What is Wirth's law?
Engineering culture and software practice
Wirth's law is the adage that software is getting slower more rapidly than hardware is getting faster, which is why new machines and new versions so often feel no quicker than what they replaced. It is named after the computer scientist Niklaus Wirth, who set out the argument in his 1995 IEEE Computer article A Plea for Lean Software, although Wirth himself credited the underlying saying to Martin Reiser.
What this means
The law captures a familiar disappointment. Processors, memory and storage improve year after year, yet the experience of using a computer to do ordinary work rarely feels faster. The reason, Wirth argued, is that software expands to consume the new capacity, so the two roughly cancel out and the user is left standing still.
It has a name because it names a systemic tendency rather than a single bug. Individual programs are not slow by accident; they get heavier because features accumulate, because each layer of convenient technology adds a little overhead, and because it is usually cheaper to demand a bigger machine than to trim the software. The law puts a label on the direction of travel.
Its natural counterweight is Moore's law, the long expectation that hardware would keep getting more capable. Wirth's law is the sardonic reply: the hardware kept its side of the bargain, and the software quietly spent all the winnings.
Why it matters
For an organisation that buys hardware and software, the law reframes a recurring question: when a system feels slow, is the honest fix a faster machine, or is the software simply demanding more each year for the same job. Treating every slowdown as a hardware problem means buying new capacity indefinitely to stand still, which is a real and avoidable cost.
The pattern shows up plainly in web pages and internal tools. Pages and applications have grown far heavier over the last decade while the work they do for the user has changed much less. The extra weight is not free: it costs load time, bandwidth, battery, and it quietly excludes people on older devices or slower connections, which for a public-facing body can be an accessibility problem as much as a performance one.
There is an AI-era version that leaders should recognise. A task that used to be instant and local, such as classifying a message or drafting a line of text, may now involve a call to a large model. That call adds latency the user notices and a per-use bill the organisation did not previously pay. The capability can be worth it, but the trade is new, and it is exactly the kind of quiet resource growth the law describes.
None of this means bloat is always bad. Much of the extra resource bought something real: better security, wider accessibility, and faster development because teams reuse large, convenient libraries rather than hand-crafting lean code. The point of the law is not that all growth is waste, but that growth should be a choice you can see and justify, not a default you pay for without noticing.
How it works
Where the term came from
The law is named after Niklaus Wirth, the Swiss computer scientist who designed Pascal, Modula and the Oberon system. He set out the argument in A Plea for Lean Software, published in the IEEE Computer Society's magazine Computer in February 1995, volume 28, issue 2, pages 64 to 68. In it he contended that software's girth had outrun its function, largely because hardware advances made the growth possible, and he offered his lean Oberon system as proof that far less was needent.
Wirth was scrupulous about attribution and did not claim the adage as his own. He credited it to Martin Reiser, who had written in the preface to his book on the Oberon system that a critical observer might note software outgrowing hardware in size and sluggishness. So the law is named after its populariser rather than its author, which is worth stating plainly. Two companion jokes travel with it: the quip that what one large company gives in performance another takes away, and later restatements about the ever-growing weight of web pages.
What Wirth actually blamed
Wirth pointed at two forces. The first was features nobody really asked for: vendors adopting almost any capability a customer might want, so that inessential details accumulate and each one carries a hidden cost. The second was time pressure. When schedules are tight, it is cheaper to let software sprawl and lean on faster hardware than to invest the discipline required to keep it small. Restraint costs effort now; bloat defers the cost onto the user's machine and the buyer's budget.
The evidence, handled honestly
The strong form of the law, a precise claim that software slows faster than hardware speeds up, is a slogan rather than a measured finding, and it should be presented that way. Measuring it rigorously across decades is genuinely hard, because the tasks, the interfaces and the expectations all change at once, so like-for-like comparison is rarely possible.
What can be measured points in the direction Wirth described. Web pages have grown steadily heavier for well over a decade according to long-running public measurement of page weight, and the growth is driven largely by images and scripts rather than by more content. That is consistent with the law without proving its strongest version. The counterweight, Moore's law, gives the joke its force: hardware capability did rise dramatically over the same period, and the user still often waits.
Where the resource actually went
Experienced teams resist the lazy reading that all bloat is waste. A large share of the extra resource bought genuine value: encryption and sandboxing for security, larger fonts and assistive features for accessibility, and above all developer speed, since reusing big frameworks lets small teams ship quickly. The mature response is not to demand universal leanness but to ask, for any given growth, what it bought and whether that was worth the latency, the cost and the excluded users. Where the answer is nothing much, the law is a licence to push back.
Examples
Consider a mid-sized retailer whose head office replaces every laptop on a three-year cycle, always because staff complain the machines feel slow. An IT manager finally checks and finds that the core sales-reporting tool has roughly doubled its memory demand across two versions while doing the same job. The slowness was software growth, not worn-out hardware, and a lighter reporting approach would have saved a whole refresh cycle of spending.
Picture a council department publishing planning documents on a public website. Over five years the pages have grown heavy with trackers, embedded viewers and large images, and residents on older phones or slower connections increasingly cannot load them. The work the page does, showing a document and a date, has not changed. Here the bloat is an accessibility failure as much as a performance one, and trimming it serves the department's duty to reach everyone.
Imagine a professional services firm adding an AI assistant to its intranet search. A lookup that used to return instantly from a local index now routes through a model, adding a couple of seconds and a per-query charge. For complex questions the richer answer earns its keep; for simple ones it is slower and more expensive than what it replaced. Recognising the trade, the firm keeps the fast local path for simple lookups and reserves the model for questions that need it.
Common misunderstandings
People often think Wirth coined the saying himself. He popularised and named the argument in 1995, but he explicitly credited the adage to Martin Reiser. The law is named after its promoter, not its originator, and Wirth said so.
A common misreading is that the law proves all modern software is lazily written. It describes a tendency and a set of incentives, not a verdict on every program. Much growth bought security, accessibility and development speed, and the law's value is in prompting the question, not in supplying an automatic condemnation.
There is a tendency to treat this as the same thing as bit rot. It is not. Bit rot is software degrading in place because the environment around it moves on, so code that once worked stops working. Wirth's law is about new software and new versions demanding ever more resource for the same job; unlike bit rot, the software here still works, it just consumes more.
Some confuse the law with premature optimisation. Premature optimisation is the error of tuning code for speed too early, before it is needed. Wirth's law is the opposite concern, a systemic drift toward heaviness over time; it is not an argument for micro-optimising everything up front, which carries its own costs.
Finally, people assume the law means you should never buy new hardware. It means you should know why you are buying it. Sometimes the workload genuinely grew; sometimes the software simply bloated. The law asks you to tell the two apart before you spend.
Risks and boundaries
The main risk is treating a slogan as a measurement. The strong claim is not something anyone has cleanly demonstrated across the history of computing, because the tasks and expectations change too much to compare fairly. Used as a rhetorical prompt to question resource growth, the law is valuable; used as a proven quantitative rule, it overreaches.
It also does not cover every kind of slowness. A slow system may be badly configured, starved of memory, or genuinely handling far more work than before, none of which is bloat in Wirth's sense. Reaching for the law before diagnosing the actual cause can send an organisation chasing the wrong remedy.
There is a legitimate debate about how much of the growth is waste. Reasonable engineers disagree, because so much bloat bought security, accessibility and speed of delivery that are hard to price. The law is best read as a standing invitation to make that trade explicit, not as a settled judgement that leanness always wins.
What to do next
Before approving a hardware refresh driven by slowness, ask whether the workload actually grew or whether the software now demands more for the same job. If it is the latter, a new machine only buys time until the next version eats the gain.
Ask vendors and internal teams what a new version's extra resource demand bought. If the answer is security, accessibility or a genuinely new capability, the growth may be justified. If the answer is vague, treat that as a reason to push back or to keep the older, lighter version.
Set a weight or performance budget for public-facing pages and internal tools, and treat exceeding it as a decision that needs justifying rather than a default. This is particularly important where slow, heavy pages would exclude people on older devices or slower connections.
For AI features, separate the tasks that genuinely need a model from those a fast, cheap, local method still handles well. Route simple work down the fast path and reserve the model, with its latency and its bill, for questions that earn it.
FAQs
What does Wirth's law actually say?
That software is getting slower more rapidly than hardware is getting faster, so the two tend to cancel out and new systems often feel no quicker than the ones they replaced.
Who really came up with it?
Niklaus Wirth named and popularised it in his 1995 article A Plea for Lean Software, but he credited the underlying saying to Martin Reiser, who had written something similar about the Oberon system.
How does it relate to Moore's law?
Moore's law is the long expectation that hardware keeps getting more capable. Wirth's law is the pointed reply that software absorbs those gains, so the user does not feel the benefit.
Is the law actually proven?
Not in its strong form. Measuring it rigorously across decades is very hard because the tasks and expectations change. It is best treated as a well-founded slogan, not a precise finding.
What did Wirth blame for the bloat?
Two things: features that nobody really needed being added anyway, and schedule pressure that makes letting software sprawl cheaper than the discipline of keeping it small.
Is all software bloat a bad thing?
No. A lot of the extra resource bought real value such as security, accessibility and faster development. The law asks you to make the trade visible, not to reject all growth.
What is the AI version of the law?
Tasks that were once instant and local now often involve a model call, which adds noticeable latency and a per-use cost. That is new resource growth for work that used to be free.
What single question should a leader ask?
When told a system needs more hardware, ask whether the work grew or the software did, and what any new version's extra demand actually bought.