jQuery and the Death of Elvis

About a decade ago, there was a little bit of a stir in the .net world. It came out that for many years, Microsoft targeted Visual Studio features towards 3 separate developer personas

Mort, the opportunistic developer, likes to create quick-working solutions for immediate problems and focuses on productivity and learn as needed.

Elvis, the pragmatic programmer, likes to create long-lasting solutions addressing the problem domain, and learn while working on the solution.

Einstein, the paranoid programmer, likes to create the most efficient solution to a given problem, and typically learn in advance before working on the solution.

In a way, these personas have helped guide the design of features during the Whidbey product cycle.

The description above is only rough summarization of several characteristics collected and documented by our usability folks. During the meeting a program manager on our team applied these personas in the context of server controls rather well (I think), and thought I should share it. Mort would be a developer most comfortable and satisfied if the control could be used as-is and it just worked. Elvis would like to able to customize the control to get the desired behavior through properties and code, or be willing to wire up multiple controls together. Einstein would love to be able to deeply understand the control implementation, and want to be able to extend it to give it different behavior, or go so far as to re-implement it.

I know it's a common practice in product design to target specific personas like this. But to me, dividing developers into Mort's, Elvis's and Einsteins is oddly frustrating. It seems at first glance that Mort, Elvis, and Einstein roughly map to a low-medium-high spread of developer skill levels, but it also doesn't seem like that's exactly what Microsoft is getting at with the classifications. In fact, they don't seem to make a clean mapping to any obvious division between developers. The confusion seems widespread, since every blogger who has commented on them seems to think they mean something different.

Is Einstein a low-level programmer, who prefers C, C++, and Assembly to Javascript or Ruby? That certainly fits the efficiency part of the description, but not the learn-and-plan up front part. In fact, for the vast majority or modern applications, I'd think starting from day one writing optimized C would be a n00b mistake, not a sign of an expert. Maybe he's a senior architect, or a rockstar ninja 10x developer, or just a guy with an academic computer science background? Meanwhile, who is Mort meant to be? Is he just not very bright? That really doesn't seem to be the case, since the descriptions of the personas ALL focus on how they prefer to learn, and experience seems to show that mediocre developers prefer not to learn new things at all.

But I had a realization

I think these 3 personas only make sense in terms of Microsoft products, and specifically the Microsoft ecosystem in the late 90's and early 2000's. In fact, I think its a chicken-and-egg thing: Microsoft includes features to make Visual Studio useful to all 3 personas, but the spread of features in Visual Studio also helped to create developers matching those personas

So here's how I think here's who those personas are meant to represent:

Mort is a tech-savvy non-programmer. He might be a researcher, he might be an engineer from another field, or an accountant who started writing programs for things he couldn't do with Excel. He might be a Systems administrator who learned how to write small, internal apps to assist him with his job, or he might be a web designer taking a step beyond html and css. I think Mort's very existence is a huge credit to Microsoft. Through Visual Basic, ASP, and later, Winforms/Webforms, they managed to create a full-featured programming platform with a shallow enough learning curve that it allowed a huge swath of people to start creating powerful applications, who simply wouldn't have been able to otherwise.

Elvis is a Microsoft specialist. Microsoft tools, particularly around 2004, worked a little differently than almost any other programming platform. You start building your application by dragging and dropping various "Controls" into a window. Each control both renders as a user interface element, and manifests as an object in a "Code Behind" file which is attached to the user interface. You typically configure your app first by dragging and dropping controls and setting them up through wizards (for the more complicated ones). Then, each control has a long list of properties which you can configure. Only when you've given your application it's basic shape in this manner do you dive into code, and its typically a wire-things-together sort of code that gets invoked to respond to user events on the various controls. If you need a user interface which is significantly more complex than what the default controls provide, the first line of defense is to go shopping around for 3rd-party controls. Elvis is a professional developer, but one who prefers to program using this technique.

