Every engineer has said it: "it's basically done, just a few finishing touches." Then the finishing touches take another month. Tom Cargill at Bell Labs turned that experience into a rule that adds up to a deliberately impossible 180%: the first 90% of the code takes 90% of the time, and the remaining 10% takes the other 90% of the time.
Key Takeaways
- The ninety-ninety rule: the first 90% takes 90% of the time; the last 10% takes the other 90% (the ninety-ninety rule).
- Attributed to Tom Cargill of Bell Labs, popularized by Jon Bentley's 1985 Programming Pearls (ninety-ninety rule).
- The 180% total is a joke about how reliably projects overrun.
- The "last 10%" is where the unglamorous, unpredictable, essential work lives.
What the Rule Captures
The humor is in the arithmetic: 90% plus 90% is 180%, which is exactly the point, that projects routinely take roughly twice as long as the "we're almost done" moment suggests (Wikipedia). Cargill's insight, popularized when Jon Bentley featured it in his September 1985 Programming Pearls column as the "Rule of Credibility", is that the first 90% is the fun, visible, predictable part, building the happy path, and the last 10% is everything that makes it real: edge cases, error handling, testing, polish, performance, and the integration surprises nobody planned for (the ninety-ninety rule).
That last 10% is disproportionately hard because it's disproportionately unpredictable. The happy path is knowable up front; the ways it breaks are not.
Why "Almost Done" Lies
"It's 90% done" is one of the most misleading phrases in software, because the remaining 10% is not 10% of the work. Progress feels fast early, when you're building the visible structure, so the estimate of time-remaining is set by that fast early pace. Then reality arrives: the edge case that needs a redesign, the error state nobody considered, the test that reveals a wrong assumption, the last integration that behaves nothing like the docs. This connects straight to the planning fallacy, which biases us to imagine the smooth path, and the cone of uncertainty, which says the unknowns dominate until they're resolved.
| The first 90% | The last 10% |
|---|---|
| Happy path | Edge cases + error handling |
| Visible, demo-able | Invisible, essential |
| Predictable | Unpredictable |
| Feels fast | Grinds slowly |
A Concrete Version
A team demos a new feature two weeks in: it works, it looks done, and everyone celebrates that it's "90% there." The remaining "10%", handling the empty state, the network failure, the concurrent edit, the accessibility pass, the load test that reveals a slow query, and the three integration quirks, takes another two weeks. The feature genuinely was 90% visible at the demo. It was maybe 50% done, and the gap is the entire reason the launch slipped.
The Honest Counterpoint
The rule can be misused as an excuse for chronic lateness, "the last 10% always blows up, so of course we're behind." It's a description of a tendency, not a law of nature, and good teams shrink the surprise. You can pull the unpredictable work forward instead of leaving it for the end: handle error cases as you build the happy path, write tests alongside features, integrate early rather than in a big-bang at the finish, and demo on real data instead of the golden path. None of that makes the last 10% free, but it moves the surprises earlier, when they're cheaper, and makes "almost done" mean something closer to done.
What This Means for Teams
The ninety-ninety rule is really a warning about how to read progress and set expectations. Treat a slick demo as evidence the happy path works, not that the feature is nearly shippable, and budget explicitly for the unglamorous last stretch that a demo hides. Experienced engineers estimate with the last 10% in mind and front-load the risky, unpredictable parts, which is the same discipline behind honest estimation and measuring real delivery over optimistic plans. See available engineers.
Frequently Asked Questions
What is the ninety-ninety rule?
A humorous adage attributed to Tom Cargill: the first 90% of a project takes 90% of the time, and the remaining 10% takes the other 90%. The impossible 180% total captures how reliably software overruns.
Why does the last 10% take so long?
Because it holds the unpredictable, essential work: edge cases, error handling, testing, performance, and integration surprises. The happy path is knowable up front; the ways it breaks are not.
Why is "it's 90% done" misleading?
Because progress feels fast while building the visible happy path, which sets an optimistic sense of time-remaining. The remaining work isn't 10% of the effort; it's the hard, slow part that a demo hides.
Can you avoid it?
You can shrink the surprise, not eliminate it. Pull unpredictable work forward: handle errors as you build, test alongside features, integrate early, and demo on real data so the last stretch holds fewer shocks.
The Bottom Line
"Almost done" is the most expensive phrase in software, because the last 10%, the edge cases, error handling, testing, and integration surprises, routinely takes as long as everything before it. A slick demo proves the happy path works, not that the feature is nearly shippable. Budget for the hard finish, pull the risky work earlier, and stop trusting the 90%-done feeling.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
