Lehman's Laws of Software Evolution
Introduction#
Between 1974 and 1996, Meir Lehman and his collaborators studied how large software systems evolve over successive releases. Their subjects included IBM OS/360, a financial trading system, and several other production systems tracked across hundreds of versions. The result was a set of empirical laws describing the forces that shape long-lived software.
These laws are not prescriptions. They describe observed regularities in how software behaves when humans maintain it over years and decades. Lehman distinguished between S-programs (formally specifiable), P-programs (approximating real-world problems), and E-programs (embedded in and changing the world they model). The laws apply specifically to E-type systems: software that operates in the real world, where requirements shift because the software’s existence changes its own environment.
The foundational publications are Lehman and Belady, “Program Evolution: Processes of Software Change” (1985) and Lehman et al., “Metrics and Laws of Software Evolution” (1997).
The Eight Laws#
I. Continuing Change#
An E-type system must be continually adapted or it becomes progressively less satisfactory.
The environment in which software operates changes continuously: business rules shift, user expectations evolve, competitor products reset baselines. Software that remains static does not remain “good enough.” It becomes progressively worse relative to its context.
This law explains why maintenance is not optional. A system that receives no changes does not stay stable. It decays in perceived value.
II. Increasing Complexity#
As an E-type system evolves, its complexity increases unless work is done to maintain or reduce it.
Each change made to accommodate a new requirement, fix a bug, or adapt to a changed environment adds structural complexity. Without deliberate effort to counteract this trend, the system’s internal structure degrades over time. Coupling increases. Naming conventions diverge. Duplicated logic appears and drifts. Dead code accumulates.
This is the entropy law. It does not say complexity might increase. It says complexity will increase unless you actively spend effort to prevent it. The default trajectory of every codebase is toward disorder.
III. Self-Regulation#
E-type system evolution processes are self-regulating with the distribution of product and process measures close to normal.
Large software projects develop their own regulatory dynamics. Release sizes, defect rates, and change volumes tend toward stable distributions over time. This happens because feedback loops (testing, code review, resource constraints, organizational risk tolerance) naturally constrain the rate of change.
The practical implication: large sudden changes to process rarely stick. Systems tend to return to their natural rhythm unless the feedback loops themselves are restructured.
IV. Conservation of Organizational Stability (Invariant Work Rate)#
The average effective global activity rate in an evolving E-type system is invariant over the product’s lifetime.
Regardless of resources allocated, the average rate of useful work on a large system tends to remain approximately constant. Adding people, changing methodologies, or increasing investment may shift output temporarily, but the system-level work rate reverts to a mean determined by organizational structure, communication overhead, and process friction.
This echoes Brooks’s Law: adding people to a late software project makes it later. The constraint is not effort but coordination capacity.
V. Conservation of Familiarity#
As an E-type system evolves, all associated with it (developers, sales, users) must maintain mastery of its content and behavior to achieve satisfactory evolution. Excessive growth diminishes that mastery.
Each release must remain comprehensible to the people who build, test, sell, and use the system. When a release changes too much at once, the collective understanding degrades and subsequent releases suffer from decisions made without full context.
This law bounds the rate at which a system can safely evolve. It is not a capability constraint but a comprehension constraint.
VI. Continuing Growth#
The functional content of an E-type system must be continually increased to maintain user satisfaction over its lifetime.
Users’ expectations grow. Competitors add features. The operational environment becomes more complex. A system that delivered adequate functionality five years ago no longer meets requirements unless its capabilities have grown proportionally.
Combined with Law II, this creates a structural tension: the system must grow (Law VI) but growth increases complexity (Law II) unless counteracted by deliberate maintenance work.
VII. Declining Quality#
The quality of an E-type system will appear to be declining unless it is rigorously maintained and adapted to operational environment changes.
This follows from Laws I and VI together. If the environment changes (Law I) and user expectations grow (Law VI), a system that does not keep pace will be perceived as declining in quality even if no bugs are introduced. Quality is relative to context, not absolute.
VIII. Feedback System#
E-type evolution processes constitute multi-level, multi-loop, multi-agent feedback systems and must be treated as such to achieve significant improvement over any reasonable base.
Software evolution is not a linear pipeline. It involves feedback loops between developers, users, testers, operations, management, and the market. Treating it as a simple input-output process (requirements in, code out) misses the dynamics that actually govern how the system changes.
Attempts to improve one metric (velocity, defect rate, coverage) without understanding the feedback loops involved will produce unexpected side effects elsewhere in the system.
The Structural Tension#
Laws II and VI together describe the central tension of long-lived software:
- The system must grow to remain relevant (VI)
- Growth increases complexity unless counteracted (II)
- Counteracting complexity requires effort that does not produce new features
This is not a problem to be solved once. It is a permanent structural condition of every E-type system. Teams that ignore Law II while pursuing Law VI accumulate entropy until the system becomes economically unviable to modify.
Constantine’s Equivalence quantifies the economic consequence: when the effort required to make each change (M) grows due to accumulated complexity, and the number of necessary changes (c) continues increasing per Law VI, total cost grows with c squared.
Limits#
Lehman’s Laws apply specifically to E-type systems: large, real-world software that operates in and changes its environment. They may not apply to:
- Small utility programs with fixed specifications
- Formal systems where requirements are mathematically specifiable
- Short-lived software that will be discarded before evolutionary pressures accumulate
The laws are empirical, not mathematical proofs. They describe observed tendencies across multiple studied systems, not inevitable outcomes for every possible codebase.
Takeaway#
These eight laws are not design advice. They are descriptions of forces that act on every long-lived system whether a team acknowledges them or not. Some are intuitive (systems must keep changing). Some are counterintuitive (adding resources does not increase the sustained work rate). Several interact in ways that create permanent tensions rather than solvable problems.
Lehman’s contribution was treating software evolution as an empirical science rather than a craft discussion. The laws give teams a vocabulary for forces they already feel but rarely name.