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?

With a title like that, you’re probably expecting to hear about the elusive silver bullet–that one ingredient that makes projects finish on-time and within budget.  We all know that that’s a pipe dream … or is it?  If there were three things that were the most critical factors in determining if a software endeavour were to succeed, what would those be?  What would the most important of those three be? One word: People (capatilisation intentional).

Joel Spolsky runs a successful software company, and ‘casts to the masses on a regular basis; and guess what makes him excited?  Figuring out the best way to get the very best people on board.  He’s identified the proverbial Goose (that lays the golden egg) and things can only get better.  Developers have the latest toys at their disposal; enormous, luxurious displays, motorised desks and their own offices (with a view!).  Because Joel has realised that once you’ve bagged the alpha geek, the story is only beginning—a really productive “smart and gets things done” geek works best when surrounded by the most scintillatingly cool toys (multi-screen/big screen and really fast machine) and quiet … yes quiet (or put another way–”freedom from interruption/distraction”) makes an enourmous difference to productivity.  Justin Etheredge echoes some of these sentiments in this well-written whinge-fest.  Joel has spared no expense in clearing the path for his people because he groks it.  That being said though, not just anyone is hired at FogCreek and often good people are overlooked, but at the end of the day it’s all in aid of attracting the Best of the Best because once again … he groks it.

When the lone hero development model breaks down due to sheer project size, we need to move onto teams … or groups of co-working people.  It’s just an extension, so excellent people beget excellent teams and as Martin Fowler points out, it isn’t methodologies that succeed or fail, it’s teams that succeed or fail.  Excellent teams will always succeed.

Recently someone raised what appears to be a contentious issue, that is, is it acceptable to “design for test”.  Personally, initially a proponent of the “don’t-prop-your-code-up-for-the-sake-of-tests” department, I am becoming more inclined to agree with the author of said posting.  Being able to completely isolate an object for the purposes of testing is a beautiful thing, but sadly it sometimes requires a whole lot of P.T. in the form of dependency injection frameworks and the like–we’re currently feeling this pain on a big project we’re working on.