Microsoft presently builds and markets its software development tools with the consideration of three principal developer personas: Mort, Elvis, and Einstein. And since these internally-intentioned marketecture artifacts leaked into the world at large, the Microsoft developer community seems to have sought not not validate them, but to at times inordinately identify with them.
Some developer personas might indeed use products the way that the usability folks Microsoft at Redmond suggest, but in a number of cases the mapping between persona, customer demographics, and feature focus are arbitrary and meaningless and have led to at times widely missed usability targets. In some cases the personas are accurate usability predictors for Microsoft’s developer tools, and in other cases, they’re more like wishful thinking than market science. The mapping of personas to Microsoft programming languages – Mort to VB, Elvis to C#, and Einstein to C++ – has caused a lot of debate and consternation in the Microsoft developer community. In some cases, these mappings don’t really hold water. There are Elvis types who use VB, and recently there has been an inflation in Mort developers using C#.
Whether the personas are appropriate or not, one thing is still certain: these are personas that Microsoft created for it’s own purposes in trying to arbitrarily segment a developer tools market such that it matches a convenient way to market VSTS to a world that Microsoft sees through waterfall-colored glasses.
Missing from the short list is a persona that depicts the Agile developer. This would be a good developer persona for Microsoft to address because it cuts across existing personas and sheds some light on the Mort/Elvis/Einstein artifice. The Agile developer also represents a growing population of developers who are out-growing the three principal Microsoft personas. Understanding the Agile developer would help Microsoft SKU wranglers shape a product line for today instead of one for two years ago. Getting with the Agile program might even help Microsoft achieve timeliness in innovation again and help unburden it from the bulk that keeps it from being able to effectively react to missed targets.
I can’t account for the qualities of all Agilists everywhere, but here’s a stab at a persona if for nothing more than grins…
Hugo, the Agilist
Hugo has qualities of Mort and of Elvis, but he also has qualities that aren’t accounted for in Microsoft’s Three Devitos.
Both of Nikhil’s summations for Mort and Elvis apply to the Hugo persona. It might be said that, “Hugo, the opportunistic developer, likes to create quick-working solutions for immediate problems and focuses on productivity and learn as needed. Hugo, the pragmatic programmer, likes to create long-lasting solutions addressing the problem domain, and learn while working on the solution.”
Hugo opts to achieve both productivity and sustainability. In fact, Hugo achieves productivity through sustainability. These qualities are not antithetical under a methodology that allows for both of them to exist in the same workspace, kinda like the way that quantum physics allows for a particle to exist in multiple locations at the same time where it’s predecessor, Newtonian physics, does not.
He values courage, and so doesn’t behave much like the paranoid Einstein. He doesn’t believe that he can create the most efficient solution to a given problem regardless of the amount of learning in advance done before working on the solution. He uses evolutionary design and implementation practices supported by formal refactoring and regression testing so that he can begin to validate his design assumptions in code earlier rather than later, while still providing opportunities to change and refine the design at will as knowledge is gained.
Hugo is a developer who achieves sustainability through testability. Hugo designs for testability by using test-first programming approaches like Test-Driven Development and makes good use of testability patterns like Inversion of Control possibly supported by a Dependency Injection framework to escape the maintenance obstructions inherent in opaque object interactions inherent in typical RAD-tooled code. He has a significant facility with and knowledge of pragmatic project automation including automated testing, configuration management, automated build, and continuous integration tools. Hugo’s code is the team’s code and he uses a harmonized code style so as not to obstruct collective code ownership. He values communication and collaboration. More than likely, Hugo uses C#, but this is more likely due to Hugo’s Java roots than C or C++ roots. Hugo tests with a light-weight test framework rather than a heavy-weight debugger. He uses Domain-Driven Design patterns and practices to better codify and represent business knowledge in application code rather than using lack-luster domain-oriented technologies like Typed DataSets.
Mort is likely to use drag-and-drop features of Visual Studio to code the bulk of an application’s concerns. Elvis is is likely to add application logic to form code, but is just as likely to have a code library of business logic that the form makes use of. Hugo would likely only use drag-and-drop to do screen layout since using Visual Studio’s RAD tools inappropriately would foster opacity, and inhibit testability to the extent that Hugo expects. Hugo builds user interface code using the Model-View-Presenter pattern, eschewing opacity by moving UI application logic out of a form’s code-behind file into a more testable class.
Hugos can achieve more maintainability through practiced testability design, Agile testing, and communication than Mort might achieve through RAD tooling since RAD is focused on short-term implementation issues. RAD helps the novice get today’s tasks done today with a minimum of concern paid to the cost to sustainability that typical RAD approaches bring. Hugo optimizes sustainability through design to keep obstructions and code debt from impacting productivity over the entire lifespan of the project or product. Mort or Elvis’ productivity would decelerate as the RAD tooling introduced more duplication and inconsistency as defects and change requests are addressed over the lifespan of the project or product.
Both Mort and Elvis are likely to write tests after writing functional code. Hugo considers testability as a primary design concern and optimizes for success in this area by engaging in Test-Driven Development. In order to achieve secure software, we design for security. In order to achieve software that scales, we design for scalability. If we merely tack on testing at the end of development we end up in the same kind of situation when we tack on security and scalability as an after-thought. Hugo achieves clean design by focusing on testability because testable designs are identical to loosely-coupled designs of reusable classes.
Hugo is likely to opt for open source tooling over Visual Studio Team Foundation and Team System since these tools don’t add much of significance to measurable quality that can’t already be had from the light-weight open source tools, and they are significantly more costly to acquire and continue to operate than the open source tools that inspired them.
Hugo understands that test coverage is a fickle metric; that one can have 100% coverage and still have a lot of defects. Rather, he pays attention to defect rates and Cyclomatic Complexity in his code, and is assured of high test coverage numbers because that’s a small part of what Test-Driven Development delivers largely as a side effect.
Hugo quite possibly represents the next logical phase in software developer evolution 😉