---
title: Lehman's Laws of Software Evolution
synced_from_vault: true
vault_source: 03-living-docs/patterns/Lehmans-Laws.md
public: true
type: pattern
tags:
  - pattern
  - systems-thinking
  - tech-debt
  - architecture
aliases:
  - Lehman's Laws
  - Lehman's Laws of Software Evolution
created: 2026-02-21T00:00:00.000Z
origin: Meir Lehman (1980); applied in pipeline-skills design priorities
---

| | |
|-|-|
| **Category** | Systems Thinking / Technical Strategy |
| **Source** | Meir Lehman (1980) |
| **Surfaced in OS** | Feb 18, 2026 (atomized Feb 21) |

---

## Core Concept

> "As a system evolves, its complexity increases unless work is done to maintain or reduce it."

Software systems that are used *must* change or become progressively less useful. And as they change, complexity grows unless you actively fight it. There's no steady state — you're either simplifying or decaying.

**The key laws (from eight total):**

1. **Continuing Change:** A system must be continually adapted or it becomes progressively less satisfactory.
2. **Increasing Complexity:** As a system evolves, its complexity increases unless work is done to reduce it.
3. **Self-Regulation:** The evolution process is self-regulating — there's a natural rate of change that you can't sustainably exceed.

---

## Where It Applies

### Tech Debt
Lehman's Law is *why* tech debt exists. It's not laziness — it's entropy. Every feature addition increases complexity. Without periodic simplification passes, the system becomes unmaintainable.

### Roadmap Planning
Alternate between "add" and "simplify" phases. After a burst of new capabilities, schedule a consolidation pass. The Foundations-vs-Features playbook is a direct application of Lehman.

### Team Capacity
Some percentage of engineering time must go to fighting entropy, not building features. Teams that spend 100% on features are borrowing from the future.

### Knowledge Systems
This OS itself is subject to Lehman's Laws. Without periodic cleanup, it'll become cluttered and contradictory. Stale knowledge is worse than no knowledge.

---

## The Management Implication

Leaders who only value feature delivery and can't see the value of simplification are setting up a Lehman's Law time bomb. The system *will* become too complex to change — it's just a question of when.

---

## Cross-References

- [Software-Laws](/patterns/software-laws) — hub for all seven laws and how they interact
- [Gall's Law](/patterns/galls-law) — complementary: Gall says evolve from simple systems, Lehman says the evolution creates complexity. Together: add one thing at a time (Gall), periodically simplify (Lehman).