Why 180% = 100%

Aphorism /ˈafəˌrizəm/ noun

“a short clever saying that is intended to express a general truth”

The 90-90 rule in software is the persistent illusion of “it’s almost done”. Tom Cargill of Bell Labs coined this aphorism back in 1985:

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

You read that right, 180%. Welcome to software engineering.

180% = 100%, Really?

Yes, really!

If you’ve ever managed, written, QA’d or hired a company to create custom software, you’ve likely encountered the peculiar phenomenon where the closer a project gets to “done,” the further it feels from completion.

Is it frustrating? Yes.

Is it annoying? Yes.

Is it part of writing great software? Absolutely!

To the uninitiated, 180% goes something like this:

• A Project Manager says: “We’re 90% feature complete.”
• The QA team hears: “We’ve just reached the fun part where everything breaks at once.”
• A Developer hears: “Let the games begin.”
• The Finance team hears: “Please double the budget.”
• The Customer hears: “You’ll get it next month.”
• The Business Analyst thinks “What did I miss, what did I miss?”

While meant to be “tongue in cheek” humour, the reality is that 90% of feature completion is only 50% of the effort it takes to create great software. This is the nature of making something complex appear simple and it’s important your technology team prepares for it. The last 10% is when the rubber hits the road, when the all the planning, foundational code, finesse and reliability gets put to the test. It’s where planning takes the gold and QA presents the medal.

The last 90, or the final 10, however you look at it, can be relatively painless, and the project can stay within budget and be delivered on time; if it is scoped out thoroughly and the last 10% is planned for. The key is planning.

Why the Last 10% Can Feel Like Walking up a Waterslide in Flip-Flops

Why does that final stretch consume so much time and sanity? Simply put, because great software is delivered by developers who are never satisfied with “good enough”. Delivering an easy-to-use product means overcoming the following:

• Unknown Unknowns: Early in a project everything looks straightforward – login, payment and a reporting dashboard. As projects progress login means 2FA and payment also includes 37 edge cases around refunds. The final 90 can feel like quicksand if these unknowns are not uncovered early in the discovery phase.
• Bugs Breed in the Shadows: The last 10% is where bugs come to hide. Integration issues, race conditions, and “this only fails when the server is under 97% load and it’s a leap year” types of problems pop up. These are far harder to spot than obvious syntax errors and determining their root cause is a lot like hunting a mosquito in a tent.
• Integration Nightmares: Everything works fine in isolation—until you connect it all together. Then your database says “No!”, your APIs times out, and Jenkins cries in the corner.
• Security: It’s one thing to make code run. It’s another to make it secure and not force you awake at 3 a.m. because it crashed under load. Lots of automated and manual testing, fuzzing and code reviews can help address this.
• Performance: Your application needs to run fast and avoid consuming all the resources over time. High performance software starts with a solid foundation but finishes in the final 90% with the polish that ensures it works reliably, every time. Part of the goal of the last 90 is the optimization. In the book The Art of Computer Programming (TAOCP) Donald Knuth stated, “Premature optimization is the root of all evil, or at least most evil in programming; the true issue is that programmers have worried about efficiency much too much, in the wrong places, and at the wrong times.” Or in other words, it is counterproductive to optimize early due to its time-consuming nature for transitive code. Only once the first 90% is locked in it is time to start optimizing for performance and resource usage.
• Compliance: Remember that simple “payment” option? It’s in the last 10% where those 37 edge cases around refunds breed new PCI compliance issues. This is where meticulous and relentless QA will help get you over the finish line.
• QA, Forever the Critic: All jokes aside, QA is the cornerstone of great software and the last 10% is their time to shine. Well-written code is only truly “good” when QA has proven it works—everywhere, for everyone, every time.

The Slippery Slope of Scope Creep: There is a significant difference between changing requirements and the unknown unknowns. The former, sometimes known as scope creep, can lead to a change request (CR) or an entirely different project phase. It can alter the timeline and budget and has been known to roll back the last 90% to the first 90%. Scope creep seems harmless when it is disguised as a simple request like “lets only offer refunds for customers who paid by Visa”. Ron Jefferies said it best, “simple, not easy”. Whereas the latter is more like an ‘aha moment’, a normal part of the last 10% The realization that “Login” means multi-factor authentication and password recovery and OAuth integrations instead of a simple log in button, generally part of the first 90% but the integrations are put to the test during the last 90%. These ‘aha moments’ are mostly preventable, but, if you fail to plan … we all know how that saying goes; more on that later.

