Your laptop has thousands of times the power of a machine from the 1990s, yet opening a chat app or a text editor can still feel sluggish. Niklaus Wirth named the reason in 1995: software gets slower faster than hardware gets faster. Every hardware gain gets eaten by software growing fatter to match it.
Key Takeaways
- Wirth's Law: software is getting slower more rapidly than hardware is getting faster (Wirth's Law).
- Wirth blamed uncritical feature adoption and the assumption that faster hardware would absorb the cost (Wirth's Law).
- He credited the observation to Martin Reiser, in his 1995 essay "A Plea for Lean Software" (Wirth's Law).
- The antidote is discipline about what you build, not faster machines.
The Observation
Wirth put it in "A Plea for Lean Software" (1995), crediting the underlying observation to Martin Reiser: the hope that progress in hardware would cure all software ills, undercut by software that manages to outgrow hardware in size and sluggishness (Wirth's Law). The mechanism is a treadmill. Hardware gets twice as fast, so teams feel free to spend that headroom on more features, more abstraction layers, more dependencies, and more convenience for the developer, until the software is twice as heavy and the user is back where they started.
Wirth pointed at two causes: rapidly growing hardware performance that hides the cost of bloat, and customers' (and builders') failure to distinguish features that are essential from features that are merely nice to have (Wirth's Law). Software vendors, he argued, uncritically adopt almost any feature anyone asks for.
Why It Keeps Winning
The treadmill persists because the incentives point the wrong way. Adding a feature is visible and rewarded; keeping the software lean is invisible and thankless. Faster hardware means a bloated app still runs "fine enough" on a new machine, so the bloat never forces a reckoning, it just quietly taxes everyone on older hardware or slower connections. And each convenient abstraction a developer adds to save themselves time usually costs the user a little performance, multiplied across millions of users who never consented to the trade.
| Hardware gain | Where it goes |
|---|---|
| 2x faster CPU | 2x more features and layers |
| More RAM | Heavier frameworks, more caching |
| Faster disk | Larger assets, more dependencies |
| Net user experience | Roughly flat |
A Concrete Version
A startup's web app loads fast at launch: small bundle, few dependencies. Over two years, the team adds an analytics SDK, a chat widget, three UI libraries, a heavy date library used for one function, and a framework upgrade that "handles more for you." No single addition felt expensive, and each shipped on a fast dev laptop where it seemed fine. Then a customer on a mid-range phone and a slow connection reports the app takes eight seconds to load. The bloat arrived one reasonable decision at a time, exactly as Wirth described, and only a user on modest hardware ever felt it.
The Honest Counterpoint
Wirth's Law can curdle into a reason to obsess over performance nobody needs. Not all software growth is bloat: features users actually value are worth their weight, and hand-optimizing everything for machines from a decade ago is its own waste, a cousin of premature optimization. Modern abstractions and frameworks also buy real developer productivity and fewer bugs, which is often the right trade. The useful reading isn't "software should be tiny"; it's that bloat is a cost that hides behind fast hardware, so you should measure it deliberately, on the hardware your users actually have, rather than letting it accumulate invisibly.
What This Means for Teams
Wirth's Law connects directly to the finding that most features go unused: the uncritical feature adoption he warned about is the same habit that fills products with software nobody opens, and each one adds weight. Fighting the treadmill takes a specific discipline, saying no to features, pruning dependencies, and measuring performance on real-world devices, that experienced engineers bring and that connects to choosing boring, lean technology. Lean software is a choice, not a gift from Intel. See available engineers.
Frequently Asked Questions
What is Wirth's Law?
Niklaus Wirth's 1995 adage that software gets slower more rapidly than hardware gets faster, so hardware gains get consumed by ever-heavier software instead of improving the user experience.
Why does software keep getting slower?
Because faster hardware hides the cost of bloat, adding features is rewarded while staying lean is invisible, and developers adopt convenient abstractions that trade a little user performance for their own speed. It compounds one reasonable decision at a time.
How do I fight it?
Measure performance on the hardware your users actually have, prune unused features and heavy dependencies, and be disciplined about which features are essential versus nice-to-have. Lean software is a deliberate choice.
Isn't some software growth fine?
Yes. Features users value and abstractions that buy real productivity are worth their cost. The point is that bloat hides behind fast hardware, so measure it deliberately rather than letting it accumulate unnoticed.
The Bottom Line
Every hardware gain tempts teams to spend it on more software, so the user experience stays flat while the code gets heavier, which is Wirth's Law in one sentence. Faster machines won't save you, because the bloat grows to fill them. Measure performance on real user hardware, prune ruthlessly, and treat leanness as the deliberate discipline it is.
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.
