The Limber Lambda

A while ago I followed up on investigating a popular metaphor amongst developers, namely, “Mort, Elvis, Einstein” (MEE).  I find it ironic that the origin of the MEE meme is Microsoft itself because there seems to be an undercurrent of bigotry surrounding it.  In short, it’s oft cited anywhere where there’s heated discussion about what I call “The Great Microsoft Imposed Development Culture”.

What constantly amazes me is the apparent lack of metrics and measures in development.  Perhaps I just haven’t done enough research, but everything I read (bar Steve Mcconnell’s writings) is full of opinion-laden anecdotal “evidence”.  There’s a whole lot of gut feel, but far too little accounting.  In fairness, that’s probably got a lot to do with how difficult it is to analyse development in that way.  Perhaps though, the most profitable software company in the world has got it right.  They may just have access to “the numbers”, and a neat little formula that takes as one of its inputs an enumerated type, namely, Mort, Elvis, Einstein, and spits out profit.

Wouldn’t such a scenario lead to an optimised developer culture—one that has been optimised for profit?  Of course, a chosen culture leads to a style in tooling as well.  Tools need to be optimised for use by the most cost-effective developer stereotype: you guessed it: Mort.

So, let’s follow this path a little further:

Q: How does Microsoft attract businesses to its platform?

A: Through the provision of a frictionless, feature-rich development platform; one that promotes visibly quick, effective solutions to business problems.

So, sure, IoC is neat and Context/Specification is da-bom, but do these things beat click-drag-and-F5 within Visual Studio backed up by a bit of copy-and-paste?  That question posed within the context of the answer above, as shocking as it may seem, has no objective answer.  Where are the numbers?

I’ve heard Bob Martin go on about the benefits of SOLID, and they all feel right to me, but if this really was as much a science as it should be (compared to say, civil engineering, for example), wouldn’t the sort of heated debate that was sparked by an episode of the StackOverflow podcast be moot?  Dead in the water.  Direct anyone who doubts the benefits of exhaustive unit testing to a neat, ratified theorem or an undeniably convincing set of statistical evidence.  If only we had such a thing.

I am a firm proponent of all things “good” (as opposed to evil, which is what many would label Mort and his cohorts), namely the SOLID principles, continuous integration, consistency of shared code, the DRY principle and various agile practices.  My gut just says it’s the right thing to do.  The question is, is it the most profitable?