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.

Version

v4 · 2026-09-19 · History · 3 corrections

Domain-specific #

623

Domain group

Applied Sciences & Engineering

Origin domain

Computer Science & Software Engineering

Subdomains

Information Technology, Software Engineering → Computer Science & Software Engineering

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.

How would you explain it like I'm…

The Old Map Problem

A computer program that helps with real-world jobs has to keep being updated, or it slowly gets less useful. The program itself does not break. The world around it keeps changing, like new rules and new machines. It is like a map of your town: if new roads get built and nobody updates the map, it gets worse and worse at helping you.

Keep Updating or Fall Behind

Lehman's law of continuing change says that software working in the real world must keep being changed, or people become less and less happy with it. The code does not wear out like an old shoe. Instead the world moves: laws change, computers get upgraded, and other programs it connects with get updated. How useful the program is depends on how well it fits the world right now. If it stays the same while everything else changes, the gap keeps growing. So people have to keep updating it, not just fixing bugs.

Software Must Track Its World

Lehman's law of continuing change is Lehman's first law of software evolution. It says an E-type system, meaning software that models or is embedded in part of the real world, must be continually adapted or it becomes progressively less satisfactory. Its fitness is relational: the gap between what the code does and what its environment now requires. Regulations, hardware, connected systems, and user expectations keep shifting, so unchanged code falls further behind each year. The code is not rotting. The world is moving away from it. A 1996 Java applet still has the same code, for example, but modern browsers can no longer load it. This law says change is required. The fifth law adds that each release can only change so much at once.

 

Lehman's law of continuing change is Lehman's first law, introduced in 1974 and restated in 1996. It is the empirical observation that an E-type system must be continually adapted or it becomes progressively less satisfactory to its users. Because an E-type system models or is embedded in a portion of the real world, its operational fitness is relational, not intrinsic to the code. Fitness is the mismatch between the system's behavior and current environmental requirements. Environments change through regulation, platforms, peer systems, and expectations. Code held constant therefore experiences a monotonically widening mismatch, which is not physical decay. Sustaining satisfaction requires ongoing investment in adaptation that updates the system's model of its world, beyond defect repair. Evidence came from the OS/360 release history. Illustrations include unloadable 1996 Java applets and the IRS Individual Master File, which needs continuous patching as tax law and integration partners shift. The first law sets the requirement for change, and the fifth law constrains its per-release rate.

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 assembly-language 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) — outgoing typed relations

• 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 → is a decomposition of Calibrated Rule versus Moving World → is a kind of Temporal Decay and Degradation → presupposes Entropy (Thermodynamic Sense)

Show alternative path (1)

Neighborhood in Abstraction Space

Lehman's law of continuing change sits in a moderately populated region (41^st percentile for distinctiveness): it has near-neighbors but no dense thicket of look-alikes.

Family — Software Evolution Laws & Code Smells (17 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-10-25