The Great Microsoft Imposed Development Culture
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?
“Most profitable?” Is that what the civil engineer is trying to achieve?
I think a lot of the questions around what’s “good” and what’s not depend entirely on one’s motivations. If someone is building crummy software, getting paid by the hour, and not planning on sticking around long enough to maintain it, they’ll build something that fits those motivations.
On the other hand, if you are building software to make a business money, as part of the business, with motivations aligned, you tend towards things that improve quality, such as the SOLID principles.
In our industry, it’s really easy to skate by with selfish motivations, and do whatever is quickest and easiest for oneself, without thought, or care as to the consequences.
@Chris – agreed–”good” depends on where you’re coming from. Perhaps my view is a bit idealistic. I generally automatically discount behaviour based on dubious motives, but that, I know, is naïve. Doing things *with* thought or care as to the consequences then requires a measure of personal and professional maturity.
It could be argued that selfish motives are in fact the only factors that influence us. For alot of us, the realisation that adding medium to long term value to software that belongs to the company that we work for will in fact benefit us personally through recognition and respect, becomes a strong driving force.
[...] just re-affirms my (reluctant) assertion that it doesn’t really take rocket scientists to keep critical business systems running. It [...]