Unless work is done

Every codebase gets worse. Not through neglect exactly, and rarely through incompetence: it gets worse because it gets changed, and each change is locally reasonable and globally slightly corrosive. Everyone who has worked on anything for more than two years knows this in their hands.

The explanation everybody reaches for is thermodynamics. Entropy increases, disorder is the natural state, the universe is against you. It is a satisfying thing to say at four in the afternoon and it is doing something quietly dishonest, which is worth pulling apart, because the real finding is both older and more useful.

Meir Lehman spent the 1970s doing something almost nobody does: measuring software over time. Not opinions about software, the thing itself, release by release, across years. In 1980 he published the results in the Proceedings of the IEEE, the engineering profession's own journal and about as unglamorous and as respectable as a venue gets, as a set of laws of program evolution, and the second one is the one everybody has since paraphrased into physics.

Read the last seven words again, because they are load-bearing and they are the ones that fall off in every retelling. Unless work is done to maintain or reduce it. That is not a law of nature. That is a conditional, and the condition is a budget.

The second law of thermodynamics has no such clause. Entropy in a closed system increases and there is nothing you may do about it, which is precisely what makes it a law and precisely what makes it the wrong shape for this. A codebase is not a closed system. It has people in it. The decay is not the universe operating on your repository, it is the sum of decisions somebody made and somebody else did not get time to unmake.

And here is the part that makes the whole thing worth writing down: Lehman saw the comparison coming and declined it, in the paper, in one sentence.

He writes that increasing complexity could be seen as an instance of the second law of thermodynamics, and then says it would seem more reasonable to regard both as instances of some more fundamental truth. Which is a very polite way of saying: yes, I noticed, and no, one is not caused by the other.

That distinction is not pedantry, because the two versions produce different behaviour in a real team. If decay is thermodynamic then it is weather, and the correct response to weather is a coat and a shrug. If decay is conditional on work not being done, then it is a line item, and the reason it is not in the plan is that somebody left it out, possibly you.

The physics framing is comfortable for exactly that reason. It converts a resourcing decision into a natural phenomenon, and nobody has to be told that the refactor is not scheduled because the refactor is not scheduled.

None of which makes the pressure imaginary. Lehman's first law is that a program in real use must keep changing or become progressively less useful, so there is no version of this where you finish and stop. The pressure is constant and it is intrinsic. It is just that the outcome is not.