Scheduling the baby out with the bathwater

When it comes to true innovation, try you must or do you will not. Whilst the larger companies have whole R&D departments dedicated to experimentation with new techniques and technologies, the smaller outfits or individuals have to innovate as they go along. One of the first casualties of war when it comes to tight schedules is the wistful experimentation that leads to great leaps forward. Playing and fiddling with new technologies, new ideas or just exploring whacky thoughts is what ultimately invents the new stuff that’s really exciting. It also exercises the brain, develops new knowledge and expands horizons. When you lose the chance to play in this fashion, then you’ve damaged your ability to develop the quality of software that, ironically, your clients would really love you for.

As Douglas Adams once said, “I love deadlines. I like the whooshing sound they make as they fly by”. Other than the detailed specification, never has a more comprehensive pack of lies been produced than the software project schedule. They don’t all start out that way, but arrive there via a collective negotiation of errors. Amongst the bottomless pit of reasons why schedules are so difficult to get right are the yin and yang of incorrect estimations:

  1. You are fundamentally scheduling invention and
  2. There is heavy pressure to keep the duration and costs low

The first one is obvious: unless you are purely assembling simple parts, then your estimate is, at best, going to be an educated guess based on your experience. The second is where the pain usually comes from. Whoever is paying for the work wishes to pay the least amount possible and wants the project delivered as fast as possible, which is only reasonable given that money doesn’t grow on trees and nobody likes been bent over a barrel for a thorough ripping off. This creates an enormous amount of pressure to take your first best-guess schedule and shrink it in order to make everyone happy.

The problem was that you were already 50% out with your estimate and any further shrinkage is going to make a bad situation even worse. It’s like receiving a punch in the face whilst being kicked in the balls. Let’s visualise the problem using one of the scheduler’s best torture tools, the Gantt Chart!


You see that red bar? Unless it's in your spare time, that never gets done, regardless of its benefit. Irregular Pigeon is here to point out just how irregular this should be. Little does he know, eh?

If you’ve been involved in software development then this might have given you a cold chill of familiarity. Note from the overflow that there is a substantial miss, usually by at least 50%. If you work at a games company and you’re not towards the top end of the chain o’ command, then this massive schedule overrun is usually compressed at your expense using the medium of “crunch time”. This genius process is where employees are guilted into working shudderingly long weeks (80 hours plus are not unknown) for months (often without any additional pay) in order to cover up for management’s piss-poor, over-optimistic scheduling, under resourcing or whatever else contributed to the error. Of course the full blame is assigned to the technical people who were pressured to deliver such outrageous estimates in the first place when, in fact, they probably only deserved a third of the blame for not realising why their estimates are grade-A bollocks:

  • Gantt Charts encourage a task oriented rather than problem oriented schedule. It is utterly impossible to describe the entire problem’s task list in advance of doing it
  • Your client’s specification is a variable, not a constant. This variable is tweaked by them and you. They change their requirements as they learn and you change the requirements as you learn – it is part of being smart enough to change to meet changing needs. This will absorb most of the rest of the contingency. The act of doing clears the mists
  • Things never go right all the time. Half of your contingency will be used by things that you could never possibly have predicted and many will be totally out of your control (what’s that? Another massive incompatible SDK update?)

The approach I like to believe that I take is the Scotty Approach1. I am asked how long something takes, I estimate then I double it. That way, when I am inevitably talked down, I can remove a smidgen of the contingency and still have time to exceed everyone’s expectations and deliver on time. This would not have worked for me twenty years ago because I did not have the experience to make any of these estimates accurately. Now, though, generally I have the knowledge to schedule invention without being light-years away from reality (even if those schedules are generally ignored). Even with this approach, there isn’t much room to manoeuvre. The actual formula I use to turn an estimate into something half-accurate is this:

  • Create best possible estimate, let’s call this X.
  • Multiply X by 1.5.
  • Then add another 10% for good measure and round up to the nearest month.

Example: you estimate that a piece of software is going to take 12 months to develop. X = 12. Now multiply by 1.5 leaving you with 18. Now add 10% leaving you with a shade under 20 months and round up to 20. Crikey! 20 months! But it’s surely only a 12 month project! No, no it isn’t. It’s a 20 month project when you add everything else in.

Total time = ((estimated time) x 1.5) x 1.1)

Ok, you can simplify this formula but I prefer to see it broken down like this. The 50% is all the extra stuff that you and the client didn’t consider at the outset. It’s the stuff that was forgotten and the stuff that becomes important as the project develops in order to deliver something that is suitably excellent. The 10% is the contingency. To be honest, I’d like it to be 20% as it’s genuine extra time that dictates the quality of the cake’s decoration. It also provides proper time to review and test the software — something which is usually the first thing to get cut.

