http://www.lhotka.net/WeBlog/SoftwareIsTooDarnHard.aspx also published into an article here http://www.ftponline.com/vsm/2006_04/magazine/departments/guestop/
Wow.
I woke up early this morning and the wheels are turning before I even have started my coffee!
Personally I have to agree with many of the arguments presented here by Scott Bellware http://codebetter.com/blogs/scott.bellware/archive/2006/04/25/143303.aspx in that the “Mort, Elvis, and Einstein” personas are extremely inaccurate.
Generally speaking the personas of Mort, Elvis, and Einstein are attributed to VB.NET, C#, and C++ respectively. Of course the big question is where is Hugo???
I might go one step further though and make a presumption that the personas were never actually intended to pigeon hole a person into a role. Perhaps they were instead to represent the differing methodologies that are used and generally a person will in fact fit into all of these personas at varying times.
One could probably go so far as to take a more eastern view and say that these three personas can be used to represent the essence of development. At times we often switch (especially between Mort and Elvis). We do this for business reasons, occasionally we are tasked with business concepts that require an Einstein in order to solve, some of us focus too much on issues like this before they come thus bringing forth a true Einstein persona.
I for one truly hope that these personas were created in the context of developers sharing traits from all of these stereotypes. I will also say I think there are important distinctions between the varying roles and I believe it to be an important research tool in order to better create tools and documentation that need to be used by such a widely varied audience.
Although the pigeon holing of people into these roles is extremely interesting it is not where my focus lay when I read this article the first time, nor the second time, nor while I was making breakfast immediately after. The parts of this article which really struck me and left me in thought involved the concept of tools and frameworks as I agree whole-heartedly with some of the commentary yet could not disagree more with other parts.
And even when we get to the business functionality, we spend most of our time fighting with the OO design tools, the form designer tools that “help” create the UI, the holes in data binding, the data access code (transactions, concurrency, field/column mapping) and the database design tools.
There is definitely room for improvement in many of our tools, data binding is a good example (and ASP.NET 1.1 is a perfect example of this). I must however disagree with the DAC plumbing, I spend nearly no time managing these issues. I generally use a framework for handling such things (prevalence layer, O/R mapper, etc). These frameworks can have a significant learning curve (perhaps making all who use them Einsteins) but the learning curve associated with the tool is well worthwhile.
I think this is the root of the issue. The computer industry is largely populated by people who want to build low-level stuff, not solve high-level business issues. And even if you go with conventional wisdom; that Mort (the business-focused developer) outnumbers the Elvis/Einstein framework-builders 5 to 1, there are still enough Elvis/Einstein types in every organization to muck things up for the Morts.
I think it is important here that we define just what a framework is. Is a framework not a generalized abstraction of a process/concept? I personally find that domain specific frameworks are built in nearly every enterprise class system. I would even go further and state that if one were following Domain Driven Design that every context would be a re-usable framework in and of itself and as such one would necessarily need framework style developers who understood concepts such as patterns and decoupling.
I will be the first to admit that Domain Driven Design is probably not within the Mort realm. I typically picture Morts heading more down the typed dataset / transaction script route. These development methodologies have their place, especially within applications that have very little business logic but are instead focused on the retrieval and display of data (Eric Evans has a nice discussion on this in DDD “Smart UI Anti-Pattern”) but as developers and architects we have come to learn the limitations of such methodologies (especially when dealing with large complex domains). This is why concepts such as DDD and frameworks such as CSLA are available within the market. I have noticed that Rocky is reading DDD at this time http://www.lhotka.net/WeBlog/WhatIveBeenReadingLately.aspx.
If we were to presume that Domain Driven Design lies within the realm of an Elvis, would that not make the Elvis extremely business oriented while at the same time creating a domain specific framework for consumption at the presentation layer (most likely by Mort)?
I can tell you with certainty that a team of Morts would probably be the wrong team to develop a complex business domain that had a reasonably long expected lifespan! Elvis has some really good advice to offer in these scenarios such as discussion on decoupling and reusability through pattern application.
That said, taking a team of Elvises probably is not the best way to go as Elvises are generally higher maintenance than Morts; perhaps each has their place on a well functioning team that is meeting business requirements. I will however leave it to someone much smarter than myself to define the proper Mort/Elvis/Einstein ratios for average enterprise projects.
Perhaps the message should be that a combination of the three personas is really required in order to create a truly successful project!