A 1965 coding paper coined the idea of software bloat
In 1965, computer scientist Mary K. Hawes published an analysis of program size and memory growth. Long before personal computers existed, she warned that software tends to expand to consume all available memory regardless of hardware upgrades. Niklaus Wirth later popularized this observation in 1995 as Wirth's Law, famously noting that software gets slower faster than hardware gets faster, formalizing decades of developer frustration.
The Paradox of Expanding Hardware
For decades, the trajectory of computing hardware followed an extraordinary pace of exponential improvement. Processors gained higher clock speeds and denser transistor counts, storage capacities jumped by orders of magnitude, and random access memory shifted from scarce kilobytes to abundant gigabytes. By conventional logic, everyday computing tasks like opening a document, drafting text, or calculating a column of numbers should have become instantaneously imperceptible in their execution time. An action that took two seconds on a machine from the early era of computing might theoretically be expected to complete in microseconds on a modern workstation.
Instead, users and engineers across multiple generations have repeatedly observed the opposite sensation: computers frequently feel just as sluggish as their predecessors, if not noticeably slower. Programs routinely take seconds to launch, user interfaces stutter under routine loads, and memory warnings reappear on machines equipped with thousands of times more physical memory than earlier hardware generations could conceive. This stubborn gap between raw hardware capability and delivered software responsiveness revealed that code does not simply remain static while physical machines accelerate around it; software continually changes, absorbs resources, and reshapes its own internal demands.
Early Warnings of Memory Growth
The recognition that code expands to consume whatever capacity surrounds it dates back to the formative years of commercial and scientific computing. In 1965, computer scientist Mary K. Hawes examined the practical dynamics of program size and memory growth, observing a trend that ran directly counter to the assumption that larger memories would permanently solve engineering bottlenecks. Long before the era of personal computers or distributed microservices, Hawes recognized that supplying developers with more primary memory did not result in lighter, unencumbered programs. Instead, systems rapidly grew in size until the newly available storage was once again entirely occupied.
Hawes's observation echoed the broader cultural logic of Parkinson's Law, the mid-twentieth-century adage originally formulated by C. Northcote Parkinson stating that work expands to fill the time available for its completion. Applied to digital systems, memory emerged not as a permanent buffer against constraint, but as a container that inevitably invited greater volume. When engineers were granted room to maneuver, the immediate pressure to prune instructions, reuse storage registers, and compress data representations diminished. Memory capacity functioned less like a static ceiling and more like an active determinant of how generously software architectures would be drafted.
Wirth's Law and 'A Plea for Lean Software'
Three decades after Hawes examined memory growth, the Swiss computer scientist and Turing Award laureate Niklaus Wirth published a landmark essay in 1995 titled 'A Plea for Lean Software.' Wirth, renowned as the creator of programming languages including Pascal, Modula-2, and Oberon, brought a disciplined, minimalist engineering philosophy to the conversation. In his paper, Wirth articulated what quickly became known across the computing field as Wirth's Law: software is getting slower more rapidly than hardware is becoming faster. While Gordon Moore's empirical rule predicted regular doublings of hardware density, Wirth pointed out that a countervailing force in software development consistently neutralized those hardware windfalls.
Wirth was not merely expressing casual irritation with system lag; he was diagnosing a structural disease within contemporary software engineering culture. He noted that the computing industry had fallen into a pattern where hardware gains were treated as a license to abandon rigorous design practices. Rather than celebrating hardware progress as a tool to achieve unprecedented computational efficiency and lower operational cost, the industry used the surplus power to insulate increasingly sprawling codebases from their own algorithmic inefficiencies. The law encapsulated a fundamental tension: hardware progress is driven by physical miniaturization and architectural innovation, whereas software growth is driven by human organization, commercial incentives, and accumulating layers of compromise.
The Internal Mechanics of Bloat
To understand why software swells, Wirth and subsequent analysts dissected the practical incentives governing modern development. Primary among these is feature creep, the relentless addition of marginal capabilities designed to justify new product releases, satisfy marketing departments, or appeal to narrow segments of users. In commercial markets, a software update with an identical feature set but cleaner, faster internals is notoriously difficult to market compared to an update boasting a long list of novel functions. Consequently, systems accumulate features that are rarely used by the majority of people, yet every user pays the ongoing runtime cost in memory overhead and operational latency.
A second critical mechanism is the proliferation of abstraction layers and external dependencies. To speed up delivery times, modern software is assembled from deep stacks of prefabricated libraries, frameworks, runtime environments, and operating system wrappers. While these abstractions dramatically shorten initial development time, they obscure what the underlying hardware is actually being asked to execute. A straightforward task that conceptually requires only a few arithmetic instructions can end up invoking thousands of intermediate function calls, dynamic memory allocations, and boundary crossings between distinct system layers. Hardware speed is routinely traded away to buy developer convenience and shorter time-to-market.
The Counterexample of Lean Engineering
Wirth did not restrict his critique to abstract complaints; he demonstrated that lean alternatives were technically achievable through his work on the Oberon operating system and programming language. Conceived alongside Jürg Gutknecht, Project Oberon sought to prove that an entire modern workstation environment—complete with a graphical user interface, text editor, compiler, file system, and network protocols—could be implemented by a tiny team within an astonishingly small memory footprint. The entire Oberon system required only a tiny fraction of the memory demanded by commercial operating systems of its era, yet it booted in seconds and ran with remarkable responsiveness on modest hardware.
The success of Oberon proved a vital point: software bloat was neither a natural law of physics nor an unavoidable byproduct of advanced digital capabilities. It was the consequence of specific engineering choices, architectural conventions, and institutional priorities. By prioritizing strict modularity, ruthless elimination of unnecessary features, and clean mathematical foundations in language design, Wirth demonstrated that high functionality and extreme economy could coexist. However, Oberon also highlighted why lean software remained rare: building lean systems demands far higher individual discipline, rigorous architectural foresight, and a willingness to say no to non-essential additions.
Related Formulations and the Modern Landscape
The dynamics formalized by Hawes and Wirth spawned several related adages reflecting identical frustrations across different eras of computing. In the 1990s, observers coined 'Gates's Law,' positing that the commercial speed of software halves roughly every eighteen months, cleanly canceling out the gains of Moore's Law. Technologist Nathan Myhrvold memorably described software as functioning like a gas: it naturally expands to fill the entire volume of its container, regardless of how large that container happens to be. In hardware engineering circles, David May formulated May's Law, cautioning that code efficiency drops at twice the rate that hardware improves, suggesting an even steeper divergence.
In the contemporary computing environment, the relevance of these observations has only magnified. The migration of desktop applications to browser-based frameworks, the rise of heavily nested mobile runtimes, and the widespread practice of bundling entire headless browsers to run simple standalone utilities have pushed memory and processor demands to unprecedented heights. Although modern devices process billions of instructions per second, developers and end-users still contend with basic operational lag, draining batteries, and runaway memory usage. Hawes's 1965 diagnosis and Wirth's 1995 formalization remain enduring reminders that hardware capability defines only the potential of a machine; the discipline of the software determines the reality.
Key takeaways
•As early as 1965, Mary K. Hawes identified the tendency of computer software to expand and consume all available memory regardless of hardware capacity.
•Niklaus Wirth formalized this phenomenon in 1995 as Wirth's Law, stating that software becomes slower more rapidly than hardware becomes faster.
•Software bloat is primarily driven by feature creep, deep layers of abstraction, and commercial incentives that prioritize rapid development over efficient code.
•Projects like Wirth's Oberon demonstrated that lean, highly responsive software is technically feasible when simplicity and strict modularity are enforced.