Wirth's Law

Core Idea

Wirth’s Law states that software is getting slower more rapidly than hardware is becoming faster. Software complexity outgrows hardware improvements, meaning users don’t experience the expected performance gains as hardware advances.

The Law

“Software is getting slower more rapidly than hardware is becoming faster.” — Niklaus Wirth (1995)

Also known as: The Law of Software Bloat

Niklaus Wirth articulated this in his 1995 paper “A Plea for Lean Software,” attributing the core observation to Martin Reiser, who wrote:

“The hope is that the progress in hardware will cure all software ills. However, a critical observer may observe that software manages to outgrow hardware in size and sluggishness.”

Why It Happens

Software bloat compounds for several interconnected reasons:

• Abstraction layers accumulate over time—each layer adds convenience but consumes cycles
• Feature creep adds functionality that most users never use, yet every user pays the performance cost
• Dependency sprawl brings in large libraries for small needs, inflating binary size and startup times
• Premature optimization neglect — teams accept “it’s fast enough” at each layer, and the costs accumulate

Each layer of abstraction is a small performance trade-off that is individually acceptable but collectively significant.

Modern Relevance

With hardware improvement rates slowing (the effective end of Moore’s Law for single-core performance), Wirth’s Law becomes more pressing:

• Moore’s Law: Hardware capability roughly doubled every ~2 years
• Wirth’s Law: Software complexity grows faster than hardware improves
• Net result: Performance headroom from new hardware is continuously consumed by software bloat before users experience it

This is directly related to Accidental Complexity—software bloat is largely accidental complexity accumulating through tooling, frameworks, and dependency choices, not essential complexity inherent to the problem.

Related Concepts

• Accidental Complexity - Software bloat is primarily accidental complexity; Wirth’s Law describes its performance consequences
• Everything in software architecture is a trade-off. - Every abstraction layer is a trade-off between developer ergonomics and runtime performance
• Algorithmic Optimization - The primary technical counter to Wirth’s Law at the code level
• Essential Complexity - Distinguishing essential from accidental complexity is key to avoiding software bloat

Sources

• Wirth, Niklaus (1995). “A Plea for Lean Software.” Computer, Vol. 28, No. 2, pp. 64–68. IEEE.

  • Original articulation of the law and call for software restraint
  • Available: https://doi.org/10.1109/2.348001

• Wikipedia contributors (2024). “Wirth’s Law.” Wikipedia, The Free Encyclopedia.

  • Overview of the law, its history, and related concepts
  • Available: https://en.wikipedia.org/wiki/Wirth%27s_law

• DevIQ (2024). “Wirth’s Law and Its Impact on Software Development.”

  • Practical implications for software architects and engineers
  • Available: https://deviq.com/laws/wirths-law

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.