preliminary noises
Much discussion has gone into the concept of “moral hazard” in the present dismal economic downturn. For those of you whose minds are virginal on this subject, it went something like this: “They got a loan on a house they couldn’t afford. Now they are in trouble and they want to be bailed out. What about me? I have mine. Why should they be rewarded?” the obvious rejoinder being, when all your neighbors are foreclosed, what happens to your property values.
moral hazard 2.0
Since that early phase we are seeing the magnum sized version rating-agencies-insurance-companies-derivatives-credit-default-swaps-CEOs who want to be immune from any accountability. That is a story, and an interesting one at that, but that is not my story.
dire developments
So that got me thinking, what are the aspects of moral hazard in the development arena? Arena is a rather threatening word, redolent of the Colosseum and bloodthirsty crowds and unwilling victims so let’s go with that. First of all, let’s talk about technology debt.
big ideas
Now I guess we are all familiar with the normal kind: buy now and pay later. The same idea can happen in the development arena. The plumbing, the infrastructure, the documentation, the component versions (gems, jars, JVM versions, OS, whatever) can all go to Hades in a leaky barely Styx-crossing boat because there is a BIG THING THAT HAS TO BE ACCOMPLISHED RIGHT AWAY WITHOUT DEFINING WHAT IT IS OR HOW IT CAN BE ACCOMPLISHED.
yuck
Down the road not less well traveled a bunch of half digested projects hit the calendar in a vomitous splat.
Now the conventional wisdom is that the engineers are complete idiots and don’t know what they are doing. Typically they are not agile enough and not seriously committed to the sprint.
And, like much of conventional wisdom it may even be true.
primordial soup
Of course, this is often produced by barely mulitcellular managers who think that hazy and ill defined tasks that they have initiated are clear if they talk really fast can be accomplished by bargain code monkeys (I find the more open ended and poorly defined a task the more sophistication and initiative (and usually salary) that is required.)
Does this sound familiar? It is kind of like the previously mentioned system, where somebody who defaults on a half million dollar house is seen as equally responsible as somebody who has lost billions.
At this point the management hazily lifts up its nictating membranes and its collectively reptilian brain slowly absorbs the fact that is in a train wreck that may very well bust up its terrarium.
avoiding blame
Of course their mantra is get it up and going fast and don’t bother about the technical details and please don’t document anything!
the failure of moral authority
Which avoids the problem: if you do a quick back of the envelope specification you will expose the fact there are logical contradictions in your idea that means that it cannot be accomplished without modification.
Please note that these types talk very very fast.
Another bad sign is that they have listened to the audio book of Agile for Dummies and use the terminology without understanding a word of it.
rewards and punishments
To really launch such a situation all you have to do is set the conditions of punishment and reward incorrectly. This will provide temporary cover to reap the rewards of borrowing against the future, and may insulate you against future consequences.
disclaimer
As this would never happen in real life, this blog post is a work of fiction and bears no resemblance to any persons living or dead.