Lehman's laws of software evolution
Principle · Chapter 16
The idea in brief
Section titled “The idea in brief”- Software evolution is the process of first developing a system and then iteratively changing it.
- Starting in the 1970s, Manny Lehman and colleagues studied how software systems evolve and identified recurring behaviors now called Lehman’s laws of software evolution. Lehman is nicknamed the “father of software evolution.”
Lehman’s three software categories
Section titled “Lehman’s three software categories”In his paper Programs, Life Cycles, and Laws of Software Evolution, Lehman distinguished three system types. The laws apply only to the third (E-type).
| Type | Description | Example | Laws apply? |
|---|---|---|---|
| S-type (specifiable) | Has an exact, formal specification; correctness can be proven and a completely correct solution provided. Requirements rarely change. Simplest and rarest type. | Calculator / specific math computation | No |
| P-type (problem) | The problem can be precisely stated and an exact spec may exist, but the solution is not well understood or is impractical to fully implement (heuristics needed). | Chess program that always plays the theoretically best move | No |
| E-type (embedded) | Modeled after real-world processes and people; “embedded” in the real world, not a device. The majority of systems. Affects and is affected by the world, creating pressure to change. Must evolve to stay useful. | Most business software | Yes |
The eight laws
Section titled “The eight laws”- Continuing change — A system must change continuously or it progressively becomes less useful and satisfaction with it declines.
- Increasing complexity — As changes accumulate, complexity increases unless deliberate effort is spent to reduce it. This is software entropy (disorder rising with the number of modifications), discussed under refactoring legacy applications.
- Self-regulation — Evolution is self-regulating. Structural factors (size, complexity) and organizational factors (consensus, approvals) constrain how much change can happen, so growth inevitably slows as a system ages.
- Conservation of organizational stability — The overall rate of development stays relatively constant over a system’s life and is largely independent of the resources assigned; work output is fairly constant.
- Conservation of familiarity — The team must keep the same level of familiarity with the system to evolve it without hurting quality. Too much growth erodes familiarity, so the amount of change per release should stay roughly constant.
- Continuing growth — To remain useful, a system keeps growing in size and functionality. Related to Law II: growth in size drives growth in complexity.
- Declining quality — Quality declines unless a concerted, disciplined effort maintains it. More code means more opportunity for defects, and quality is harder to hold as size and complexity rise.
- Feedback system — Evolution is a complex feedback-driven process. Feedback from varied stakeholders must be collected, analyzed, and acted on so the system evolves toward useful improvement.
Why this matters to architects
Section titled “Why this matters to architects”- These laws justify designing for change up front rather than treating a delivered system as finished.
- Laws II, VII, and VIII directly motivate the practices in designing evolutionary architectures: managing complexity, guarding quality, and building feedback loops.
Related concepts
Section titled “Related concepts”Citations
Section titled “Citations”- Software Architect’s Handbook (Packt, 2018), Ch.16 “Lehman’s laws of software evolution”, pp. 1130-1143.