Skip to content

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.

Core Idea

Lehman's sixth law — the law of continuing growth, formulated in 1991 and incorporated into the 1996 restatement — is the empirical observation that the functional content of an E-type software system must be continually increased over its operational lifetime in order to maintain user satisfaction. The first law establishes that a system must be adapted merely to preserve its current level of fitness as the environment drifts; the sixth law adds a stronger requirement: in a field where competing systems also grow their capability, adaptation alone is not enough — functional content must expand or users migrate to alternatives that offer more. The dynamic is competitive: if a deployed system holds its feature set constant while peer systems extend theirs, users' reference point shifts upward, their satisfaction with the constant system declines not because it changed but because the comparison set did, and eventually the gap between what the system offers and what users can obtain elsewhere exceeds their switching cost. Growth is therefore not a preference but a condition of long-run survival in any market where alternatives exist and continue to develop. Longitudinal evidence comes from Linux kernel line-count growth across twenty-five years (documented by Godfrey and Tu in 2000 and extended subsequently), Apache and GCC feature trajectories, and commercial cases such as Microsoft Office's three-decade expansion of its feature set driven by competition with Apple iWork and later Google Workspace rather than by incremental user demand for specific features. The sixth law creates a structural tension with the second law (increasing complexity): each increment of functional growth adds coupling, code paths, and conceptual surface, so a growing system becomes progressively more complex unless restructuring work is interleaved — making the refactor cycle the characteristic resolution of the growth-versus-complexity pressure that the sixth and second laws together impose.

Structural Signature

Sig role-phrases:

  • the deployed E-type system — a long-lived system whose user satisfaction is judged in a competitive field, not against its own past
  • the functional-content metric — the features, capabilities, and supported use cases whose quantity the law tracks
  • the growing competitor field — the peer systems whose own expanding capability sets the moving reference point users measure against
  • the switching cost — the threshold the system-to-best-alternative gap must exceed before users migrate
  • the comparative gap — the distance between this system's functional content and the best available alternative, which widens whenever the system holds its features constant
  • the offensive-growth requirement — the monotonic feature expansion forced for long-run survival, distinct from the first law's defensive adaptation
  • the complexity cost — the coupling, code paths, and conceptual surface each growth increment adds, per the second law
  • the refactor cycle — the periodic restructuring interleaved to keep the competitive gap and the structural complexity both in bounds

What It Is Not

  • Not the first law restated. The first law requires defensive adaptation — change merely to preserve fit as the environment drifts. The sixth adds a stronger, distinct obligation: offensive growth of functional content to keep pace with what rivals now offer. A system can satisfy the first (perfectly drift-corrected, bug-free) and still fail the sixth, losing users to a growing competitor.
  • Not demand-driven feature accumulation. The growth is forced by the competitive reference point, not by users articulating need for specific features — which is why functional content expands while the marginal user exercises only a fraction of it. Attributing the expansion to per-feature demand misreads its driver; the system grows to match what alternatives offer, not what users requested.
  • Not an unconditional imperative. The requirement holds only in a field where alternatives exist and continue to develop. Where there is no live, growing competitor, the comparative gap does not widen and the survival pressure is absent. Growth is a condition of survival in a competitive field, not a property of software as such.
  • Not free. Each growth increment adds coupling, code paths, and conceptual surface, so the same expansion that retains users degrades the structure carrying it (the second law). Reading growth as costless misses the standing tension the sixth and second laws impose together — and the periodic refactor cycle that is its forced resolution.
  • Not growth in code size. The quantity that must increase is functional content — features, capabilities, supported use cases measured against the best alternative — not lines of code. A system can grow in size without closing the competitive gap, or close it while restructuring holds size in check; the law tracks capability relative to the field, not bulk.

Scope of Application

