A system in use must keep changing; its complexity grows unless work is invested specifically to counter it. The entropy-reduction budget is a recurring line item, not “someday later.”
Meir Lehman began with a study of IBM OS/360 releases with László Belady in the 1970s and stated the laws in “Programs, Life Cycles, and Laws of Software Evolution” (Proceedings of the IEEE, 1980); the 1997 FEAST paper revisited them with more data. The first two carry most of the weight. Continuing change: a program used in the real world must be adapted or it becomes progressively less satisfactory. Increasing complexity: as it evolves, its complexity increases unless work is done to maintain or reduce it. Both apply to what Lehman called E-type systems — those embedded in a changing environment, which is almost every backend. The evidence is case studies of a few large systems, and later studies found exceptions (Godfrey and Tu, 2000, saw the Linux kernel growing faster than the laws predicted), so treat them as strong observations, not physics.
Two different claims in one card, and they carry different weight. Lehman's observations are empirical: a system embedded in a changing environment (E-type) either changes or loses its usefulness, and its structure degrades unless the work of preserving it is funded separately. “Thermodynamics,” however, is a metaphor, and it lies about the main thing: growing complexity is not a spontaneous process but the sum of locally rational decisions, each of which, taken alone, is cheaper than the right one. The physical analogy would imply “resistance is futile”; the empirical evidence implies the exact opposite: this is a budget line item, and it can be managed.
“Debt” is also a metaphor, with an author. Ward Cunningham introduced it in his OOPSLA 1992 experience report on the WyCash system: shipping code that reflects an incomplete understanding is like borrowing — fine if repaid promptly by reworking the code as understanding grows, ruinous if the interest compounds. It did not mean sloppy code. In practice the repayment is concrete: a dependency upgrade lane, a fixed share of each cycle for removals and migrations, deletion of dead paths (44). The misuse is calling every disliked design “debt” to justify a rewrite (76).