The ninety-ninety rule states: “The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.” The rule is credited to Tom Cargill of Bell Labs and was made famous by Jon Bentley, who recorded it in his September 1985 Programming Pearls column in Communications of the ACM, titled “Bumper-Sticker Computer Science.” The Jargon File preserves the rule and the attribution to Cargill, serving as a stable documented source.
The joke is in the arithmetic: ninety plus ninety is one hundred eighty, so the rule cheerfully admits that a task estimated to be finished will, in practice, take nearly twice as long. The deliberate impossibility of the percentages is the point. The rule mocks the optimism of the moment when a programmer believes the hard part is done, the screen shows something working, and only “a few loose ends” remain. Those loose ends, the rule insists, are where the real time goes.
What the rule describes is the gap between code that demonstrates a feature and code that is actually finished. The first 90 percent gets the happy path working. The last 10 percent is error handling, edge cases, performance under load, the integration that fights back, the bug that only appears in production, the documentation, and the polish that separates a demo from a product. This work is unglamorous, hard to estimate, and routinely omitted from the original plan, which is exactly why it blows the schedule.
The rule was originally floated under the name “Rule of Credibility,” but that name never stuck, and it survived as the ninety-ninety rule because the absurd math made it memorable. Bentley’s Programming Pearls columns were full of such compressed wisdom, short enough to fit on a bumper sticker yet pointed enough to change how a reader thought about a problem. The ninety-ninety rule was the most quoted of them.
It pairs naturally with Hofstadter’s Law and with Fred Brooks’s observations about why software runs late. All three describe the same chronic optimism from different angles: estimates are biased low, the tail of a project is heavier than the head, and the parts that look almost done are the parts that take forever. The rule endures because every programmer has lived it, usually more than once, and because no amount of experience seems to cure the underestimate it describes.