Continuing growth lives within software engineering — the empirical-software-evolution, product-strategy, and software-architecture subfields where long-lived E-type systems compete for users — and its reach is bounded there; the competitive-expansion pressure recurs in product lines, legal codes, and curricula, but those are co-instances carried by competition, red_queen_dynamic, and s_curve_diffusion, not the named law transferring.

  • Empirical software evolution — the home turf, where the law is the sixth of the eight Lehman laws; Linux kernel line-count growth across twenty-five years (Godfrey and Tu) and Apache and GCC feature trajectories supply the longitudinal evidence.
  • Software product strategy — reframes feature growth from optional polish into a survival condition wherever live alternatives exist, since satisfaction is judged against a rising competitive reference point rather than the product's own past.
  • Roadmap and maintenance planning — splits "keep the product going" into defensive adaptation (the first law) and offensive growth (the sixth), flagging a drift-corrected, bug-free system that funds no feature growth as structurally incomplete.
  • Software architecture and refactoring — read against the second law (increasing complexity), makes the periodic refactor cycle legible as the forced interleaving that keeps both the competitive gap and the structural complexity in bounds, not as discretionary cleanup.
  • Competitive-product analysis — attributes observed feature expansion to the competitive reference point rather than per-feature demand; Microsoft Office's three-decade growth, driven by competition with iWork and later Google Workspace while the marginal user exercises a fraction of the features, is the exemplar, with the frozen WinZip losing the market the contrasting case.

Clarity

The sixth law's clarifying work is to separate two maintenance obligations that a roadmap conversation routinely collapses into one undifferentiated "keep the product going": defensive adaptation, which preserves a system's fit as its environment drifts (the first law), and offensive growth, which expands its functional content to keep pace with what competing systems now offer. They draw on different budgets and answer to different pressures, and conflating them hides a failure mode — a system that is diligently drift-corrected, bug-free, and perfectly adapted to its original mission can still be losing users, because adaptation alone holds fitness constant while the competitive reference point keeps rising. Naming the law makes that loss legible as a comparative phenomenon: satisfaction with a constant feature set declines not because the system changed but because the comparison set did, and the relevant gap is the one between this system and the alternatives, measured against switching cost.

The sharper question it licenses is not "does our system still do its job?" but "is its functional content keeping pace with the field, and is the gap to the best alternative approaching what users will pay to switch?" — which reframes feature growth from optional polish into a survival condition wherever live alternatives exist. Just as importantly, the law does not stand alone: read against the second law (increasing complexity), it exposes a standing tension rather than a free lunch — every growth increment adds coupling, code paths, and conceptual surface, so the same expansion that retains users degrades the structure carrying it. That pairing is what makes the periodic refactor cycle legible as the characteristic resolution of a growth-versus-complexity pressure, not as discretionary cleanup a team could skip.

Manages Complexity

To judge whether a long-lived system will retain its users, a strategist would otherwise have to survey a whole competitive landscape: which peer products are adding which capabilities on what cadence, how each new feature elsewhere shifts what users now consider baseline, how far each user's expectations have moved, and how all of that nets against the cost of switching. The sixth law compresses that landscape into a single comparative quantity — the gap between this system's functional content and the best available alternative — governed by one regularity: in any field where alternatives exist and continue to develop, that gap widens whenever the system holds its feature set constant, because the users' reference point rises even though the system did not change, and retention breaks when the gap exceeds switching cost. The strategist does not have to model every competitor's roadmap; those collapse into the single moving reference point the deployed system is measured against. The qualitative outcome — retain or bleed users — is read off one comparison: is functional content keeping pace with the field, and is the gap to the best alternative approaching what users will pay to leave?