The net result with my normal formula is that if it is stuck to, you deliver high-quality software on time and on budget and are in a position to exceed expectations of all stakeholders whilst delivering excellent value for money… so long as you are a half decent developer.

Then, sometimes, despite all your experience you make one or both of these errors:

  1. You agree times and budgets without a decent or full specification: the “gentleman’s agreement error”
  2. You end up quoting X, or worse still, slightly less than X under immense pressure to reduce time and cost

Either way, you are now set up to crash and burn. You end up delivering the full formula’s worth of work, but you can usually only bill for less than half of any over-run, if at all. Professional pride ensures that you run it out to the line but the lateness is a cross you bare: further projects will inherit the bad estimates and you run the risk of being locked into a continual nightmare of under billing for increasingly large amounts of work.

All words, no answers

I have no idea what the answer to this is. Unless you’re EA squeezing out another iteration of one of their evergreens or are in such a position that you can simply say “this will take as long as it takes”, then scheduling is always going to be a tough exercise in educated guesswork: travel past the mysterious specification of incompleteness, through the woodland of over-optimistic estimates and then wade knee-deep in the swamp of unrealistic expectations. The larger, more evolved, better resourced companies can mitigate and control the risks through process: proper change-control and staff who’s job it is to deal with all this stuff. Whilst you procedure your way out of a whole stack of creativity, you do create a situation where slippage is minimised and controlled with the added bonus of potentially being able to avoid it altogether by simply managing the situation professionally. For the small or individual developers this kind of management overhead is simply unrealistic: you either do the work or manage the work but you can’t do both effectively without some compromise somewhere.

I make the scheduling mistake all the time. I ignore my gut feeling, bow to pressure and agree to schedules that are going to be tough to achieve. That isn’t to say that they can’t be achieved, but I condemn myself to additional work either paid or unpaid that should be spent rocking backwards and forwards in a hammock with a gin and tonic in one hand and a good book in the other. Take a look at my independent iPhone game: I’ve already ignored my own formula for calculating its duration. It should be a seven month project but fortunately, I don’t care. It’s for the fun so whether I deliver it or not is not really the point but I accept that I am a special kind of hypocrite for lecturing on the subject of bad scheduling decisions whilst making those bad decisions.

Why task-orientated, tight schedules for games don’t work 101:
Take this snake-oriented game. The snakes indicate the area of the specification that is unchanged. Oh! What’s that? Giraffes? That’s right. Turns out that adding vertical snakes with giraffe patterns on them made a better game: but not a single giraffe existed in the documentation when the project started. The original task-oriented tight schedule contained less than half of the tasks that were eventually implemented. Thus, it was whoppingly out from the start. This is on-going specification dilution. It’s normal. It’s good. It shows you’re smart enough to not flog dead horses: fail to build this into the schedule and terrible things happen with milestones. They end up like concrete boots.

Personal hatchet job aside, though, “accurate” scheduling is done only if the parties involved accept that;

  1. the up-front knowledge of the scope of the project will be under by a good 30%,
  2. the act of doing will change the project scope,
  3. scheduling by detailed individual tasks is doomed to failure,
  4. unexpected surprises are so normal that they’re really expected surprises,
  5. testing always takes longer than anticipated and needs to be factored in as a continuous process and finally,
  6. you’ll still need contingency to experiment, learn and try: schedule this out, you lose the little touches that allow your solutions to really stand out

To spot the expert, pick the one who predicts the job will take the longest and cost the most”

For the work that pays the bills, though, pressure to deliver is high and over the years I’ve delivered a shocking amount of work that I am not able to charge for for one reason or another. Other than being truly independent financially, it is difficult to place yourself in a position where you can quote realistic times and budgets without someone else being prepared to undercut you knowing that they won’t deliver, but figuring that getting their foot in the door is more important than delivering quality. Winning contracts by quoting the least amount of time normally means that QA and contingency have been scheduled out of a schedule that was probably already utter fiction anyway.

Quality, well structured, reliable software development is hard to come by. Endless warranties that stretch to infinity are even rarer. It surprises me that the impression is that this stuff is easy to do – it is not. Quality, as it does in all areas, comes at a cost. That is not to say that there isn’t a sliding scale of value, but it’s amazing to me that so many people expect first class service for third-class costs.

In the meanwhile, though, yeah, sure: I can shave a couple of months off that schedule…

1 I say “like to believe” because this ideal situation exists purely in my dreams. I dream that I estimate it’s a year’s work, quote two years and they say “OK, Mr Cobras, that’s great, but we’d love it if you can do it in, say, 22 months.” I say “Yes, I can manage that” and then love, happiness and general excellence washes over the world at large.

This entry was posted in Software development and tagged , , , , . Bookmark the permalink.

11 Responses to Scheduling the baby out with the bathwater

  1. Pingback: Book Club episode II: Wool and the art of software documentation | Cobras Cobras