§ 93
Lehman's Laws of Software Evolution
A program in real use must keep changing or grow less useful, and each change makes it more complex unless work is spent to simplify it.
Keep in mind
Budget for simplifying, not just for changing
What to do
Budget ongoing change as the normal cost of a program in use, not as an exception after launch. Reserve part of every cycle for work that reduces complexity, such as deleting dead paths and merging special cases, and track a complexity measure across releases so you see the trend before it stalls you. Freeze only what other people build on, and say so when you do.
Why it happens
A program that automates part of the world is a model of that world, and the world keeps moving: users' needs shift, the business changes, and the program's own arrival changes how people work. So the program is never finished, and each release reopens the gap between the model and what it models. Changes are made under pressure by people who do not hold the whole design in mind, so special cases and dependencies are added faster than they are removed, and the structure decays. Lehman drew the laws from watching large systems evolve over many releases, and in the same paper describes them as arising from the habits and practices of people and organizations rather than being immutable like the laws of physics.
When it stops applying
Stability Is a Feature: every change makes users relearn something and breaks someone who relied on the old behavior, so for a protocol, file format or tool that others build on, freezing the design can be worth more than keeping up with the world.
Source
Meir M. Lehman, Programs, Life Cycles, and Laws of Software Evolution (Proceedings of the IEEE, vol. 68, no. 9, 1980), Table I — Continuing Change: "A program that is used and that as an implementation of its specification reflects some other reality, undergoes continual change or becomes progressively less useful."; Increasing Complexity: "As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it."; p. 1069: the laws are "clearly not immutable, as for example, are the laws of physics" and "arise from the habits and practices of people and organizations".
Read the sourceCite this
Hammurabi, § 93, “Lehman's Laws of Software Evolution.” https://kanywst.github.io/hammurabi/laws/lehmans-laws/
BibTeX
@misc{hammurabi-lehmans-laws,
title = {Lehman's Laws of Software Evolution},
author = {{Hammurabi contributors}},
note = {Hammurabi, § 93},
url = {https://kanywst.github.io/hammurabi/laws/lehmans-laws/}
}Read in a column
- Living with old code Next in the column: Technical Debt
Related laws
- 92Technical DebtCode shipped before the team fully understands the problem charges extra on later changes to that code until someone rewrites it.
- 29Boy Scout RuleCode decays because cleanup tends to be deferred to a refactor that rarely happens.
- 90Strangler FigReplacing a live system piece by piece around its edges is usually safer than replacing it all at once.