Lehman's law of continuing growth

State that a long-lived software system must continually expand its functional content to retain users, because satisfaction is judged against a rising competitive reference point — adaptation alone holds fitness constant while rivals grow past it.

Version

v3 · 2026-09-28 · History

Domain-specific #

624

Domain group

Applied Sciences & Engineering

Origin domain

Computer Science & Software Engineering

Subdomains

Information Technology, Software Engineering → Computer Science & Software Engineering

Core Idea

Lehman's sixth law — continuing growth — is the empirical observation that an E-type software system's functional content must be continually increased over its lifetime to maintain user satisfaction. The first law requires only defensive adaptation to preserve fit as the environment drifts; the sixth adds that in a field of growing competitors, adaptation alone is not enough, because users' reference point rises and satisfaction with a constant system declines. Growth is a condition of survival, in standing tension with the second law (increasing complexity).

How would you explain it like I'm…

Keep Adding New Toys

Imagine your favorite toy shop never gets new toys, while the shop next door keeps adding cool ones. Your shop didn't get worse, but kids start going next door. A computer program that people use is the same: it has to keep adding new things, or people leave for programs that offer more.

Grow or Get Left Behind

Lehman's law of continuing growth says that a computer program people rely on has to keep gaining new features for as long as it is used, or users become less happy with it. This is not because the program got worse. It is because other programs keep getting better, so people start expecting more. If the gap gets big enough, they switch to a different program. There is a catch: every new feature also makes the program more complicated, so programmers need to clean things up from time to time.

Competitive Feature Growth Law

Lehman's law of continuing growth is an observation about real-world software: its functional content must keep increasing over its lifetime to keep users satisfied. It goes further than Lehman's first law, which only says a system must be adapted to stay as useful as it is while its environment changes. Growth is needed because competing systems keep growing, so users' expectations rise. A program with a frozen feature set loses satisfaction not because it changed, but because what it is compared against did. Once the gap is bigger than the hassle of switching, users leave. Growth also makes a system more complex, so periodic restructuring becomes the usual way to balance growth against complexity.

 

Lehman's law of continuing growth is the sixth of Lehman's laws of software evolution. It applies to E-type systems, which are programs embedded in and judged by a real-world environment. It states that their functional content must be continually increased to maintain user satisfaction. Where the first law requires adaptation just to preserve fitness as the environment drifts, the sixth adds a competitive mechanism. Peer systems grow their capabilities, users' reference point moves upward, and a system with a fixed feature set loses satisfaction relative to that rising comparison set. When the capability gap exceeds users' switching cost, they migrate. Growth is therefore a survival condition in any market with developing alternatives, not merely a preference. Long-term evidence includes the line-count growth of the Linux kernel, the feature histories of Apache and GCC, and Microsoft Office's competitive expansion. The law is in tension with the second law, increasing complexity, because each increment of growth adds complexity. Interleaved refactoring cycles are the characteristic way to resolve that tension.

Scope of Application

The law lives within software engineering — the software-evolution, product-strategy, and architecture subfields where long-lived E-type systems compete for users; its reach is bounded there.

• Empirical software evolution — the home turf: Linux kernel growth (Godfrey and Tu), Apache, GCC.
• Software product strategy — reframing feature growth as a survival condition where alternatives exist.
• Roadmap and maintenance planning — splitting "keep it going" into defensive adaptation and offensive growth.
• Software architecture and refactoring — the refactor cycle read against the second law.
• Competitive-product analysis — Microsoft Office's growth driven by rivals, not per-feature demand.

Clarity

The sixth law separates two maintenance obligations a roadmap conflates: defensive adaptation (preserve fit as the environment drifts) and offensive growth (expand to keep pace with rivals). It makes a failure mode legible — a drift-corrected, bug-free system can still lose users because the competitive reference point rose. Read against the second law, it exposes a standing tension: every growth increment degrades the structure carrying it, making the refactor cycle a forced resolution, not discretionary cleanup.

Manages Complexity

A whole competitive landscape compresses into one comparative quantity — the gap between this system and the best alternative — governed by one regularity: the gap widens whenever features hold constant, and retention breaks when it exceeds switching cost. The strategist reads "retain or bleed users" off that comparison, sees "adapted but not grown → losing users" as predicted, and tracks two axes — competitive gap and structural complexity — that move oppositely under the same growth action, with the refactor cycle equilibrating.

Abstract Reasoning

The law licenses retention forecasting against a moving reference point, an adapted-but-losing diagnosis reading a healthy-yet-bleeding system as comparative rather than defective, an offensive-versus-defensive budget separation flagging a drift-only roadmap as incomplete, a two-axis tension reading that makes the refactor cycle a forced equilibrating move, and a growth-source attribution reading feature growth as competitively rather than demand driven.

Knowledge Transfer

Within software engineering the law transfers as mechanism across every E-type system facing a developing competitive field — the retention forecast, the adapted-but-losing diagnosis, the budget split, and the two-axis reading move without translation from the Linux kernel to Microsoft Office and WinZip. Beyond software the portable claim — an offering must expand or the field overtakes it — is carried by the parents Competition, red_queen_dynamic, Feature Creep, and s_curve_diffusion, which transfer as mechanism. The software-specific cargo — functional content, code coupling, the refactor cycle — stays home; the named law is the canonical software case.

Relationships to Other Abstractions

Current abstraction Lehman's law of continuing growth Domain-specific

Parents (2) — outgoing typed relations

• Lehman's law of continuing growth presupposes Competition Prime

  The law's compulsory growth presupposes rival alternatives whose gains raise the reference point and threaten user migration.

• Lehman's law of continuing growth is a decomposition of Non-Stationary Objective Prime

  The continuing-growth law is a software-market tracking problem whose functional target moves as competing systems expand.

Hierarchy paths (2) — routes to 2 parentless roots

• Lehman's law of continuing growth → presupposes Competition

Show alternative path (1)

Neighborhood in Abstraction Space

Lehman's law of continuing growth sits in a moderately populated region (53^rd percentile for distinctiveness): it has near-neighbors but no dense thicket of look-alikes.

Family — Software Evolution Laws & Code Smells (17 abstractions)

Nearest neighbors

• Lehman's law of continuing change — 0.89
• Lehman's law of conservation of familiarity — 0.88
• Lehman's law of declining quality — 0.87
• Lehman's law of conservation of organizational stability — 0.87
• Lehman's law of increasing complexity — 0.86

Computed from structural-signature embeddings · 2026-10-25