1980 United States / United Kingdom meta

Programs, Life Cycles, and Laws of Software Evolution

Manny Lehman, 1980 — software degrades over time. Maintenance is not a phase; it is the dominant mode.

Manny Lehman, at Imperial College London, formulated a set of empirical laws governing the evolution of large software systems based on his observations at IBM in the 1960s and his subsequent academic study. The first three laws, originally formulated in 1974: Continuing Change — an evolving system must be continually adapted or it becomes progressively less satisfactory. Increasing Complexity — as a system evolves its complexity increases unless explicit work is done to reduce it. Self Regulation — system evolution is self-regulating, with measurable rhythms. Lehman explicitly invoked the term entropy to describe the second law, drawing the analogy to the second law of thermodynamics. He also reported the figure that defines the discipline: 70% of US software expenditure in 1977 was on maintenance, 30% on new development. Software degrades. Maintenance is the work.

In plain terms

In the 1960s Manny Lehman ran a research group at IBM that was responsible for OS/360 — at the time the largest software system ever built. He noticed something that no one had named: the system was not stable. It was not just that bugs needed fixing. It was that, every release, the structure got a little worse. Modules that had been clean became tangled. Interfaces that had been crisp grew exceptions. The same engineers who had written elegant code in version one were writing baroque code in version twelve, not because they had gotten worse but because the system had. Lehman wrote it down. Software, he said, is not like hardware. Hardware sits on the shelf and degrades by oxidation. Software sits in source control and degrades by use — every change makes the next change a little harder. The complexity goes up unless somebody pays explicit cost to bring it back down. And in industry that cost almost never gets paid, because there is always a feature deadline and a customer waiting and a quarter to close. He called the phenomenon entropy on purpose. The second law of thermodynamics says ordered systems become disordered unless energy is supplied. Lehman's second law says ordered codebases become disordered unless engineering effort is supplied. The analogy is not metaphorical. The mechanism is the same: lots of small local changes, each individually rational, none of them aware of the global structure, and the global structure pays the bill. The 70/30 figure is the one to remember. In 1977, before the personal computer, before the web, before mobile, before SaaS, before AI — seventy percent of the dollars spent on software in the United States were on maintenance. Not on new features. On keeping the existing systems running. And every decade since the figure has gotten worse. This is why this book is about maintenance and not about programming. Maintenance is the work. The empirical research in chapters fifteen through twenty — GitClear, DORA, METR — is just the modern measurement of Lehman's laws under the new tooling. Software ages. Pretend otherwise and pay later.