Skip to content
GK LibraryA home for curious minds
English

Slowing Down Faster Than Hardware Speeds Up: Wirth’s Law

A newly bought laptop feels very fast for the first few months. But after a few operating system and program updates, it somehow starts to lag like your old computer. Chips get faster every year, yet the speed you actually feel hardly improves. There is a saying that sums up this curious phenomenon in a single sentence: ‘Wirth’s Law.’

Put simply, Wirth’s Law refers to the rule of thumb that ‘software slows down faster than hardware speeds up.’ No matter how much hardware improves, software eats up the gains first, so the speed users feel stands still or even goes backward.

In this piece, we will look in turn at where Wirth’s Law came from, why software gets heavier, examples we see around us today, and ways to build lean software.

Wirth's Law explainer diagram. In a hypothetical example, a workload of 4 at a processing speed of 1 takes 4 seconds, while a workload of 12 at a processing speed of 2 takes 6 seconds, showing that wait times can grow when workload increases more than hardware speed. It suggests focusing on essential features, reducing unnecessary code, and measuring speed and memory.
A simplified hypothetical example for understanding Wirth’s Law, not an actual benchmark. Source: Niklaus Wirth, “A Plea for Lean Software,” Computer 28(2), 64–68 (1995). Original paper

Heavy Software That Catches Up With Faster Chips

Where Did Wirth’s Law Come From?

An old beige workstation with a dim screen, a CRT monitor, a keyboard and mouse, a stack of academic journals with blank covers, and a coffee cup on a wooden desk in a Swiss university computer room in the 1990s, with mountains faintly visible through the window

The law is named after the Swiss computer scientist Niklaus Wirth. Wirth introduced the programming language Pascal in 1970, and in 1984 he received the Turing Award, often called the Nobel Prize of computer science.

(1) ‘A Plea for Lean Software’
In 1995, Wirth published an article titled ‘A Plea for Lean Software’ in the journal ‘Computer.’ In it, he introduced the remark “Software is getting slower more rapidly than hardware becomes faster” as the words of his colleague Martin Reiser, and this sentence later came to be called Wirth’s Law.

(2) Bloated software in numbers
Wirth wrote that only about 25 years earlier, an interactive text editor could be built in 8,000 bytes, and a compiler had to fit within 32 kilobytes. Their descendants, however, demand memory measured in megabytes, and he criticized that they would not even be usable if hardware had not become roughly a thousand times faster.

(3) An observation paired with Moore’s Law
If Moore’s Law is the prediction that the number of transistors on a semiconductor chip keeps doubling, Wirth’s Law is the opposite observation that the performance gained this way does not fully reach users. Wirth noted that the performance of Intel’s 80×86 family of processors improved 335-fold from 1978 to 1993, while adding that software’s endless appetite showed no sign of shrinking.


Why Does Software Keep Getting Heavier?

A small, light paper boat floating on a calm sea beside a huge cargo ship loaded with far too many colorful containers, a metaphor for lean software versus bloated software

Wirth named two reasons people so readily accept software growing larger. One is that hardware performance improves so quickly, and the other is the attitude of consumers who cannot distinguish essential features from nice-to-have ones.

(1) Feature creep
When a feature or two is added with every new version, even features most people hardly ever use pile up and the program becomes heavy. Wirth pointed out that people mistake complexity for sophistication.

(2) Layers of abstraction
Stacking many layers of tools and libraries that make development easier speeds up building, but it also adds just as many steps to go through when the program runs.

(3) Faith in fast hardware
When the idea spreads that ‘computers will get faster anyway, so optimization can wait,’ the work of refining efficiency gets pushed back. As another saying Wirth quoted puts it, software expands to fill the available memory.


Wirth’s Law Around Us Today

A young office worker at a bright desk looking a little frustrated at a new laptop screen showing only a blurry loading indicator, with a smartphone with its screen off, a potted plant, and a coffee cup beside it

Wirth’s Law has repeated itself under different names in every era. In the 1990s the joke “What Intel giveth, Microsoft taketh away” was popular, and at a Google developer event in 2009, Sergey Brin called the same phenomenon ‘Page’s Law,’ after his co-founder Larry Page.

  • Messenger Apps: Exchanging text is the same as it always was, yet it has become common for a single app to take up hundreds of megabytes of memory.
  • Web Pages: Reading a few paragraphs of an article also means downloading ads, tracking code, and even a video player, so the page appears slowly.
  • Word Processors: The basic job of entering, deleting, and moving text is unchanged, but installation size and startup time have grown with each version. Wirth’s point is that the arrival of windows and icons did not change an editor’s essential task.
  • OS Updates: When a new operating system is built for the latest devices, phones a few years old become noticeably slower while doing the same work.

How to Build Lean Software

A developer’s two hands on a clean white desk carefully pulling a few small blocks out of a neatly stacked wooden block tower, with a thin laptop with its screen off and a precision screwdriver set beside it

Wirth did not stop at criticism; he built an example himself. From 1986 to 1989, he and his colleague Jürg Gutknecht created an operating system called Oberon with just the two of them, and also designed a programming language of the same name. The core of Oberon, including the editor and compiler, was less than 200 kilobytes.

(1) Focus on the essentials
Decide on the truly necessary features first, and separate the rest so that only those who need them can add them.

(2) Measure performance consistently
Measure execution speed and memory usage every time a new feature is added, so you notice early when the program is gradually getting heavier.

(3) The courage to take things away
Wirth said that the greatest satisfaction in programming comes when you succeed in removing something. Deleting unused code is as important as adding features.


Wirth’s Law reminds us of the costs we can easily overlook while advances in hardware hide software’s excess weight. For users to enjoy experiences that are faster in step with faster chips, those who build software must make efficiency and simplicity their standard from the start. This also ties into reducing power use and the cost of replacing devices.

Thinking about taking away before adding: that is the first step toward developing software that is fast and lasts.