← Patterns

Lehman's Laws of Software Evolution

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 — hub for all seven laws and how they interact
• Gall’s 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).