We have grasped now the basics of shambolic software planning and adopted the behaviours necessary to succeed. That is, fail. But these are not, even in combination, always enough. You may by chance allow just long enough to do the work. For guaranteed, repeatable blunders, you need to be mathematically certain that you’re doomed from the off. It is therefore essential to collect all of the precision-tooled components that could be used to construct a viable plan for the production of useful software. And then, with a 20-pound sledgehammer forged from our unique alloy of breathtaking arrogance, brainless optimism and pig ignorance, smash each one into the dust.
We have established that brainless optimism is your guiding light towards not only offering and agreeing to a ludicrous deadline, but in convincing yourself that that date is eminently reasonable. You employ this optimism in the first instance when you write down your list of tasks and size them. Brainlessly forget some, and optimistically underestimate the rest. Hard to forget about actual programming, to be honest, but perfectly plausible to forget about code reviews, unit tests, merges, meetings and the days that will be spent trying to get everybody’s code to work together when you finally integrate. One could also legitimately omit any of the many, varied but always compulsory demands of the Captain Darlings who inhabit your Programme Office: submissions to the Technical Architecture Committee, attendance at Test Strategy Review Workshops, Stage Boundary Gatekeeping Assessments, Paperclip Resource Forecasts. As these are designed to help(*)and add value(**), they will surely have a net positive effect. The many hours spent filling in the forms they demand will undoubtedly be outweighed by the quantum uplift in Quality.
Brainless optimism really gets into its stride when contemplating test and bugfix. ‘Cuz there won’t be any bugs, will there ? Run your installer, click around a few screens, check a few numbers and bingo. It’s all going to be fine. Test all done in a jiffy. Fortnight, tops. Looking through your 1970s-Elton-John-jumbo-size-rose-tinted spectacles you will be able to see that the chances of the following scenarios arising are so negligible as to be absurd:
- Toiling for a month to get different bits of test kit to connect to each other and play nicely.
- Upgrade scripts having to be revised 17 times before they run without error on said kit
- Report which took two days to write requiring three weeks to debug.
- Discovering four pages of the spec that haven’t been developed at all.
- Performance turning out … to …. be … so … very … slow … that the whole team has to spend four months on emergency optimisation and caching before they can even start on bug fixing.
- Users raising over 200 concerns(***) during acceptance testing, all of which are ultimately proved to be witless misconceptions of how the system is meant to work. Nonetheless, each one requires half a day of investigation, analysis and debate to establish that it is not in fact a bug.
Never happen. Not with our top-notch set up. Inconceivable.
We’re in a good place now. We have a task list which is so flimsy, content-free and unrealistic, it could be a script for Hollyoaks. But we can finesse it still further. For the coding jobs where you actually got an engineer to have a look through and make estimates, let us examine who that engineer might have been. It won’t have been Ciaran, the new graduate you started last month. He may well have a large collection of ironic slogan T-shirts and a good complicated haircut but he certainly won’t have the experience on which to make any sort of sensible guesses. It also won’t have been Terry, the vague ex-hippie whose working hours, general understanding and engagement are ill-defined and erratic. And it absolutely won’t have been Keith, who took two months to write a 20-line data extract and can’t be trusted with actual Java or sharp implements. No. It will have been Patricia, who is competent, well-organised and knows her stuff. She will naturally have estimated on the basis of how long it would take her to write it all herself. You will then take the 135-day total she gives you and divide it by three to get an elapsed time of nine weeks. By that simple piece of arithmetic, you are blissfully presuming that your team will be Pat and two other tip-top developers. Those two paragons will have exactly as thorough a comprehension of the requirements and technology as she does. But that’s not who you’ll get. All of the capable First Eleven engineers will turn out to be working on some other fool’s ill-fated endeavour. You’ll be left with Ciaran, Terry and Keith. So now the Keira-Knightly-width slim chance of hitting your code freeze rests on Ciaran turning out to be a genius, Terry getting his shit together and staying off the jazz cigarettes, and the pair of them collectively pulling such an unprecedented blinder that it doesn’t matter if Keith spends the entire two months trying to extract and format a list of active users.
But as a best-of-all-possible-worlds type of guy, all of the ill-founded and inaccurate assumptions you have made within this planning exercise will seem entirely sound. Or alternatively as a born-again moron, you won’t even notice you’ve made any assumptions. You’ll be in good company. A lot of software project management lore rests on the implicit belief that the spread of developer ability is vanishingly narrow. The bell curve is zero width. A day is a day. A line of code is a line of code. One programmer is exactly equivalent to any other programmer; they are as interchangeable as bushels of wheat, barrels of Brent Crude, or pork bellies. In this admirably egalitarian / soullessly inhuman conception, the lad who wrote Tetris on a Soviet minicomputer is the equal of the erstwhile colleague of mine who struggled to get his head round a four-clause Case statement. Privately you may realise that even within your own office, the brightest engineer is 50 times quicker than the dimmest, but put this thought out of your ahead in order to embrace dogma and disaster.
At this point, your proposed schedule has become so preposterous that carnage is assured. There are further shambolic planning steps one could take, but by this stage we are really just gilding the lily. Or french polishing the turd, whichever. One layer of polish you may wish to apply is the fond belief that everyone on the job will be working on it the full 37.5 hours per week. Starting with days off, bank holidays, illness, training, corporate team building workshops and the christmas piss-up and you’ve already lost one day out of five. On top of that, there will be live bugs, third-line support and other, even more hopelessly knackered projects that need rescuing. Add the fallout from that lot in and your people have lost between a third and a half of their working week. But maybe your team will turn out to be heroic Stakhanovite shockworkers. They will perhaps shrug off fatigue and gaily work 14 hour shifts to make up lost time and produce double the production quota of function points.
Or maybe they’ll be down the pub for a two-hour lunch most days, before clocking off at 5:15 on the dot to get home in time for Mythbusters. One of the two.
And you’re done. You have a schedule and it all looks really slick. It’s probably a Gantt chart in Microsoft Project, with dependencies and resource utilisation graphs and milestones and critical paths and whatnot. It will be passed round, and all the stakeholders will nod sagely and agree that an exhaustive analysis exercise has been carried out and therefore that the timeline is achievable and 100% validated. But they’ve all just come back from an SMT Brainsharing shindig on the topic of Management through Stretch Goals, based inevitably on a string of very tired motoring metaphors. The Little People see roadblocks instead of looking for shortcuts. They should be picking up speeding fines rather than collecting parking tickets. Let’s shoot some Nitrous into the carburettor. You say February – why not Christmas ? Why not Tuesday week ?
And now you’re really screwed.
(*) “Help”, in normal English usage, is something you ask for when in need which makes your life easier. In the context of IT projects, it is something forced upon you that you have not asked for, cannot get rid of, and which makes you life worse. Like a persistent telesales caller, or herpes.
(**) Any person, body or practice which claims to add value will, categorically, not.
(***) In the olden days, people spoke English and when something went wrong it was a problem. Then we stopped having problems, as that was defeatist negative thinking, and had instead and rather more vaguely, issues. Now that issue has slid semantically toward the pessimistic connotations of problem, we have concerns. Thing with concern is, you can be concerned about anything. Taxation. Wind Farms. Traffic Police. France. There don’t have to be any specifics, it doesn’t have to be wrong, and you don’t have to propose or justify an alternative. You just state your concern, and put on your concerned, serious face. Baseless Inarticulate Whinge would be a sharper definition for what is being put across.