In our introductory monograph we exhibited the two basic recipes in the shambolic software planning cookbook which are, in short:
- Pure guesswork. Just pick the end date out of thin air.
- As above, but with extra ego. Guess how long it’ll take, and then halve that on the grounds that you and your pals are Superheroes.
Now these two are great for the newcomer and in fact correspond closely to the algorithms used in many large-scale professional IT programmes. But to progress in the world of software calamity and ruin we need to grasp the fundamentals of failure and embrace them without reservation. So let us examine the mindset, the essence and the, if you will, Weltanschauung, that are essential for enterprise-scale cock-up.
First, keep it vague. Primarily, keep the scope and therefore the size of what is being undertaken vague. High-level. Outline. Don’t get bogged down in the itsy-bitsy details that might illustrate the full breadth of what has been asked for: user requirements, functionality, performance, capacity, all that pettifogging undergrowth. The more you delve, the more complex it becomes. The more complex it becomes, the harder people have to work to figure out what is wanted and how it should be done. Nobody likes fiddly, complicated work, and everyone’s going to get depressed. Especially senior management, and you don’t want depressed bosses. So stay loose. They want a website ? It will likely be just a handful of pages. Words and pictures, with a cheap’n’cheerful webstore tacked on. Doddle, put like that. Few weeks work, maybe. Further probing will only distort the picture. You’re going to find out they want stock and order control off the back of the online shop. And they want customer profiling, ratings, reviews and intelligent product recommendations. And it’s got to be like Amazon, but not the same as Amazon, but better than Amazon – know what I mean ? You don’t know, of course, but just nod, smile and go with amibguous, fuzzy and approximate. A nice simple spec for your nice simple job which is easy for your nice simple top bananas to understand. They’ll like that, and the warm feeling they remember from these early, halcyon days may reduce the ferocity of the brutal kicking you will most assuredly get when it all unravels later on. As usual, Mr. Scott Adams provides the clearest illustration of how well estimating and scheduling can go when no-one has a clue what anyone is meant to be doing:
Vagueness and obscurity should obviously be extended to all other areas where they can be useful. Architecture and design for starters. But by all means be specific about the colour scheme.
Secondly, work backwards. Rather than starting with the tasks at hand and calculating when conceivably they could be finished, take a deadline you’ve been given and spend a week convincing yourself it’s viable. Ideally, the date given will come as an unbrookable challenge from someone senior, frightening and / or impossible to reason with. A big customer. A Vice President. The MD. Your missus. To return to the garage-clearing-out example, this is the equivalent of ‘Er Indoors delivering you the ultimatum that, as you’d bloody well promised to tidy it out over last bloody Christmas, then you had better bloody well actually tidy it out before next bloody Christmas, you useless bloody waster. Or Bloody Else.
We all inhabit increasingly fearful and authoritarian work places where not just the Customer but also Your Boss, His Boss and anyone else who can claim to be a Senior Stakeholder is Always Right. So what if they’ve never written so much as an Excel macro in their life. They Know. They have Years of Experience. Insight. Vision. They can survey the landscape from 30,000 feet, allowing them to perceive complex interconnected structures at a glance. To pick out the opportunities where their minions see only problems. And they have the magical power to make even the most ludicrous proposition true by stating it to their underlings repeatedly, with messianic self-belief and bags of implied threat. So it will be done by Christmas, you bloody wasters. Or Bloody Else.
Thirdly, be optimistic. Wildly optimistic. About everything. You’ll probably get assigned three dozen of the finest software engineers available to humanity. They will all work 80 hour weeks. They will, within days, be completely au fait with the design, the business processes and all of the technologies involved. They will never be ill, take holidays, or get dragged away from your work into urgent flavour-of-the-month special projects for weeks on end. All of the code will work perfectly first time. Even though the spec was kept deliberately vague at the start, your guesses about what those five bullet points on a Powerpoint slide might mean will turn out to be absolutely bang on. No nasty new vital requirements will crawl out of the woodshed, and you definitely won’t find out six months in that you’re expected to add in data encryption, support for Chinese characters and migration to MySQL.
I cannot stress the importance of mindless optimism enough in Planning for Disaster. It is the most valuable guiding principle; a literal no-brainer. When faced with any question about your undertaking, think Gordon Brittas meets Pollyanna on Ecstasy.
Question #1: Should we put a few weeks contingency into the timeline somewhere ?
Answer #1: No ! We haven’t forgotten anything, and nothing at all is going to go wrong.
Question #2: If we replace this experienced and relatively good team of coders in Swindon with some random guys from Chennai we’ve never worked before, will that affect the end date ?
Answer #2: No ! They come highly recommended. Capability and Maturity Model level 97. They’ll be up to speed by Tuesday, no bother.
Question #3: The general ledger module is a Black Hole. Nobody understands it. Last time we had to make what purported to be a simple, low-risk, minimal-impact surgical adjustment, it took Keith two months. For the same sort of hack this time, we’re allowing precisely a week. Is that wise ? Specially as Keith left last Easter.
Answer #3: Yes ! We’ve Learnt from Experience. Done the Knowledge Transfer. Got the Robust Documentation in place. It’s a Turnkey Operation.
And so on, and on. The key is that, rather than remembering painful history as it was and vowing not to repeat it, you recall it as it should have been. And repeat it as even bigger farce, the second, third and ninety-seventh time round.