Unlike Mort, who typically does small, solo projects, Elvis is comfortable working on a team to contribute to a large project. He usually understands a pretty wide set of the features of .net, understands object orientation, understands databases, and cares about writing efficient code. However, in my experience, the typical Elvis is not so good at decomposing code into small, expressive functions. He tends to put most of his code in the code-behind file for the window, and will add to existing classes or procedures rather than creating new ones. On a large project, Elvis's functions will typically grow to be in the hundreds of lines, and his classes in the thousands.

Just the name of the persona, Einstein, seems to imply that this programmer is a savant; an intellectual titan; certainly one of the top members of his field. I don't think that's necessarily the case. In fact, I think most of the people who read a lot of software blogs would get lumped as Einsteins. I think Einstein is simply the developer who is comfortable looking beyond the Microsoft abstraction. On the desktop, he might lay out his User interface in Winforms if he needs a user interface quickly, but he is comfortable writing a C++ application from scratch if Winforms doesn't meet his needs. If he's a web developer, he is comfortable writing his own HTML and Javascipt, and writing server code to respond to HTTP requests directly, rather than relying on webforms controls.

And here we get to the heart of why, I think, these classification seemed unintuitive to me. I think in the last 10 years, the world of development has changed enough to make these categories unrecognizable.

Elvis is dead

A number of changes to the world of programming in recent years have made his approach untenable. However, new tools have made the barrier to entry for becoming an "Einstein" so low that the name "Einstein" has become a complete misnomer.

The Elvis way was really designed for Desktop programming. Microsoft made a valiant attempt through Webforms to make web programming work like Desktop programming, but even in 2004 It was questionable whether this was a good idea. A web app is necessarily based on asynchronous communication between the client side; ie, the html and javascript in the user's browser, and the software running on the server. For the same programming approach to work, its necessary for webforms to try to make this communication invisible, and create an illusion of a stateful app. It needs to do more magic, to hide more, create more abstractions. It tends to be slow, since all the event handling has to take place on the server, which means that any change to the state of the application needed to invoke a roundtrip to the server and a full re-render of the page.

Then, a major change to the world of Web applications occurred when Google launched Google Maps and particularly Gmail. With Gmail, they created a full-featured competitor to Microsoft Outlook, and one that ran entirely inside a web browser. Ajax allowed Gmail to keep the page in sync with the server via a constant stream of tiny requests and responses, and then used javascript to only re-render small parts of the page. This runs completely counter to the Elvis way of doing web pages. Microsoft tried to adapt by introducing a set of Ajax controls which would automatically generate Ajax behavior, but they were not Elvis-friendly. They were too complicated, they were still slow compared to native ajax, and their behavior was filled with limitations.

Now, when Google first did Gmail, it was a marvel of engineering. Writing complicated javascript applications in the browser was considered an exercise in frustration. You had to write a ton of boilerplate code, you would be constantly bitten by subtle incompatibilities between different browsers, and it was slow. In 2006, the web saw the emergence of several javascript libraries, but particularly jQuery, which almost completely eliminated these problems. Focused R&D has made javascript orders of magnitude faster. As the Elvis way became more haphazard, the Einstein way became worlds easier.

As similar shift happened on the server side, with the rise of Convention-over-configuration web frameworks such as Rails or Microsoft's own MVC. These allow an approach to client-server interaction which doesn't disguise the underlying reality of the web, but also doesn't require a ton of boilerplate code or arcane incantations.

Mort has left the Microsoft stack

I think part of the fault here lies with Microsoft. In its effort to accommodate all 3 personas, it has added more and more features to Visual Studio and .net. I think Mort was really most comfortable with pre-.net Visual Basic, and the complexity added by the very existence of the vast array of Elvis and Einstein features makes Visual Studio harder for him to use. Meanwhile, smaller, more specialized tools have sprung up which are likely to be a much better fit for the majority of Morts. Wordpress or Microsofts's own Sharepoint are an easier solution to building almost any app that would be within Mort's grasp using Webforms. If he needs to crunch numbers or visualize data, Python makes it at least as easy as Visual Basic ever did. Really the only place where Microsoft tools may still be a good fit for Mort is if he needs to build a Windows desktop app, and that situation is increasingly rare.