That comparative framing already separates a branch the raw "is the product still working?" question hides — a system can be perfectly drift-corrected and bug-free (the first law's defensive adaptation satisfied) and still be on the losing branch, because adaptation holds fitness constant while the competitive reference point climbs. So the analyst reads "adapted but not grown → losing users" as a predicted state rather than a paradox. The deeper compression is that the sixth law does not stand alone but is read against the second law (increasing complexity) as a standing tension: every growth increment that closes the competitive gap simultaneously adds coupling, code paths, and conceptual surface, degrading the very structure that carries the features. The two laws together yield a two-axis reading — competitive gap and structural complexity move in opposite directions under the same growth action — and the characteristic resolution, the periodic refactor cycle, becomes legible as the forced interleaving that keeps both axes in bounds, not as discretionary cleanup. A sprawling competition-and-architecture problem reduces to tracking one gap against switching cost and one complexity cost against restructuring capacity, with the refactor cycle as the known equilibrating move between them.

Abstract Reasoning

The law of continuing growth licenses reasoning moves built on one comparative quantity — the gap between this system's functional content and the best available alternative — and one threshold, the user's switching cost.

Retention forecasting against a moving reference (predictive): The characteristic move treats user satisfaction as governed not by the system's own feature set but by its position relative to a competitive reference point that rises as peer systems grow. Given a deployed system holding its features constant in a field where alternatives keep developing, the engineer predicts declining satisfaction — not because the system changed but because the comparison set did — and forecasts user migration once the gap to the best alternative exceeds switching cost. The reasoning runs FROM (constant feature set, growing competitors, switching cost) TO a retention outcome, without modeling every competitor's roadmap: the whole field collapses into the single moving reference point the system is measured against.

Adapted-but-losing diagnosis (diagnostic): Confronted with a system that is diligently drift-corrected, bug-free, and perfectly fitted to its original mission yet still bleeding users, the move is to diagnose the loss as comparative rather than as a defect or a fitness failure. The law lets the engineer reason FROM the surface paradox (healthy system, declining share) TO the cause: the first law's defensive adaptation holds fitness constant, but the sixth law's competitive reference point has climbed past it. "Adapted but not grown → losing users" is read as a predicted state, not an anomaly — so the remedy is sought in functional expansion, not in further bug-fixing or drift-correction. The frozen WinZip losing the market to growing competitors is the move applied: nothing broke; the field moved.

Offensive-versus-defensive budget separation (interventionist/boundary-drawing): The move splits "keep the product going" into two obligations drawing on different budgets — defensive adaptation (preserve fit as the environment drifts, per the first law) and offensive growth (expand functional content to keep pace with competitors, per the sixth). The reasoning runs FROM a maintenance plan TO the recognition that satisfying only the defensive obligation leaves the offensive one unmet, so a roadmap that funds drift-correction but not feature growth is diagnosed as structurally incomplete wherever live alternatives exist. The intervention lever is explicit: in a competitive field, functional content must monotonically grow or share erodes, so feature growth is reclassified from optional polish into a survival condition.

Two-axis tension reading and the refactor cycle (interventionist/boundary-drawing): Read against the second law (increasing complexity), the sixth law yields a move that tracks two axes moving in opposite directions under the same growth action — every increment that closes the competitive gap simultaneously adds coupling, code paths, and conceptual surface that degrade the structure carrying it. The reasoning runs FROM a growth action TO its dual consequence (gap narrows, complexity rises), and the characteristic resolution is to interleave restructuring so both axes stay in bounds. This makes the periodic refactor cycle legible as the forced equilibrating move between retaining users and containing complexity — not as discretionary cleanup a team could skip. The move predicts the refactor cycle's existence in any long-lived growing system as the necessary consequence of the two laws acting together.

Growth-source attribution (diagnostic): A characteristic discrimination is reading observed feature growth as competitively driven rather than demand-driven. When a system's functional content expands while the marginal user exercises only a small fraction of it, the move attributes the growth to the competitive reference point (matching what rivals offer) rather than to specific user requests. Microsoft Office's three-decade expansion, driven by competition with iWork and later Google Workspace rather than by incremental demand for particular features, is the move's exemplar: the reasoning runs FROM the mismatch between feature count and per-user utilization TO the inference that survival-in-the-field, not articulated need, is the growth driver.

Knowledge Transfer

Within software engineering the law transfers as a working mechanism across every E-type system that faces a developing competitive field, and the transfer is literal because the precondition — a deployed system whose user satisfaction is measured against live, growing alternatives separated from it by a switching cost — is the standing condition of any such system in a market. The retention forecast, the adapted-but-losing diagnosis, the offensive-versus-defensive budget split, and the two-axis growth-versus-complexity reading move without translation from the Linux kernel's twenty-five-year line-count growth (Godfrey and Tu) through Apache and GCC feature trajectories to the commercial cases — Microsoft Office's three-decade expansion driven by competition with iWork and later Google Workspace rather than by per-feature demand, and the frozen WinZip losing the market to growing rivals. What carries across these substrates is the comparative gap-against-switching-cost quantity, the moving competitive reference point, and the standing tension with the second law that makes the refactor cycle the characteristic resolution; the vocabulary travels because the referent — functional content of a system measured against the best available alternative — is the same in each case. The sixth law is the software-evolution operationalization of a competitive-growth pressure, and within software that operationalization is what gives it predictive bite.

Beyond software the situation is again a shared abstract mechanism carried by the parent primes, not by Lehman's sixth law as named — with the looser invocations being analogy. The portable claim underneath the law — that in a competitive environment an offering must continually expand or the field overtakes it, because satisfaction is judged against a rising reference point rather than against the offering's own past — really does recur across domains, and the recurrence is mechanistic where genuine competition with developing alternatives is present: product lines that must keep adding capability or cede share, legislative or regulatory codes that accrete provisions to match peer jurisdictions, curricula that expand to keep pace with the field. But these are co-instances of the more general patterns the law instantiates — competition and red_queen_dynamic (the upstream pressure of running to stay in place against rivals who are also improving), feature_creep (the pathological extreme of the same growth dynamic), and s_curve_diffusion (the lifecycle envelope within which the growth plays out) — and it is those primes, not Lehman's sixth, that carry the lesson cross-domain. The home-bound cargo is the software-specific content: that the growing quantity is functional content measured in features and supported use cases, that the cost side is code coupling and conceptual surface tracked by the second law, and that the equilibrating move is a code refactor cycle. When the law is reached for outside software, that is a fresh instance of the parent primes — recognized by re-derivation, renaming "functional content" to whatever the offering trades in — not the named law transferring. So the honest instruction is that the cross-domain lesson should be carried by competition, red_queen_dynamic, and s_curve_diffusion, which transfer as mechanism; "Lehman's law of continuing growth," as named, stands as the canonical software case of competitively-forced expansion, paired with the second law to make the growth-versus-complexity refactor cycle legible. (See Structural Core vs. Domain Accent.)

Examples

Canonical

The law's clearest longitudinal evidence is Godfrey and Tu's 2000 study of the Linux kernel. Tracking the kernel's source size across successive releases from the mid-1990s onward, they found not a plateau but sustained growth — the development kernel expanding continuously, at a rate that over the study window was at least linear and in fact super-linear rather than tapering off as a maturing system "should." Each release added drivers, filesystems, architectures, and subsystems, steadily enlarging the kernel's functional content year over year. This directly instantiates the sixth law: an actively used E-type system does not settle at a fixed feature set but must keep enlarging its capability to remain the kernel people choose, in a field where BSD variants and commercial Unixes were themselves developing. The measured, multi-year climb is the law made visible.

Mapped back: The Linux kernel is the deployed E-type system, and the drivers, filesystems, and subsystems it accretes are the functional-content metric. BSD and commercial Unixes are the growing competitor field whose own development sets the moving reference point. The refusal to plateau — the continual, super-linear enlargement — is the offensive-growth requirement enacted, expansion demanded by remaining a viable choice rather than by any single articulated need.

Applied / In Practice

Microsoft Office is the commercial case the sixth law reads cleanly. Across three decades Office continuously expanded its feature set — from basic word processing and spreadsheets to real-time co-authoring, cloud sync, and web and mobile versions — even though surveys consistently find the average user touches only a small fraction of the available features. The expansion tracks the competitive frontier rather than articulated per-feature demand: co-authoring and cloud storage were added as Google Workspace made browser-based collaboration the new baseline, and cross-platform apps answered Apple iWork and mobile-first rivals. A product manager applying the law would read Office's growth not as gold-plating but as offensive growth — hold the feature set constant and the rising competitive reference point erodes satisfaction until the gap to Workspace exceeds users' switching cost. The continual additions are a survival condition in a field of developing alternatives, not optional polish.

Mapped back: Office is the deployed E-type system; its accumulating capabilities are the functional-content metric. Google Workspace and iWork constitute the growing competitor field that raises the reference point, so the widening comparative gap against the switching cost is what a frozen Office would face. That users exercise only a fraction of the features is the growth-source attribution: the expansion is the offensive-growth requirement answering rivals, not demand.

Structural Tensions

T1: Offensive growth versus feature bloat (the survival imperative and its pathology are the same act). The law reclassifies feature growth from optional polish into a survival condition — hold the feature set constant and the rising reference point erodes satisfaction until the gap exceeds switching cost. But the very expansion that retains users is, one increment too far, feature_creep: capability the marginal user never touches, added to match a rival rather than to serve a need. There is no clean line in the act itself between growth-that-retains and growth-that-bloats, because both are "add functional content to close the competitive gap"; the difference is only whether the addition tracks a reference point users actually weigh or one the product team imagines. The same law that forbids standing still can license accretion that degrades the product it means to save. Diagnostic: Is this increment closing a gap to an alternative users would actually switch to, or padding the feature count against a reference point no user is measuring?

T2: Growth-versus-complexity (the two-axis pull the sixth and second laws impose together). Every increment that narrows the competitive gap simultaneously adds coupling, code paths, and conceptual surface — the two axes move in opposite directions under the same growth action. This is the law's own named tension, and it has no dissolution, only equilibration: grow fast enough to retain users and complexity accumulates faster than it can be tamed; interleave enough restructuring to contain complexity and growth slows below the field's cadence. The refactor cycle is the forced move between them, but the refactor budget competes directly with the growth budget for the same engineering capacity. A team is perpetually choosing how much retention to trade for how much structural health, with no setting that buys both. Diagnostic: Is the current growth rate outrunning the restructuring capacity needed to carry it, and is the refactor cycle being funded or deferred into accumulating debt?

T3: Offensive versus defensive budget split (a clean separation that competes for one purse). Naming the two obligations — defensive adaptation to preserve fit, offensive growth to keep pace — exposes a failure mode the undifferentiated "keep the product going" hides: a diligently drift-corrected, bug-free system still bleeding users. The clarity is real. But the split is conceptual; both draw on the same finite maintenance budget, so surfacing the offensive obligation does not create resources to fund it. A team that recognizes it must grow to survive still has to take that budget from adaptation, bug-fixing, or restructuring, and over-weighting offense can leave the defensive fit to rot. The law tells you both obligations are live; it does not tell you the ratio, and the recognition can drive growth at the expense of the stability that growth needs. Diagnostic: Is offensive growth being funded by genuinely new capacity, or by starving the defensive adaptation that keeps the existing system fit?

T4: Moving reference point versus finite user appetite (competitors set the pace, but users can saturate). The law's engine is that satisfaction is judged against a rising competitive reference point, so a constant product loses ground as rivals grow. But it treats the reference point as monotonically climbing, when user appetite for functional content is not unbounded — a market can reach a point where additional features add no perceived value, where simplicity itself becomes the competitive axis, and a leaner alternative overtakes the feature-maximal incumbent. The frozen-WinZip diagnosis assumes the field always rewards more; sometimes it rewards less. The law's competitive-growth pressure is real where the reference point rises, but reading every retention loss as a call for more functional content can miss the moment the field turned against accretion. Diagnostic: Is the field's reference point still rising in functional content, or has it inverted toward simplicity such that further growth widens rather than closes the gap?

T5: Field-conditioned scope versus universal imperative (the law binds only where live rivals develop). The requirement is explicitly conditional: growth is a survival condition in a field where alternatives exist and continue to develop. That conditionality is what keeps the law honest — a system with no live, growing competitor faces no widening comparative gap and no survival pressure to grow. But the law's rhetorical force ("must continually increase") invites reading it as a property of software as such, driving growth in monopoly niches, internal tools, or mature stable markets where the reference point is not moving and the growth only buys complexity. The imperative that is genuinely binding under competition becomes a self-imposed treadmill where the precondition is absent. Diagnostic: Does this system actually face live alternatives that are themselves developing, or is the growth pressure being manufactured where no rising reference point exists?

T6: Autonomy versus reduction (its own named law or the software instance of its parents). "Lehman's sixth law" is a named, canonically studied regularity with proprietary content — functional content measured in features and use cases, the code-coupling cost tracked by the second law, the refactor cycle as equilibrating move — and that apparatus transfers literally across software (Linux, Apache, GCC, Office, WinZip), where the referent is the same and the vocabulary needs no translation. But beyond software the named law does not travel; what carries is the more general parents it instantiates — competition and red_queen_dynamic (running to stay in place against improving rivals), feature_creep (the pathological extreme), and s_curve_diffusion (the lifecycle envelope). A legal code that accretes provisions to match peer jurisdictions or a curriculum that expands to keep pace is a fresh instance of those primes, recognized by re-deriving the pressure and renaming "functional content," not the law transferring. The tension is between a standalone software law that earns its own name and second-law pairing and the recognition that its cross-domain cargo already belongs to competition, the red-queen dynamic, and diffusion. Diagnostic: Resolve toward the parents (competition, red-queen, s-curve) when asking what carries outside software; toward "Lehman's sixth law" when diagnosing a specific long-lived system's retention against a growing field.

Structural–Framed Character

Lehman's law of continuing growth sits at mixed on the structural–framed spectrum — like its sibling continuing-change, its core dynamic (running to stay in place against improving rivals) is substrate-neutral and recurs in nature, but the named law is software-and-market-bound.

Evaluative weight is nil-to-low and points structural. The law is a descriptive competitive regularity — grow or the field overtakes you — that grades nothing; even "less satisfactory" is a relational claim about a moving reference point, not a verdict.

Human-practice-bound is split, tilting the entry toward the structural side of mixed. The named law lives in a human-institutional substrate — software markets, features, switching costs, product roadmaps. But its core dynamic is the red-queen pattern (satisfaction judged against a rising reference point, so standing still loses ground), which runs observer-free in nature as biological arms races and coevolutionary escalation. So the mechanism needs no human practice in general; only its software-market instantiation is practice-bound.

Institutional origin is mixed: the named law is Lehman's sixth, a discipline-born construct, while the competition/red-queen dynamic it points at is a general pattern of nature and markets, not an institutional invention. Vocab-travels is likewise split — functional content, feature set, switching cost, refactor cycle are software-bound, while the abstract competitive-escalation dynamic travels freely. Import-vs-recognize is bimodal in the entry's terms, tilting structural: cross-substrate appearances (legal codes accreting provisions to match peers, curricula expanding to keep pace) are co-instances "recognized by re-derivation" where genuine competition with developing alternatives is present — mechanism, not mere metaphor.

The portable structural skeleton is in a competitive field where rivals keep improving, an offering must continually expand or the rising reference point overtakes it — running to stay in place — carried by red_queen_dynamic and competition (the escalation pressure), with feature_creep (the pathological extreme) and s_curve_diffusion (the lifecycle envelope) as neighbors. As the entry establishes, that skeleton is what continuing growth instantiates in a software register, not what makes "Lehman's sixth law" itself travel: the cross-domain reach belongs to those parents, while the domain-accented cargo — functional content in features, the second-law coupling cost, the refactor cycle — stays home. Its character: a substrate-neutral, evaluatively neutral competitive-escalation (red-queen) mechanism (recognized across markets and nature) wearing software-evolution vocabulary and a named-law identity, structural at its core but pinned by that software-market cargo to mixed rather than a free-floating prime.

Structural Core vs. Domain Accent

This is the section that settles why continuing growth is a domain-specific abstraction and not a prime — and it carries, in the same breath, the case for why it counts as domain-specific at all.

What is skeletal (could lift toward a cross-domain prime). Strip the software and a thin relational structure survives: an offering competes in a field where rival offerings keep improving; satisfaction with it is judged against a reference point set by the best available rival rather than against its own past, so holding capability constant lets that reference point climb past it, and only continual expansion keeps pace — running to stay in place. The portable pieces are abstract: a set of competing offerings, a comparative gap between one offering and the field's frontier, a reference point that rises with rivals' improvement rather than sitting fixed, and a switching threshold beyond which the disadvantaged offering is abandoned. That skeleton is genuinely substrate-portable — which is exactly why it recurs in the catalog as red_queen_dynamic and competition, the escalation pressure the law instantiates, with feature_creep naming the pathological extreme and s_curve_diffusion the lifecycle envelope. But it is the core the law shares, not what makes it distinctive.

What is domain-bound. Almost all the worked content is software-engineering furniture, and none of it survives extraction intact. The growing quantity is specifically functional content — features, capabilities, supported use cases of an E-type system — not capability in the abstract; the cost side is code coupling, code paths, and conceptual surface tracked by the second law of increasing complexity; the characteristic equilibrating move is a code refactor cycle interleaved to hold both the competitive gap and structural complexity in bounds; and the empirical cases are the Linux kernel's line-count growth (Godfrey and Tu), Apache and GCC feature trajectories, Microsoft Office's three-decade expansion against iWork and Workspace, and frozen WinZip losing its market. The decisive test: remove the E-type-system substrate and the second-law coupling cost, and the "refactor cycle" has nothing to restructure and "functional content" nothing to count — what remains is a looser competitive-escalation claim, no longer this law but the bare pressure it instantiates.

Why this does not clear the prime bar. A prime is a relational structure whose vocabulary travels and whose cross-domain transfer is recognition of the same mechanism, not analogy. Continuing growth's transfer is bimodal. Within software the mechanism travels intact across every E-type system facing a developing field — the retention forecast, the adapted-but-losing diagnosis, the offensive-versus-defensive budget split, and the two-axis growth-versus-complexity reading move without translation from the Linux kernel through Apache and GCC to Office and WinZip, because each substrate supplies the same referent: functional content measured against the best available alternative, separated by a switching cost. Beyond software it travels only by renaming the traded quantity — a legal code accreting provisions to match peer jurisdictions, a curriculum expanding to keep pace with its field — which is a fresh instance recognized by re-deriving the pressure and swapping "functional content" for whatever the offering trades in, not the named law carrying over. And when that bare competitive-escalation lesson is needed cross-domain, it is already supplied, in more general form, by the primes the law instantiates: running to stay in place against improving rivals is red_queen_dynamic under competition; the growth-turned-pathological is feature_creep; the lifecycle within which it plays out is s_curve_diffusion. The cross-domain reach belongs to those parents; "Lehman's law of continuing growth," as named, stays home as the canonical software case of competitively-forced expansion, paired with the second law to make the refactor cycle legible.

Relationships to Other Abstractions

Local relationship map for Lehman's law of continuing growthParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Lehman's law ofcontinuing growthDOMAINPrime abstraction: Competition — presupposesCompetitionPRIMEPrime abstraction: Non-Stationary Objective — is a decomposition ofNon-StationaryObjectivePRIME

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

Parents (2) — more general patterns this builds on

  • 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

Not to Be Confused With

  • Lehman's first law (continuing change). The sibling law demanding defensive adaptation — change merely to preserve fit as the environment drifts. The sixth law adds the stronger, distinct obligation of offensive growth — expand functional content to keep pace with rivals. A system can perfectly satisfy the first (drift-corrected, bug-free) and still fail the sixth, losing users to a growing competitor. Tell: is the required change to hold fitness constant against a moving environment (first law), or to increase capability against a rising competitive reference point (sixth law)?

  • Lehman's second law (increasing complexity). The cost-side law the sixth is paired against: as a system is changed, its internal complexity rises unless work is done to reduce it. It is not a growth imperative; it is what makes the sixth law's growth expensive. Together they produce the refactor cycle. Tell: is the claim that the system must grow to survive (sixth law), or that growth degrades internal structure and must be counteracted (second law)? The sixth pushes features up; the second tracks the complexity that growth incurs.

  • Feature creep / bloat. The pathological extreme of the very same growth act — capability the marginal user never touches, added past the point of value. Offensive growth (survival) and feature creep (bloat) are the same move (add functional content to close the gap); the difference is only whether the addition tracks a reference point users actually weigh. Tell: does the increment close a gap to an alternative users would switch to (offensive growth), or pad the feature count against a reference point no user is measuring (feature creep)?

  • Gold-plating / demand-driven feature accumulation. Adding unrequested polish or building features because specific users asked for them. The sixth law's growth is driven by the competitive reference point, not by articulated demand — which is why functional content expands while the marginal user exercises a fraction of it. Tell: is the feature added because a user requested it or to embellish (gold-plating/demand-driven), or to match what rivals now offer regardless of per-feature demand (continuing growth)?

  • The parent primes it instantiates (red-queen dynamic, competition, s-curve diffusion). The substrate-neutral skeleton — in a field where rivals keep improving, an offering must continually expand or the rising reference point overtakes it (running to stay in place) — that the sixth law instantiates for software. A legal code accreting provisions to match peer jurisdictions or a curriculum expanding to keep pace is a fresh instance of these parents. Tell: strip away functional content, code coupling, and the refactor cycle and what remains is bare competitive escalation, carried by red_queen_dynamic/competition (with s_curve_diffusion as the lifecycle envelope), not Lehman's sixth law. (Treated fully in an earlier section.)

Neighborhood in Abstraction Space

Lehman's law of continuing growth sits in a crowded region of the domain-specific corpus (21st percentile for distinctiveness): several abstractions share nearly its structure, so a description that fits it tends to fit its neighbors too.

Family — Software Evolution & Systemic Laws (16 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-07-12