Software Engineering Laws: The Ninety-Ninety Rule

First of all, I must say that this is not a law that happens in every project. I know that you’re smart enough to understand this but I’ve seen leaders that really needs some reinforcing message to not generalize everything and take word by word. That said, read this post with this in mind. :)

I have lost count of how many times I have seen a project sprint through most of its scope, only to stall right at the end. The team demos something that looks 90% done. Everyone is happy. Then two more weeks go by, and it is still not shipped.

There is a name for this. It is called the Ninety-Ninety Rule, and it goes like this:

The first 90% of the code accounts for the first 90% of the development time. The remaining 10% accounts for the other 90% of the development time.

Yes, that adds up to 180%. That is the joke, but it is also the truth.

Why it happens

The first 90% is the fun part. Features come together fast, the architecture makes sense on paper, and progress is visible every day. It is easy to feel like the project is almost done, because most of what you can see is, in fact, almost done.

The last 10% is a different kind of work. It is integration between pieces that were built separately. It is the edge case nobody thought about during planning. It is the bug that only shows up under production load. It is performance tuning, security review, and the small polish items that do not look important individually but add up to a lot of hours together.

None of this is visible early on, because you cannot find these problems until the pieces actually come together. That is exactly why it always feels like it comes out of nowhere.

How to navigate it as a manager

I cannot make the last 10% disappear. Nobody can. But there are a few things that have helped me and my teams get through that stretch without burning out or losing trust with stakeholders.

Name the stage before it happens. When I plan a project, I now tell the team and the stakeholders directly that the last stretch usually slows down. That is not pessimism, it is just how software works. Naming it early means nobody is surprised or defensive when it happens, and it protects the team from being blamed for something that is a known pattern.

Change the team structure for that stage. The skills that get you through the first 90% are not always the skills that get you through the last 10%. Broad feature work benefits from parallel streams, several people building different pieces at once. Integration and bug fixing benefit from fewer people, deeper focus, and less context switching. If I can, I shrink the group working on the final stretch and let a couple of strong generalists own it end to end, instead of keeping the same wide team structure that worked for the earlier phase.

Increase communication, not pressure. This is the stage where I show up more, not less. More check-ins, shorter feedback loops, and I make myself available to unblock things quickly. What I try hard not to do is add pressure on top of that. The team already feels the weight of being close but not done. Piling stress on top of that usually slows things down further, not speeds them up.

Protect the team from scope creep during this window. The last 10% is not the time to squeeze in one more improvement because “we are already in there.” I hold that line as firmly as I can. New ideas go on a list for later, not into the current stretch.

Give credit for the invisible work. Fixing a subtle integration bug does not look as impressive as shipping a new feature, but it is often harder. I try to be explicit about that in one on ones and in front of the team, because this is the kind of work that goes unnoticed if nobody names it.

The Ninety-Ninety Rule is not really about bad planning. It is about the nature of software itself. The first 90% builds the parts. The last 10% proves they actually work together. Knowing that in advance will not make it faster, but it will help you lead your team through it with less friction.

I hope this was useful for you, Rodolfo