Lehman's Laws of Software Evolution

A system in use must keep changing, and its complexity grows unless work is done to reduce it.

Complexity grows on its own as a system changes; only continuous simplification work keeps it down.

To an executive

A product in use must keep changing or it loses value, and without upkeep it gets harder and costlier to change. Budget for continuing maintenance, not only new features.

To an engineer

Plan continuous change and set aside time for simplifying, because structure decays with each release. Track complexity and fix it before it slows delivery.

The idea

Meir Lehman, working with Laszlo Belady, studied how large IBM systems changed across many releases. In his 1980 paper in Proceedings of the IEEE, he set out a set of laws of program evolution. Two of them matter most to architects:

Continuing change. A program used in the real world must keep changing, or it becomes progressively less useful.
Increasing complexity. As a program changes, its complexity grows and its structure decays, unless work is done to maintain or reduce it.

Lehman was careful to apply the laws to what he called E-type programs: software embedded in a real-world activity, whose use changes the world it serves. That covers most business systems.

Software in use is never finished. Architecture must budget for continuous change and continuous simplification.

Why it works

The world moves, so the system must. Regulations, products, users and neighbouring systems change. Software that does not follow them drifts out of fit.

Every change adds a little disorder. Each feature, fix and workaround is locally sensible, but together they erode the original structure. Without deliberate clean-up, the erosion accumulates.

Ignoring the laws does not suspend them. Teams that fund only features still pay for complexity; they just pay later, in slower delivery and riskier changes.

Where it applies

Long-lived business systems, which will be changed for years after launch.
Funding and planning conversations, to justify capacity for refactoring and upgrades.
Platform ownership, where many consumers keep adding demands.
Lifecycle management: upgrades, deprecations and retirements as ongoing work.

How to apply

Reserve capacity for simplification in every planning cycle, not as a one-off project.
Track complexity trends with a few indicators: build times, change failure rate, dependency counts, time to make a typical change.
Plan lifecycle work as routine: upgrades, deprecations and retirements on a schedule.
Explain the laws to funders so they expect ongoing cost after launch, not a finished asset.

Example scenario

An internal platform launched with a clean design and a budget only for new features. Five years later it had forty integrations, three generations of frameworks and a long upgrade backlog. Every change took weeks, and teams began building around it.

The recovery plan put a fixed share of each quarter into simplification: removing unused integrations, consolidating on one framework and retiring old interfaces. The platform's owners also agreed a lifecycle policy with funders, so the next major upgrade was planned and paid for before it became urgent.

Questions to ask

What share of our capacity goes to simplification, not just features?
Is complexity trending up, and how would we know?
What will this system need to adapt to next?

When not to use it

Short-lived or throwaway software, such as a one-off migration script or a prototype, which will not live long enough to decay.
Closed, fully specified programs, which Lehman himself excluded; their correctness does not depend on a changing world.

How it misleads you

The laws can be read as permission to accept decay as inevitable. They describe what happens without effort; they are an argument for investing in that effort. They are also tendencies observed in large systems, not physical laws, so use them to set expectations, not to excuse a specific mess.