Cobra Effect · People and organisations
The ninety-ninety rule
The last tenth of a project takes as long as the first nine.
6 cards, read aloud in 2:00, with a test and sources.
The demo works. The team says it is 90% done.
That was three months ago. It is still 90% done. Nobody is lying and nobody is idle.
Tom Cargill at Bell Labs put the joke into its final form.
The first 90% of the code takes 90% of the time. The remaining 10% of the code takes the other 90% of the time. That adds up to 180%, which is exactly the point.
It reached print in 1985, in a column of one line truths.
Jon Bentley collected bumper sticker computer science for Communications of the ACM, and Cargill’s line was one of them. Programmers have quoted it ever since. Usually at about month four of a three month project.
The last tenth is a different job wearing the same name.
The first 90% is the part you imagined. Happy paths and good weather. The rest is every case you did not imagine. Error handling, odd data, the machine nobody has, the customer who types a name into the date field. None of it shows up in a demo.
Progress gets measured in whatever you can see.
A demo is visible. A race between two processes is not. So the estimate tracks the visible part, and the visible part finishes first. Which is why every project feels nearly done for a very long time.
What to do about the second 90%.
Stop counting features and start counting the things that must be true before you ship. Write that list at the start, when it is cheap and unwelcome. And when somebody says 90% done, ask which 90% they mean.
Sources
- Ninety-ninety rule, Wikipedia. The line as Tom Cargill of Bell Labs gave it, and where Jon Bentley printed it in 1985. Short, with the related estimating jokes that turn out not to be jokes.
- Programming Pearls, Jon Bentley, 1986. Bentley’s first collection of columns. The bumper sticker column where Cargill’s rule first appeared is in the sequel, More Programming Pearls, 1988. Still one of the best books about thinking a program through.
- The Mythical Man-Month, Frederick Brooks, 1975. The older classic on why software schedules slip, by the man who watched it happen on a mainframe operating system and then wrote down why.
Nearby ideas
- Hofstadter’s law. It always takes longer than you expect, even when you allow for that.
- The planning fallacy. Why projects nearly always take longer than we plan.
- Parkinson’s law. Work expands to fill the time you give it.
- Span of control. Why a manager can only really lead a handful of people.
- Broken windows theory. Visible neglect invites more of it, though the crime claims are contested.
- The Peter principle. Why people get promoted until they reach a job they cannot do.
- Brooks’s law. Adding people to a late project makes it later.
- Conway’s law. Systems end up shaped like the teams that build them.