Writing code that “just works” is fast. Writing code that is secure, easy to maintain, and user-friendly takes exponentially longer. It’s the difference between buying a fast-food burger and fries or making one from scratch where you raised the beef and grew the potatoes yourself.

Fast and Cheap vs. Slow and Good

Good, fast or cheap pick any two:

• Fast + Cheap = Bug-Driven Development
  You’ll ship quickly, sure, but your customers become unpaid QA testers. Congratulations, you’ve just invented a new business model called “chaos as a service.”
• Cheap + Good = Slow Pace
  You’ll eventually have solid software, but your competition has an advantage if they are on the fast + good track.
• Fast + Good = More Expensive
  This is where the magic happens, but it requires top developers, solid requirements, and a bit bigger budget.

The reality? Great software is a marathon with hurdles, not a 50m dash. The 90-90 rule isn’t an excuse; it’s a reminder that quality, scalability, and security can’t be rushed without consequences.

How to Beat the 90-90 Trap (Sort of)

Consider this:

• NASA’s Mars Climate Orbiter was lost because of a unit conversion error (imperial vs metric). A tiny oversight cost $327.6 million.
• Knight Capital lost $440 million in 30 minutes because of a buggy software deployment.
• Intel wrote off $475 million because of an arithmetical error, which was determined to be an edge case rounding error.

Would you rather explain to your board that you’re “90% done” or that you lost half a billion dollars because “done” was rushed?

90-90 is not a cynical joke, it’s a lesson in project and time management:

• Take Your Time Building Requirements: 70% of all software projects fail because of issues with requirements. The more time spent on gathering requirements the fewer CR’s and ‘aha’ moments you will have in the last 10%. At STEP we opt for a Hybrid SDLC whenever possible. Its long discovery and requirement gathering phases give us the opportunity to gain a deeper understanding of our client’s goals, timelines and budgets.
• Plan for Overruns – If you budget for “best case,” you’ll overrun time and money almost every time. Expect change and ensure the expense has a buffer for this, – Agile isn’t just a buzzword; it’s software survival.
• Budget for the Finesse – That “final stretch” of usability and reliability is worth the extra time; it’s what users will remember. The final finessing is where good software becomes great, or where great projects die quietly in a Git branch named final_final_reallydone_thisone.
• Prioritize Ruthlessly – Not everything can (or should) make it into Version 1.0. Focus on essentials. Break work into smaller milestones or phases. Ship iteratively. Smaller releases mean smaller unknowns. Learn to say “no”, not at least “not yet.” Just look at the iPhone, it didn’t get copy and paste functionality until the iPhone 3.
• Invest in Quality Early and Automate the Boring Stuff – Unit tests, CI/CD pipelines, and good architecture reduce pain in that final 90%. Remember Jenkins over there in the corner? This helps avoid that.
• Communicate Honestly – Setting the right expectations with clients and stakeholders saves careers (and friendships). Have difficult conversations early, help them understand the long-term ROI of doing it right the first time. Talk openly about the difference between unknown unknowns, scope creep and new requirements. Be firm on how each will impact the project and whether it is a realistic part of the last 10%.

The 90-90 aphorism forces leaders and developers to accept that software isn’t just about writing code; it’s about solving problems, finessing experiences, and elegantly handling edge cases you didn’t know existed.Ultimately, it’s about building something you can be proud of.

Respect the Aphorism

The rule isn’t really about percentages. It’s a warning label for optimism. Software projects always look “almost done” until you start testing, integrating, and hardening them for real-world use.

But here’s the punchline: that’s a good thing. It means developers are sweating the small stuff, QA is challenging them with edge cases, and both are refusing to settle for “it works on my machine.”

In the long run, great software isn’t remembered for being fast or cheap. It’s remembered for working. Reliably. Predictably. Securely. Every time.

Remember this:

• Doing it right the first time is cheaper in the long-term.
• Technical debt is compound interest—ignore it, and you’ll pay double (or triple) later.
• Customer trust is fragile. You only get one chance to make a first impression, ship a buggy product once, and users/clients may never come back.

So yes, taking the time to slog through that “last 10%” may feel endless, but it’s better than spending eternity fixing avoidable mistakes or losing customers forever.

And that’s worth 180%.