Lehman's law of declining quality

Read software quality as the system's fit to its present environment rather than its intrinsic defect count, so an unchanged, bug-free release still degrades in the field as the surrounding world drifts away from the conditions it was built for.

Version

v2 · 2026-09-19 · History

Domain-specific #

625

Domain group

Applied Sciences & Engineering

Origin domain

Computer Science & Software Engineering

Subdomains

Information Technology, Software Engineering → Computer Science & Software Engineering

Core Idea

Lehman's seventh law (1996) observes that an E-type software system, unless rigorously adapted to its changing environment, will be perceived as declining in quality over its lifetime even when no new defects appear. The move is to read quality as relational — the system's fit to its present environment — not the intrinsic property a defect count measures. A bitwise-identical release still degrades because peers, expectations, interfaces, and threats have moved. It is the first law seen from the outside.

How would you explain it like I'm…

The Puzzle Piece That Stopped Fitting

Imagine a puzzle piece that fit perfectly last year. The piece never changed, but the puzzle around it got rebuilt, so now it doesn't fit. A computer program can start to seem worse in the same way, even with no new mistakes in it, because everything around it changed.

Same Code, Worse Fit

Lehman's law of declining quality says a program that people use will seem to get worse over time unless it keeps being updated for the world around it. That's true even if nobody adds a single new bug. Quality isn't only about the code itself. It's also about how well the program fits everything around it: other programs, websites, what users expect, and new security dangers. When those change and the program doesn't, the fit gets worse. An old web browser kept unchanged for years is a good example: it became nearly useless.

Relational Quality Decay Law

Lehman's law of declining quality separates two meanings of software quality. One is intrinsic: how few bugs the code has and whether it matches its specification. The other is relational: how well the system fits its current environment. The law says that, without rigorous adaptation, a system's perceived quality declines over time even if its code is unchanged and no new bugs were added. Partner systems change their interfaces, security threats evolve, and users compare it with newer alternatives. Internet Explorer 6 is the classic example: its code stayed the same from 2001, but by 2008 its fit to the web had collapsed. The symptoms include more complaints and more failures when it interacts with updated systems.

 

Lehman's seventh law, the law of declining quality, holds that an E-type system will be perceived as declining in quality unless it is rigorously adapted to its operational environment, even with no new defects. It separates intrinsic quality (defect count, conformance to specification) from relational quality (fit to the environment). Under the relational view, an unchanged binary degrades as peers update, expectations rise, interfaces change, and the threat landscape shifts. The law is operationally the contrapositive of the first law. The first law says the system must be continually adapted or it becomes less satisfactory. The seventh describes what 'less satisfactory' looks like from outside: rising complaints, more defects when integrating with evolved peers, and a sense of sluggishness or incompleteness next to newer alternatives. Internet Explorer 6 in 2008 is the canonical example. Studies of aging code (Eick et al.) and of Apache defect rates (Mockus et al.) show defect-encounter rates rising as the environment drifts from the conditions the system was built and tested for.

Scope of Application

Declining quality lives within software engineering — the empirical-software-evolution, software-quality, and legacy-maintenance subfields where E-type systems run in the field.

• Empirical software evolution — the home: the seventh law and field-observable contrapositive of the first.
• Software quality engineering — recasts quality as relational fit, not intrinsic defect count.
• Postmortem and incident analysis — supplies the three-channel decomposition of a complaint stream.
• Legacy-system and rejuvenation planning — selects the remedy from the dominant channel.
• Security-posture analysis — an unchanged system's standing erodes as threats and peers move.

Clarity

The law makes "quality" a relational reading — fit to the present environment — which dissolves a recurring postmortem puzzle: the system feels worse, complaints are up, yet no code shipped and no bugs appeared. It lets the analyst separate the channels feeding a rising complaint stream — new defects, environmental drift, and rising expectations — isolating the middle channel, the one that leaves no trace in the diff or bug tracker and is therefore most easily missed.

Manages Complexity

A rising complaint stream around an aging system, untreated, is a forensic puzzle with many candidate causes at once. The law compresses that phenomenology into a single relational reading — fit decays monotonically as the environment moves, independent of any new defect — making "feels worse" and "we shipped nothing" consistent. The operative compression is a fixed three-channel attribution; the analyst reads off which channel dominates, and that selection determines the remedy directly.

Abstract Reasoning

The law licenses a three-channel attribution (resolving a decline into new defects, drift, and rising expectations, then finding the dominant one), an identical-release-degrading diagnosis (reading an unchanged system's decline as environmental drift rather than phantom regression, as with Internet Explorer 6 in 2008), a remedy-selection move (matching the lever to the dominant channel), and a contrapositive coupling to the first law that yields the field-observable signature for free.

Knowledge Transfer

Within software engineering the law transfers literally across every E-type system, because the precondition — perceived quality read as fit to a drifting environment — holds for any deployed system; the three-channel attribution, the identical-release diagnosis, and the remedy-from-dominant-channel move carry without translation. Beyond software the relational-quality-decay dynamic recurs (an unchanged agency judged worse as expectations rise), but those are co-instances carried by the parent primes Temporal Decay and Degradation, Institutional Lag, Hedonic Treadmill, and reference_class_shift — not the named law. The software-specific cargo (rendering correctness, integration breakages, defect-encounter rates, rejuvenation) stays home.

Relationships to Other Abstractions

Current abstraction Lehman's law of declining quality Domain-specific

Parents (1) — outgoing typed relations

• Lehman's law of declining quality is a decomposition of Calibrated Rule versus Moving World Prime

  Lehman's seventh law frames calibrated-rule decay as user-perceived software quality loss despite unchanged intrinsic correctness.

Hierarchy paths (2) — routes to 2 parentless roots

• Lehman's law of declining quality → 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 declining quality sits in a moderately populated region (51^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 continuing change — 0.90
• Lehman's law of continuing growth — 0.87
• Lehman's law of conservation of familiarity — 0.87
• Lehman's law of conservation of organizational stability — 0.86
• Lehman's law of increasing complexity — 0.86

Computed from structural-signature embeddings · 2026-10-25