This content originally appeared on DEV Community and was authored by Seth Keddy
The 90–90 Rule is a tongue-in-cheek observation about software development that goes like this:
“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.”
In short: the last mile always takes longer than expected.
On the surface, this seems absurd—until you’ve actually written code in a production environment. Then it becomes painfully accurate. This article explores how this rule plays out in modern DevOps pipelines, how it affects developer velocity, and why it’s not just about code—it’s about everything surrounding it.
The Rule Behind the Rule
The 90–90 Rule is essentially a brutal reinterpretation of the Pareto Principle (80/20 rule) and closely aligned with Hofstadter’s Law, which says:
“It always takes longer than you expect, even when you take into account Hofstadter’s Law.”
This recursion captures the essence of complex systems: you don’t know what you don’t know—until you do, and by then it’s too late.
DevOps Meets the 90–90 Rule
DevOps promises speed, automation, and continuous delivery. But real-world projects still hit the wall of the 90–90 Rule. Why?
Here’s how that last “10%” shows up in DevOps:
1. Deployment ≠ Done
You finished your CI/CD pipeline and deployed to staging? Great. Now wait for:
- Security reviews
- Compliance checklists
- Permissions and IAM audits
- Feedback from operations
- Cost estimation reviews
- Secret management issues
Suddenly, your “final 10%” just turned into another sprint.
2. Automation is Harder Than It Looks
Writing a script is easy. Writing a repeatable, testable, observable, and secure automation pipeline across staging and prod? That’s your “second 90%.”
- YAML drift between environments
- Parameter mismatches
- State not being idempotent
- Terraform’s “destroy” doing what it does best
3. Observability and Monitoring
Instrumentation is usually considered a “post-dev” concern. Until a bug hits prod. Now you’re scrambling to add:
- Proper logging
- Distributed tracing
- Dashboards
- Alerting thresholds that don’t page you at 3 AM
The kicker? These systems themselves require CI/CD and version control. The observability of the observability stack is the rabbit hole you didn’t want to fall into.
4. Writing Code That Works ≠ Writing Code That Lasts
A function may pass tests locally. But in production?
- It may leak memory
- It may not scale under load
- It might silently fail in edge cases
- It may have business logic that changes next week
DevOps isn’t about just getting the code to run. It’s about lifecycle management: monitoring, updating, patching, retiring, and documenting.
Why the Last 10% Takes 90% of the Time
Here are a few hard truths:
- Unknown unknowns appear late in the cycle
- Integration pain is exponential, not linear
- Edge cases multiply as complexity grows
- Code is easy to write, but hard to support
- Perfection becomes the enemy of “good enough,” especially in regulated industries
How to Break the 90–90 Rule (or At Least Respect It)
Design for observability and testability from the beginning.
Don’t make instrumentation an afterthought.Treat infrastructure as code and version it religiously.
Your pipeline should be as testable as your application code.Accept that “done” is a moving target.
Code in isolation is an illusion. Feature completeness includes docs, alerts, metrics, runbooks, failover testing, and more.Use chaos engineering to uncover hidden dependencies early.
Nothing shows you your “real last 10%” like breaking prod in a controlled way.Overcommunicate in cross-functional teams.
Devs think in features. Ops think in uptime. Security thinks in risk. The last 10% often falls between these silos.
Conclusion
The 90–90 Rule isn’t a sign of failure—it’s a warning. In DevOps, it’s not enough to just build and deploy. You have to plan for the unknowns, design for sustainability, and deliver with confidence, even when time is against you.
Next time you finish that “last bit of code,” pause. You might just be at the halfway mark.
Related Concepts:
This content originally appeared on DEV Community and was authored by Seth Keddy