the ninety-ninety rule
expressionprogrammingops culture
'The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent accounts for the other 90 percent.'
Tom Cargill of Bell Labs coined it and Jon Bentley's 1985 Programming Pearls column made it canon; the arithmetic is the joke and the truth. Demos, happy paths, and prototypes are the first 90; edge cases, integration, and polish are the second. Every 'almost done' status report is the rule mid-execution.
The first ninety percent of the code takes ninety percent of the development time, and the remaining ten percent takes the other ninety percent. Tom Cargill's joke works because the arithmetic is deliberately impossible and the experience is universally recognized.
What it names is the systematic underestimation of the tail. The demonstrable functionality arrives quickly, and then comes everything that is not demonstrable: error handling, edge cases, the deployment story, migration of existing data, the interface that has to work for people who did not build it, and the long sequence of small problems that only appear under real conditions. None of that is visible in a prototype, which is why prototypes are so misleading as estimates.
The practical use is in how you communicate progress. Percentage complete based on features implemented is systematically optimistic, and a project reported at ninety percent for several months is the standard shape rather than an anomaly. Estimating the tail explicitly, or reporting progress by what is genuinely finished including its failure modes, is less satisfying and considerably more honest.