Lehman's law of continuing change¶
The empirical software-evolution law that an E-type system — one embedded in a moving real-world environment — must be continually adapted or it progressively becomes less satisfactory, because its fitness is relational (the gap between what the code does and what the world now requires) and that gap widens monotonically while the code stands still.
Core Idea¶
Lehman's first law states that an E-type software system — one that models or is embedded in a portion of the real world — must be continually adapted or it progressively becomes less satisfactory to its users. Fitness is not intrinsic to the code but relational: the gap between what the code does and what the environment now requires. The environment moves — regulations, platforms, integration partners, expectations — so frozen code experiences a monotonically widening mismatch. The code does not rot; the world drifts away from it.
Scope of Application¶
Continuing change lives within software engineering — the empirical-software-evolution and maintenance subfields where E-type systems are operated over long lifetimes.
- Empirical software evolution — the home: the first of the eight Lehman laws, established on OS/360 data.
- Software maintenance and budgeting — reclassifying baseline maintenance as a non-negotiable line item.
- Legacy-system management — diagnosing an untouched system's decline as environmental drift, not bit-rot.
- Software-lifecycle and risk planning — exposing "ship no changes, no risk" as a provably-excluded branch.
- Software preservation — why unchanged artifacts lose usability as their runtime environment moves.
Clarity¶
The law's central clarification is that an E-type system's fitness is relational, not intrinsic. Intrinsic correctness is unchanged in frozen software; relational fitness degrades monotonically because the environment moves while the code does not. Without the law, "we shipped no changes" reads as "we incurred no risk," and drift gets misdiagnosed as bit-rot. It reframes maintenance from a discretionary activity into a non-negotiable obligation, and sharpens the manager's question to "how far has the environment drifted, and how volatile is it?"
Manages Complexity¶
The forces degrading a deployed system are heterogeneous — amended regulations, retired platforms, breaking partner changes, dropped runtimes. The law collapses that heterogeneity into a single relational quantity, the fit deficit, asserting one regularity: with code held constant, the gap only widens. The analyst tracks just two things — time-since-last-adaptation and environmental volatility — and reads the deficit off their product. By fixing the sign of the function, it eliminates the false "no change, no risk" branch, and hands the rate constraint to the companion fifth law.
Abstract Reasoning¶
The law licenses fit-deficit forecasting (reading a frozen system's prospects off time-frozen × volatility without enumerating drift sources), drift-versus-bitrot diagnosis (locating decay outside the code), and false-branch elimination (proving "no change, no risk" guarantees the deficit grows). Its interventionist reframing makes maintenance a compulsory obligation that must update the system's model of the world, not just fix defects. A direction-without-rate scoping move recognizes the law fixes only that change is compulsory, handing the increment size to the fifth law.
Knowledge Transfer¶
Within software engineering the law transfers literally across every E-type system, since the precondition — software interwoven with a moving environment, fitness relational not intrinsic — is what makes a system E-type; the forecast, diagnosis, and maintenance-obligation reframing move without translation from OS/360 to Linux to the IRS COBOL master file. Beyond software the fit-drift dynamic genuinely recurs — frozen statutes, unrevised policies, stale curricula — but as co-instances carried by the parent primes institutional_lag, coevolution, temporal_decay_and_degradation, and maintenance, which often name it better without the software framing. The E-type framing stays home.
Relationships to Other Abstractions¶
Current abstraction Lehman's law of continuing change Domain-specific
Parents (1) — more general patterns this builds on
-
Lehman's law of continuing change is a decomposition of Calibrated Rule versus Moving World Prime
Lehman's first law is the E-type-software application of a frozen mapping losing fit with a non-stationary world.
Hierarchy paths (2) — routes to 2 parentless roots
- Lehman's law of continuing change → Calibrated Rule versus Moving World → Temporal Decay and Degradation → Entropy (Thermodynamic Sense)
- Lehman's law of continuing change → Calibrated Rule versus Moving World → Temporal Decay and Degradation → Time
Neighborhood in Abstraction Space¶
Lehman's law of continuing change sits in a crowded region of the domain-specific corpus (7th percentile for distinctiveness): several abstractions share nearly its structure, so a description that fits it tends to fit its neighbors too.
Family — Software Evolution & Entropy (7 abstractions)
Nearest neighbors
- Lehman's law of increasing complexity — 0.91
- Lehman's law of declining quality — 0.90
- Lehman's law of continuing growth — 0.89
- Lehman's law of conservation of organizational stability — 0.88
- Lehman's law of conservation of familiarity — 0.87
Computed from structural-signature embeddings · 2026-07-12