I remember an episode of Saturday Kitchen, featuring Raymond Blanc, where he refused to be drawn into the ridiculous “omelette challenge” – his sentiment was, if you don’t have a few extra minutes to cook an omelette properly, then it’s not worth making.
Blanc’s belief mirrors the menu from Restaurant Antoine, popularised in Frederick P. Brooks, Jr. The Mythical Man-Month (1972): “Good cooking takes time. If you are made to wait, it is to serve you better, and to please you.”
In summary, Brooks uses cooking as a metaphor for software projects. He proposes that most have gone awry because of a lack of calendar time. Following on, he highlights five causes:
- Our techniques for estimating are poorly developed, so over-optimism results in making estimates shorter than they should be;
- Effort is NOT the same as progress;
- Schedule progress is poorly monitored;
- When schedules slip, we add more people;
- Managers are gutless, so often over-promise and over-commit the people actually doing the work.
I like to think that, although we are still over-optimistic by nature, we’ve made headway in making estimates. We also frequently promote the thought that effort is different from progress and monitor progress more appropriately (an example of both is that we record the time left on a burndown chart, not the time spent so far). I’ve already said my piece on burndowns, so won’t do so again.
The bulk of the essay focuses on his final cause: adding more resources to a problem when the schedule slips. Although he supports it with a lot of graphs and maths, the gist is that “adding manpower to a late software project makes it later.” As he says, “The bearing of a child takes nine months, no matter how many women are assigned.”
However, communication still seems to be a problem for many companies. Every month when I’m speaking to people about agile, the root cause of many an issue is that someone communicated something inappropriate. I like Brook’s analogy of the chef: “the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion. An omelette, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices – wait or eat it now. … The cook has another choice: he can turn up the heat. The result is often an omelette nothing can save – burned in one part, raw in another.” Although I could be pedantic and highlight that a chef making an omelette is very different from our work – as the time it takes to make every omelette should be pretty consistent – the point is that you can’t hurry a project. His solution still holds true: until we get better at estimating, “managers will need to stiffen their backbones”.