What is Ninety-ninety rule?
Engineering culture
Ninety-ninety rule is a famous software joke about schedules. It says that the visible first stretch of a project takes a large chunk of the time, and the supposedly final small stretch somehow takes almost as much again. Engineers use it to describe the stubborn tail of integration, testing, edge cases, documentation, release work, and polishing, which often arrives after everyone has already started saying the feature is basically done.
What this means
The rule is funny because the arithmetic is impossible. That is what makes it memorable. It captures the feeling that a team can get most of the way to a working feature, then spend ages on the last awkward bit.
In software, the "last awkward bit" is rarely one thing. It is the pile up of details that were always real but easy to ignore early on, such as data migration, security checks, monitoring, packaging, permissions, retries, messages, and support for all the odd cases that real users immediately find.
Why it matters
This piece of engineering culture matters because it explains a perennial source of frustration between teams and the people around them. From the outside, a feature can look nearly finished once a demo works. From the inside, that demo may still be missing the hardening that turns a promising build into something you can safely release and support.
The rule also teaches a useful scheduling lesson. Software work is not evenly distributed across the life of a task. The end carries a lot of hidden weight. If leaders do not account for that, they create a cycle of cheerful progress reports followed by bruising disappointment. Understanding the rule helps teams talk more honestly about what "done" actually includes.
How it works
Where the rule came from
The rule is commonly attributed to Tom Cargill of Bell Labs. The best known early printed appearance is in Jon Bentley's 1985 Programming Pearls column "Bumper-Sticker Computer Science" in Communications of the ACM, where it appears under the label "Rule of Credibility". That matters because it places the line in the world of compact engineering maxims, not formal project management theory.
It also hints at the spirit in which people have used it ever since. The line is not a calculation. It is an experienced engineer rolling his eyes at the way software work expands in the closing stretch.
Why the last stretch grows
Early progress in software is often highly visible. You can sketch the interface, wire the happy path, show a working flow, and make the system appear almost complete. The problem is that software only becomes truly real when it meets the whole environment around it.
That environment includes real data, real users, real timing, and real failure. A feature that works for one input may fail for twenty others. A service that runs smoothly on a laptop may struggle in production. A workflow that looks fine in a demo may be unusable without proper permissions, audit trails, notifications, rollback, and support guidance. Nothing magical has happened. The team has simply reached the part of the work where the system has to stop being plausible and start being dependable.
This is why the tail of the schedule feels disproportionate. Closing the gap between "works in principle" and "works in practice" forces the team to discover all the missing assumptions.
How engineers use the rule in practice
When engineers invoke the ninety-ninety rule, they are usually warning against one of three habits. The first is mistaking a demo for a release. The second is treating test, operations, and documentation work as optional add ons. The third is reporting percentage complete as though software progress were smooth and linear.
In healthy teams, the phrase is used with a bit of self mockery. It reminds people not to be fooled by their own early momentum. It also encourages better scoping. If a team wants a genuinely short schedule, it often has to reduce the work in a more meaningful way, not just pretend the last stretch will be quick.
What the line does not mean
The rule does not mean software estimates are hopeless. It means estimates improve when teams define completion properly. If "done" includes integration, tests, deployment, permissions, observability, and support handover, the trap becomes easier to see.
It also does not mean every project tail will explode. Some work is tidy and bounded. The rule is memorable because the opposite case is common, especially in product work, platform changes, integrations, and anything user facing.
Examples
A team builds a new checkout flow and proudly shows that payment goes through. Then the real final stretch arrives. Refund handling, failed card retries, tax edge cases, receipt timing, fraud checks, analytics, customer support scripts, and accessibility fixes all need attention. The system was not deceptively incomplete. It was incompletely defined.
An internal platform team says a migration is almost done because the new service is live. What remains sounds small: decommission the old path. In practice, that means backfills, dashboards, on call playbooks, access changes, secret rotation, data consistency checks, and a plan for rollback. The visible move was only part of the job.
A reporting feature looks complete in staging. Once it reaches production, users want export formats, timezone consistency, permission filters, column names that match business language, and numbers that tie back to finance. The "last ten percent" turns out to be the part that decides whether anyone trusts it.
Common misunderstandings
A common mistake is to treat the rule as permission to pad every estimate dramatically. That misses the point. The goal is not inflation, it is honesty about what completion includes.
Another misunderstanding is that the rule only applies to weak teams. Strong teams can hit it too, especially when the boundary between feature work and release work is blurry.
People also use it as if it were mainly about coding. In reality, the painful tail often lives in testing, integration, operations, support, and product details.
Finally, some hear the joke and conclude percentage complete is useless. It can be useful, but only if the team shares a real definition of each milestone instead of handing out optimistic round numbers.
Risks and boundaries
The bad version of this rule becomes cynicism. Teams shrug, assume every project will spiral, and stop learning from their misses. That is not wisdom. It is surrender.
The good version is diagnostic. If the end of the work always expands, ask what keeps being omitted from the plan. Is it integration. Release readiness. Data quality. Approvals. Monitoring. The rule is most valuable when it reveals a blind spot the team can fix.
It also has a natural boundary. If a piece of work is tightly bounded and the team has done the same thing many times before, the tail may be short. Folklore should sharpen judgement, not replace it.
What to do next
If this pattern sounds familiar, start by tightening your definition of done. Make it explicit that progress is not just code written. It includes tests, instrumentation, deployment readiness, documentation, and whatever else your organisation needs before a change is genuinely complete.
Break large projects into milestones that each finish in a real way, not in a theatrical way. Ask for evidence of readiness, not percentages alone. When a team says something is nearly done, ask what is left in integration, edge cases, rollback, support, and production safety.
Most of all, stop rewarding early optimism more than late accuracy. Teams get better estimates when truth is safer than theatre.
FAQs
Is the ninety-ninety rule mathematically serious?
No. The broken maths is the joke. It is a way of making the schedule tail unforgettable.
Why is the end of software work often harder than the start?
Because the end is where the system meets reality. Edge cases, integration, failure handling, and release details all become unavoidable.
Is this the same as Brooks's Law?
No. Brooks's Law is about adding people to a late project. The ninety-ninety rule is about how the supposedly small final stretch keeps growing.
Does agile working make the rule disappear?
Not automatically. Iterative delivery can expose the tail earlier, but only if the team treats each slice as something close to genuinely releasable.
How can we avoid the trap?
Use a stronger definition of done, slice work more carefully, and include integration and release tasks in the plan from the start.
Is this only about customer facing products?
No. Internal tools, infrastructure changes, migrations, and data work can all show exactly the same pattern.
Sources
September 1985 issue (Communications of the ACM). publication context for Jon Bentley's column and the period in which the rule entered print
Bumper-Sticker Computer Science (IIT Chicago mirror of Communications of the ACM article). early printed appearance of the rule, attribution to Tom Cargill, and "Rule of Credibility" label