Programs, Life Cycles, and Laws of Software Evolution¶
Lehman, M. M. (1980). Programs, Life Cycles, and Laws of Software Evolution. Proceedings of the IEEE, 68(9), 1060-1076.
Cited by¶
8 citations across 8 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Compatibility
- This reasoning clarifies trade-offs before decisions are made—an analytical move Lehman (1980) made central to his laws of software evolution, where continuing change requires explicit reasoning about what compatibility guarantees survive each release.
Supported in partVerified against the publisher's abstract
The abstract establishes that Lehman introduced laws of program evolution from quantitative studies of evolving systems, but says nothing about compatibility guarantees surviving each release.
“The paper then introduces laws of Program Evolution that have been formulated following quantitative studies of the evolution of a number of different systems.”
- This reasoning clarifies trade-offs before decisions are made—an analytical move Lehman (1980) made central to his laws of software evolution, where continuing change requires explicit reasoning about what compatibility guarantees survive each release.
- Legacy Integration
- Legacy integration is not identical to continuity vs. rupture, the tension that describes whether systems maintain or break from their past, a tension Lehman (1980) formalized in his laws of software evolution where continuous change is the default condition of operating systems.
Supported in partVerified against the publisher's abstract
Lehman's 1980 abstract backs continuous, never-ending maintenance as software's default, but names no 'continuity vs. rupture' tension or operating-system scope.
“the paper identifies the sources of evolutionary pressure on computer applications and programs and shows why this results in a process of never ending maintenance activity.”
- Legacy integration is not identical to continuity vs. rupture, the tension that describes whether systems maintain or break from their past, a tension Lehman (1980) formalized in his laws of software evolution where continuous change is the default condition of operating systems.
- Maintenance
- In each case, maintenance work slows the rate of decay, requires ongoing energy input, and succeeds by maintaining a stable state rather than producing a new outcome.
Supported in partVerified against the publisher's abstract
Lehman's abstract supplies the frame of never-ending maintenance activity forced by evolutionary pressure, but says nothing of energy input, rates of decay, or a stable-state-versus-new-outcome distinction.
“the paper identifies the sources of evolutionary pressure on computer applications and programs and shows why this results in a process of never ending maintenance activity”
- In each case, maintenance work slows the rate of decay, requires ongoing energy input, and succeeds by maintaining a stable state rather than producing a new outcome.
- Temporal Decay and Degradation
Domain-specific¶
- Bit Rot
- Lehman's law of conservation of familiarity
- Lehman's fifth law — the law of conservation of familiarity, first published by Meir Lehman in 1980 and restated in the 1996 eight-law set
Supported in partVerified against the source
- Lehman's fifth law — the law of conservation of familiarity, first published by Meir Lehman in 1980 and restated in the 1996 eight-law set
Mechanisms¶
- Documentation Maintenance Review
- This is the maintenance analog of a well-known pattern in software — artifacts require continual adaptation to their changing environment or they become progressively less useful, and a rubber-stamp review only pretends to supply that adaptation.
This sourceStates that a program reflecting an external reality must continually change or become progressively less useful.
- This is the maintenance analog of a well-known pattern in software — artifacts require continual adaptation to their changing environment or they become progressively less useful, and a rubber-stamp review only pretends to supply that adaptation.
- Post-Reorganization Architecture Impact Review
- Lehman's laws of software evolution make the point structural — a system must be continually adapted to its environment or it grows progressively less fit, and an org change is exactly the environmental shift that leaves an unadapted architecture encoding a structure that is already gone.
This sourceStates that an evolving software system must be continually adapted to its environment or become progressively less satisfactory.
- Lehman's laws of software evolution make the point structural — a system must be continually adapted to its environment or it grows progressively less fit, and an org change is exactly the environmental shift that leaves an unadapted architecture encoding a structure that is already gone.
Verification¶
Does it exist? Confirmed. This work's DOI resolves to a registered record, which fixes its identity. That is all it fixes.
Does it back the claim? Read against the text for 5 of 8 citations: 5 supported in part. Each verdict is shown under its citation below, with what in the work backs the sentence.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Registry ID ref:ebba2e804dc2 · see in the full table