Unless work is done

Every codebase deteriorates. Usually not through neglect, and rarely through incompetence. Each feature solves a real problem and leaves behind another path, dependency or exception for the next person to understand. Anyone who has maintained the same system for a few years feels it in their bones, and then sees it in the estimate for the next small change.

The usual explanation is entropy. Disorder increases, the universe is against you, and there is nothing to be done except say so at four in the afternoon. It is satisfying. It is also the wrong explanation for what makes software harder to change.

Meir Lehman, a computer scientist who spent his career studying how software changes, followed programs from one release to the next for years. In 1980 he published five laws of program evolution in the Proceedings of the IEEE, the engineering profession's own journal and about as glamorous as that sounds. The first two belong together.

His first law says that a program in real use must keep changing or become progressively less useful. Users change, organisations change, and the world around the program changes. Standing still is not an option.

That sentence is dense. In plain English: useful software has to change, and each change tends to make the next one harder. The only way out is to spend some of the same time simplifying the system again.

The important clause is "unless work is done to maintain or reduce it." The work is dull and specific. It is removing obsolete paths, simplifying interfaces, strengthening tests and paying back shortcuts before the next feature sits on top of them.

Lehman noticed the physics analogy himself. In 1980 he suggested that software complexity and thermodynamic entropy might reflect some broader natural rule. He did not name it then. He did something more useful later: he kept measuring.

By 1996, five laws had become eight, and his new eighth law put feedback at the centre. A working program changes the world around it. Users and managers respond with new demands; developers change the program again; every round adds interactions and dependencies. The loop keeps turning, which is a better explanation than the universe being annoyed with your repository.

A team has limited time. It can spend it adding capability, or on what Lehman called anti-regressive work: restructuring and simplifying what earlier changes left behind. Fill the plan with visible additions and the maintenance work does not happen by itself. The backlog has yet to refactor itself.

Software will keep changing because the world around it keeps changing. Lehman's useful point is that growing complexity is not the unavoidable price of that change. It is what happens when the work of simplifying is left out. The law never says "everything decays." It is "unless work is done."