Skip to content

Lehman's law of increasing complexity

Observe that the structural, behavioral, and conceptual complexity of an evolving software system rises monotonically under unmanaged change — an entropy-positive default that only deliberate, non-feature restructuring can bend back down.

Core Idea

Lehman's second law — the law of increasing complexity, first stated by Meir Lehman in 1974 and refined in the 1980 Belady-Lehman formalization and the 1996 restatement — is the empirical observation that the structural, behavioral, and conceptual complexity of an E-type software system grows monotonically as the system evolves, unless work is explicitly and continuously expended to maintain or reduce it. Each change increment introduces new code paths, new coupling between modules, new special cases and exceptions to existing logic, and new conceptual surface that must be held in the mental model of anyone working on the system. In the absence of deliberate restructuring — refactoring, modularization, deprecation of dead code, interface simplification — these increments accumulate and compound: each added path creates new potential interactions, each new coupling narrows the safe change envelope around adjacent modules, and the aggregate effect is a system that becomes progressively harder to understand, modify, and test correctly. The directional claim is thermodynamic in character: unmanaged change is entropy-positive; the default trajectory is complexity increasing, not holding constant or decreasing. Reversing the direction requires explicit restructuring work that is not feature-bearing — it produces no new user-visible capability but reduces the coupling density and conceptual load that future change must navigate. Belady and Lehman quantified the trend on OS/360 release data using Halstead and McCabe metrics; subsequent studies on the Linux kernel (Israeli and Feitelson, 2010) confirmed the trajectory with coupling and modularity measures, as did work on GNU utilities and GCC. The second law interacts structurally with the sixth law (continuing growth): growth is competitively required, but each growth increment pays a complexity cost, so a project that grows without refactoring will eventually reach a regime where feature velocity collapses as the complexity load consumes an increasing fraction of available engineering capacity — the signature of long-lived systems that never invested in periodic complexity reduction.

Structural Signature

Sig role-phrases:

  • the evolving E-type system — a long-lived codebase whose structural, behavioral, and conceptual complexity is measurable (Halstead, McCabe, coupling, modularity) and accumulates per change increment
  • the change increment — each release adding code paths, module coupling, special cases, and conceptual surface to be held in the mental model
  • the entropy-positive default — unmanaged change driving complexity monotonically up regardless of team skill or intent, the thermodynamic-character claim
  • the restructuring debit — the non-feature work (refactoring, modularization, deprecation, interface simplification) that is the only force bending the curve down
  • the rate balance — restructuring rate against growth rate, the comparison the remaining outcome turns on
  • the conserved-throughput coupling — fixed engineering capacity (fourth law) silently reallocated from features toward navigating an ever-larger structure as complexity rises
  • the velocity-collapse endpoint — the regime a grown-but-never-restructured system reaches on schedule, where the share left for new capability becomes unworkable
  • the refactor cycle — the recurring complexity-reduction debit that restores the headroom the next stretch of competitively-required growth (sixth law) will consume

What It Is Not

  • Not a sign of a careless team. Complexity growth is the default trajectory of evolution itself, independent of intent or skill. Each well-intentioned, individually clean change still adds a code path, a coupling, a special case, enlarging the conceptual surface the next change must navigate. Reading accumulating cruft as negligence — fixable by trying harder — misses that a flawless team produces a rising curve too.
  • Not an inviolable increase. The monotone rise is conditional on unmanaged change. Deliberate non-feature work — refactoring, modularization, deprecation, interface simplification — bends the curve back down. The law says complexity rises absent restructuring, not that it must rise; the corrective is exactly what the law tells you is required.
  • Not optional tidiness. Restructuring delivers no new user-visible capability, which tempts treating it as discretionary cleanup. But it is the only force that reduces coupling density and conceptual load, so a roadmap of pure feature work is structurally unsustainable. The periodic refactor is the non-negotiable debit against an entropy-positive default, not housekeeping.
  • Not the physical second law of thermodynamics. The entropy framing names the direction of the trend — up by default — by analogy; it is an empirical regularity about evolving codebases, not a derivation from statistical mechanics. No literal thermodynamic quantity governs the source code; the "entropy-positive" character is a description of the trajectory, not its cause.
  • Not just growth in size. The complexity at issue is structural, behavioral, and conceptual — coupling between modules, special cases, conceptual surface to hold in mind — measured by metrics like coupling and McCabe, not by line count alone. A system can grow in lines while held simple by restructuring, or stay the same size while compounding in coupling; the law tracks the latter.

Scope of Application

Increasing complexity lives within software engineering — the empirical-software-evolution, software-architecture, and software-maintenance subfields where long-lived E-type codebases accumulate structure — and its reach is bounded there; the entropy-positive default recurs in legal codes, organizations, and genomes, but those are co-instances carried by entropy_thermodynamic_sense and complexification, not the named law transferring.

  • Empirical software evolution — the home turf, where the law is the second of the eight Lehman laws; Belady and Lehman quantified the trend on OS/360 with Halstead and McCabe metrics, and Linux (Israeli and Feitelson), GNU-utility, and GCC studies confirmed it with coupling and modularity measures.
  • Software architecture and design — fixes the sign of the complexity trend (monotonically up under unmanaged change, independent of team skill), recasting accumulating cruft as the expected outcome of any change history rather than negligence.
  • Refactoring and technical-debt management — reframes non-feature restructuring from optional tidiness into the only force that bends the curve down, making the periodic large refactor (BKL removal, IO-scheduler and dcache rewrites in Linux) legible as a regulating complexity-reduction debit.
  • Software-project and capacity planning — read with the fourth (conserved throughput) and sixth (competitive growth) laws, forecasts the slow velocity-collapse a grown-but-never-restructured system reaches on schedule, as conserved engineering capacity is reallocated from features to navigating an ever-larger structure.
  • Software-metrics research — supplies the operationalization (code paths, module coupling, special cases, conceptual surface measured via Halstead, McCabe, and modularity) over which the increasing-complexity trajectory is measured and replicated.

Clarity

The second law's clarification is that complexity has a direction — monotonically up under unmanaged change — and that the direction is independent of the team's intent or skill. This separates two things a project lead easily conflates: complexity as the result of carelessness (sloppy code, bad developers, fixable by trying harder) and complexity as the default thermodynamic trajectory of evolution itself, in which each well-intentioned, individually clean change still adds a code path, a coupling, a special case, and so enlarges the conceptual surface the next change must navigate. Naming the law reframes accumulating cruft from a sign of negligence into the expected outcome of any change history, and reframes the corrective — refactoring, modularization, deprecation, interface simplification — from optional tidiness into the only force that bends the curve the other way. The sharp consequence for planning is that non-feature restructuring becomes a non-negotiable line item: work that delivers no user-visible capability but buys down the coupling density and conceptual load future change will pay against.

It also makes a slow failure mode legible before it arrives. The question shifts from "is the code messy?" to "how much of our engineering capacity is the complexity load already consuming, and is that fraction rising?" Read together with the sixth law (growth is competitively required) and the fourth (throughput is structurally conserved), the second law predicts the trajectory of a project that grows without ever refactoring: feature velocity does not stop suddenly but is silently reallocated toward navigating and fixing an ever-larger structure, until the share left for new capability becomes unworkable. That makes the periodic refactor visible as the regulating response to an entropy-positive default, and the collapse of velocity in an old, never-restructured system visible as a destination reached on schedule rather than a surprise.

Manages Complexity

The accumulation of complexity in a long-lived codebase looks, change by change, like a vast bookkeeping problem: every release adds some code paths, some coupling between modules, some special cases, some conceptual surface, and to know where a system stands an engineer would seem to have to audit the lot. The second law compresses that into a single directional statement about one quantity — structural-behavioral-conceptual complexity rises monotonically under unmanaged change, and only deliberate non-feature restructuring bends it down. The analyst does not have to tally each increment's contribution; the law fixes the sign of the aggregate trend, so the qualitative state is read off two things: how much change history has accumulated since the last restructuring, and whether restructuring has been keeping pace. The thermodynamic character of the claim — unmanaged change is entropy-positive, the default is up — is exactly what collapses the bookkeeping: the direction is settled in advance and independent of the team's care or skill, so individually clean changes still sum to a rising curve, and the analyst need only ask whether anything is pushing back.

That fixed sign supplies the branch structure. One branch is excluded outright: "our developers are good, so complexity is under control" is ruled out, because the law makes complexity-growth a property of evolution rather than of negligence — so the analyst reads accumulating cruft as the expected outcome of any change history, not as evidence of bad engineering. The remaining branches turn on a single comparison — restructuring rate against growth rate — and the law, read together with the sixth (growth is competitively required) and the fourth (throughput is structurally conserved), lets the analyst read off a slow failure mode before it arrives. A project that grows without ever restructuring does not halt abruptly; under fixed conserved throughput, an ever-larger structure silently reallocates engineering capacity away from new features toward navigating and fixing what exists, so feature velocity erodes on a predictable path to unworkable. The periodic refactor thereby reads as the regulating debit against an entropy-positive default, and the eventual velocity collapse of an old, never-restructured system as a destination reached on schedule. A release-by-release complexity audit reduces to one signed trend and one rate comparison, with the velocity-collapse endpoint and the refactor remedy both read off rather than rediscovered.

Abstract Reasoning

The law of increasing complexity licenses reasoning moves built on one fixed-in-advance claim — complexity rises monotonically under unmanaged change, and only deliberate non-feature restructuring bends it down — whose thermodynamic character (the default is up, regardless of team skill) is what each move exploits.

Sign-fixed trend reading (predictive): The characteristic move declines to audit each change increment's contribution and instead reads the aggregate state off two facts: how much change history has accumulated since the last restructuring, and whether restructuring has kept pace. Because the law settles the sign of the trend in advance, the engineer reasons FROM "much change, little restructuring" TO "complexity is high and rising" without tallying paths, couplings, and special cases one by one. Individually clean changes still sum to a rising curve, so the only question the move asks is whether anything is pushing back.

Negligence-versus-entropy diagnosis (diagnostic/boundary-drawing): Confronted with accumulating cruft, the move is to refuse the reading "our developers are careless, fixable by trying harder" and instead classify the growth as the default thermodynamic trajectory of evolution itself — independent of intent or skill. The law lets the engineer reason FROM observed complexity growth TO the conclusion that it is the expected outcome of any change history, because each well-intentioned, individually clean change still adds a code path, a coupling, a special case. This rules out an entire false branch ("good team → controlled complexity") and reframes the corrective — refactoring, modularization, deprecation, interface simplification — from optional tidiness into the only force that bends the curve the other way.

Restructuring-rate-versus-growth-rate comparison (interventionist): With the sign fixed and negligence excluded, the remaining branches turn on a single comparison: is the restructuring rate keeping pace with the growth rate? The move treats non-feature restructuring as a non-negotiable debit against an entropy-positive default and reasons FROM the balance of those two rates TO whether the system's complexity is being held in check or compounding. The intervention lever is explicit and feature-invisible: restructuring produces no new user-visible capability but reduces the coupling density and conceptual load future change must navigate, so the move prescribes periodic restructuring sized to offset the growth the sixth law competitively requires.

Velocity-collapse forecasting (predictive): Read together with the sixth law (growth is competitively required) and the fourth (throughput is structurally conserved), the move forecasts a specific slow failure mode for a project that grows without ever restructuring. Feature velocity does not stop abruptly; under fixed conserved throughput, an ever-larger structure silently reallocates engineering capacity away from new features toward navigating and fixing what exists, until the share left for new capability becomes unworkable. The reasoning runs FROM "growth without restructuring under conserved throughput" TO a predictable erosion path with a known endpoint — so the eventual velocity collapse of an old, never-refactored system is read as a destination reached on schedule rather than a surprise, and the question shifts from "is the code messy?" to "how much of our capacity is the complexity load already consuming, and is that fraction rising?"

Refactor-cycle rationalization (interventionist/boundary-drawing): A characteristic move is reading the periodic large refactor — a BKL removal, an IO-scheduler rewrite — as the regulating response to the entropy-positive default rather than as discretionary cleanup. The reasoning runs FROM the law's fixed direction TO the necessity of recurring complexity-reduction debits in any growing system, so a roadmap that contains only feature work is diagnosed as structurally unsustainable. Each refactor reads as restoring the headroom the next stretch of growth will consume — the visible debit against an invisible but certain rising cost.

Knowledge Transfer

Within software engineering the law transfers as a working mechanism across every long-lived E-type system, and the transfer is literal because the precondition — an evolving codebase whose structural, behavioral, and conceptual complexity is measurable and accumulates per change increment — holds for any such system. The sign-fixed trend reading, the negligence-versus-entropy diagnosis, the restructuring-rate-versus-growth-rate comparison, and the velocity-collapse forecast move without translation from the OS/360 release data on which Belady and Lehman quantified the trend with Halstead and McCabe metrics, through the Linux confirmations with coupling and modularity measures (Israeli and Feitelson) and the GNU-utility and GCC studies, to the contrasting field cases: the kernel's periodic large refactors (BKL removal, IO-scheduler and dcache rewrites) read as complexity-reduction debits, and the never-refactored enterprise monoliths whose every change comes to require multi-week effort. What carries across these substrates is the monotone-up-under-unmanaged-change regularity, the thermodynamic framing of restructuring as the only force that bends the curve down, and the growth-versus-complexity tension with the sixth law that makes the refactor cycle legible; the vocabulary travels because the referent — accumulating complexity in an evolving software system — is the same in each case.

Beyond software the situation is the clearest shared abstract mechanism in the Lehman cluster: the portable claim underneath the law is essentially the second law of thermodynamics generalized to evolving systems — any extended system tends to accumulate disorder unless work is expended to reduce it — and that genuinely recurs across substrates as co-instances, not as decorative analogy. Legislative and regulatory codes accrete special cases and cross-references and grow harder to navigate unless deliberately simplified; organizational structures accumulate process and exception unless periodically streamlined; biological genomes accrete complexity over evolutionary time. But these are co-instances of the more general patterns the law instantiates — entropy_thermodynamic_sense (the entropy-positive default direction of any unmanaged system), complexification (the same arrow-of-time applied across substrates), and temporal_decay_and_degradation (the corollary that structure erodes absent maintenance work), with technical_debt the financial metaphor for the accumulated cost — and it is those primes, not Lehman's second, that carry the lesson cross-domain. The home-bound cargo is the software-specific operationalization: that the complexity is measured in code paths, module coupling, special cases, and conceptual surface via Halstead, McCabe, and modularity metrics; that the restructuring is refactoring, modularization, deprecation, and interface simplification; and that the failure endpoint is feature-velocity collapse under conserved engineering throughput. When the law is reached for outside software, that is a fresh instance of entropy_thermodynamic_sense and complexification recognized by re-derivation, not the named law transferring. So the honest instruction is that the cross-domain lesson should be carried by entropy_thermodynamic_sense, complexification, and temporal_decay_and_degradation, which transfer as mechanism; "Lehman's law of increasing complexity," as named, stands as the canonical software case of an entropy-positive complexity default, paired with the sixth law in teaching the growth-versus-complexity tension. (See Structural Core vs. Domain Accent.)

Examples

Canonical

The defining instance is Belady and Lehman's study of IBM's OS/360 operating system, the empirical base from which the law was first stated. Tracking successive releases of OS/360 over its development history, they measured module-level structure and found that complexity indicators rose release over release, and that the fraction of modules touched by each release (a proxy for how far change had to reach) also climbed — while the incremental work needed to add capability grew. The trend was monotone under ordinary release pressure, and it did not reverse on its own; only releases that included deliberate structural cleanup showed complexity being bought back down. This release-series data is what let Lehman formulate increasing complexity as a directional law rather than a project-specific complaint, later quantified with Halstead and McCabe metrics.

Mapped back: OS/360 across its releases is the evolving E-type system; each release is the change increment; the release-over-release rise Belady and Lehman measured is the entropy-positive default. That the rise reversed only where cleanup was included is the restructuring debit doing the only work that bends the curve down.

Applied / In Practice

The Linux kernel is the field case that shows both halves of the law. Israeli and Feitelson's 2010 study of the kernel's version history measured its evolution with size, coupling, and modularity metrics and confirmed the increasing-complexity trajectory across decades of releases. Against that rising default, the kernel community repeatedly spent large, feature-invisible restructuring effort: the multi-year removal of the Big Kernel Lock (BKL), a coarse global lock that had accumulated as a special-case shortcut and choked scalability, and rewrites of subsystems such as the IO scheduler and the directory-entry cache. None of these delivered a new user-facing capability; each reduced coupling and conceptual load so that later growth had headroom. Enterprise monoliths that skip such investment show the opposite endpoint — routine changes eventually requiring multi-week effort.

Mapped back: The kernel is the evolving E-type system and the Israeli–Feitelson metric rise is the entropy-positive default measured in the field. The BKL removal and subsystem rewrites are the refactor cycle: recurring restructuring debits restoring headroom the next stretch of competitively-required growth will consume, staving off the velocity-collapse endpoint the never-refactored monoliths reach.

Structural Tensions

T1: Law versus tendency (how binding is a monotone that any refactor can reverse). The second law is stated with the force of a law — complexity rises monotonically, thermodynamically, regardless of team skill — yet the same sentence carries the escape clause "under unmanaged change," and deliberate restructuring demonstrably bends the curve down. The two framings pull against each other: as an entropy-positive default the claim is robust and useful, warning that individually clean changes still sum to a rising curve; as a law it overstates, since a system under sufficient restructuring discipline can hold complexity flat or reduce it for long stretches. The tension is that the law's rhetorical power comes from its air of inevitability, while its practical content is precisely that the inevitability is conditional. Lean too hard on "law" and refactoring looks futile; lean too hard on "conditional" and the default's grip is underestimated. Diagnostic: Is the rising complexity here the ungovernable default asserting itself, or the measurable consequence of restructuring having fallen behind a rate that could in principle keep pace?

T2: Competitive growth versus complexity cost (the vise between the second and sixth laws). The second law does not stand alone: the sixth law makes growth competitively required, so a system cannot simply stop adding capability to avoid the complexity tax, yet every growth increment pays that tax. The project is caught between two pressures neither of which it can release — halt growth and lose competitively, grow without restructuring and reach velocity collapse on schedule. Restructuring is the only relief, but it delivers no user-visible capability, so it competes directly against the growth the sixth law demands for the same conserved throughput (fourth law). The tension is structural and unresolved: the system must grow, growth compounds complexity, and the only cure spends the very capacity growth also needs. Diagnostic: For the next planning cycle, is the growth-versus-restructuring split being set by the rate balance the laws imply, or is one pressure (ship features / pay down complexity) simply winning by default?

T3: Non-negotiable restructuring versus refactoring that starves features (the debit can be overpaid). The law reframes restructuring from optional tidiness into a mandatory debit against an entropy-positive default — a genuine correction to roadmaps of pure feature work. But the law fixes only the sign of the required work, not its size, and restructuring consumes the same conserved throughput as features. A team that internalises "refactoring is non-negotiable" without a rate target can overpay: endless architecture churn, speculative generalisation, rewrites chasing a cleanliness the product does not need — complexity work that starves delivery as surely as complexity itself would. The tension is that the law makes restructuring necessary without making it self-limiting, so both under- and over-investment are failure modes and the law adjudicates neither. Diagnostic: Is the proposed restructuring sized to offset the complexity growth actually accumulated since the last one, or is it cleanup beyond what the rate balance requires, spending throughput the product needs for capability?

T4: Measured complexity versus felt complexity (the metrics proxy a mental load they do not contain). The law is operationalised through Halstead, McCabe, coupling, and modularity metrics, which give it empirical teeth on OS/360, Linux, and GCC. But the complexity that actually throttles a project is conceptual — the surface an engineer must hold in mind to change the system safely — and the metrics are proxies for that load, not the load itself. A system can score badly on McCabe yet be locally comprehensible, or score well while hiding coupling the metrics do not capture (implicit dependencies, distributed invariants, tribal knowledge). The tension is that the law's credibility rests on measurability, while its real referent is a cognitive quantity no metric fully captures, so a project can be reassured by good numbers while the mental model quietly becomes unmaintainable. Diagnostic: Is the complexity that matters here showing up in the coupling and McCabe numbers, or is it conceptual surface the metrics miss — and which one is the change budget actually paying against?

T5: Exoneration versus excuse (entropy as expected outcome, and as alibi). The diagnostic move — read accumulating cruft as the expected outcome of any change history, not as negligence — is fair and clarifying: a flawless team still produces a rising curve, so blaming developers misdiagnoses a thermodynamic default. But the same reframing hands a team a ready alibi for genuine carelessness: sloppy coupling, skipped tests, and copy-paste special-casing all register as "complexity growth" and can hide behind "it's just entropy, the law says so." The tension is that the law's exoneration of clean-but-accumulating change is legitimate, while its blanket application launders avoidable messes into inevitable ones. Distinguishing the entropy-positive floor from negligence stacked on top of it requires judgment the law's fixed-sign claim does not supply. Diagnostic: Would a careful team have produced this same complexity growth, or is some of it avoidable carelessness being reclassified as the unmanageable default?

T6: Autonomy versus reduction (its own software law or the codebase instance of entropy and complexification). Lehman's second law is a named, canonically studied result with proprietary software operationalisation — complexity measured in code paths, module coupling, special cases, and conceptual surface via Halstead and McCabe; restructuring realised as refactoring, modularization, and deprecation; the failure endpoint being feature-velocity collapse under conserved engineering throughput. Yet its portable claim is thinner: it is essentially entropy_thermodynamic_sense (the entropy-positive default of any unmanaged system) and complexification (the arrow-of-time accretion across substrates) applied to code, with temporal_decay_and_degradation as the maintenance corollary and technical_debt as the financial metaphor. Legal codes, organisations, and genomes accrete complexity the same way, but they are co-instances of those parents, recognised by re-derivation, not the named law transferring — and the "entropy" framing is itself an analogy the law borrows, not a derivation from statistical mechanics. The tension is between a standalone software law that earns its own metrics and the recognition that its cross-domain reach belongs to the entropy/complexification primes. Diagnostic: Resolve toward entropy_thermodynamic_sense and complexification when asking what carries beyond codebases; toward Lehman's second law when forecasting a specific system's velocity collapse from its restructuring-versus-growth rate balance.

Structural–Framed Character

Lehman's law of increasing complexity sits at mixed on the structural–framed spectrum, leaning structural — with continuing-change it is one of the most prime-shaped members of the cluster, because its core (an entropy-positive complexity default in any unmanaged evolving system) is genuinely substrate-neutral and recurs in nature. The named law's software operationalisation is what holds it at mixed.

Evaluative weight is nil-to-low and points structural. The law describes a directional trend; it grades nothing, and its signature move is to drain the moral charge — reclassifying accumulating cruft as the expected thermodynamic default of evolution rather than as negligence. "Cruft"/"debt" carry a faint tint, but the concept explicitly says a flawless team produces a rising curve too.

Human-practice-bound points structural at the level that matters. The named law lives in software practice (codebases, refactoring, engineering capacity), but the core dynamic — an extended system accumulates disorder unless work is expended to reduce it — runs observer-free and recurs across substrates the entry names, including biological genomes accreting complexity over evolutionary time. So the mechanism needs no human practice at all; only its software instantiation does. This is a stronger structural core than the conservation-law siblings, whose bounds are intrinsically human (cognition, organization).

Institutional origin is mixed: the named law is Lehman's second, first quantified on OS/360 with Halstead and McCabe metrics — a discipline-born construct — while the entropy/complexification arrow-of-time it points at is a near-universal pattern, not an institutional invention. Vocab-travels is split: code paths, coupling, McCabe, refactoring are software-bound, while the abstract entropy-positive-default travels freely. Import-vs-recognize is, in the entry's own words, "the clearest shared abstract mechanism in the Lehman cluster" — legal codes, organizations, and genomes are co-instances recognized by re-derivation, mechanism not decorative analogy — which pulls the criterion structural.

The portable structural skeleton is an unmanaged evolving system accumulates complexity monotonically unless work is expended to reduce it — an entropy-positive default reversible only by deliberate restructuring — carried by entropy_thermodynamic_sense (the default direction) and complexification (the cross-substrate arrow-of-time accretion), with temporal_decay_and_degradation as the maintenance corollary and technical_debt as the financial metaphor. (Notably, the "entropy" framing is itself an analogy the law borrows, not a derivation from statistical mechanics; complexification is the load-bearing cross-substrate pattern.) As the entry establishes, that skeleton is what increasing complexity instantiates in a software register, not what makes "Lehman's second law" itself travel: the cross-domain reach belongs to those parents, while the domain-accented cargo — Halstead/McCabe metrics, refactoring/modularization, velocity-collapse under conserved throughput — stays home. Its character: a substrate-neutral, evaluatively neutral entropy-positive complexification default (recognized across codebases, institutions, and genomes) wearing software-metric vocabulary and a named-law identity — structural at its core but pinned by that software operationalisation to mixed.

Structural Core vs. Domain Accent

This is the section that settles why increasing complexity is a domain-specific abstraction and not a prime — and it is the sharpest case in the cluster to settle, because the law's portable core is nearly a prime already, leaving the domain-specificity resting almost entirely on operationalisation.

What is skeletal (could lift toward a cross-domain prime). Strip the software and a thin relational structure survives: an extended system that keeps changing accumulates disorder — coupling, special cases, conceptual surface — monotonically by default, and only work expended specifically to reduce disorder, producing no new capability, can bend the trend the other way. The portable pieces are abstract: an evolving system, an entropy-positive direction fixed independent of the changer's care or skill, and a restructuring debit that is the sole reversing force. That skeleton is genuinely substrate-portable — indeed the entry calls it the clearest shared mechanism in the Lehman cluster, essentially the second law of thermodynamics generalised to evolving systems — which is exactly why it recurs in the catalog as entropy_thermodynamic_sense (the default direction of any unmanaged system) and complexification (the same arrow-of-time accretion across substrates), with temporal_decay_and_degradation the maintenance corollary and technical_debt the financial metaphor for the accumulated cost. But it is the core the law shares, not what makes it distinctive — and note that even the "entropy" framing is an analogy the law borrows, not a derivation from statistical mechanics, so the load-bearing cross-substrate pattern is complexification, not a literal thermodynamic quantity.

What is domain-bound. Almost all the worked content is software-engineering furniture, and none of it survives extraction intact. The complexity is measured specifically in code paths, module coupling, special cases, and conceptual surface via Halstead, McCabe, and modularity metrics — the empirical teeth from OS/360 through Linux and GCC; the restructuring debit is realised as refactoring, modularization, deprecation, and interface simplification, with concrete instances like the Big Kernel Lock removal and IO-scheduler and dcache rewrites; and the failure endpoint is feature-velocity collapse under conserved engineering throughput (the fourth law), triggered by the competitive growth the sixth law forces. The decisive test: remove the codebase and its metric instrumentation, and "the refactor cycle" has no coupling to reduce and "velocity collapse under conserved throughput" no engineering capacity to reallocate — what remains is the bare entropy-positive accretion claim, no longer this law but the general default 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. Increasing complexity's transfer is bimodal. Within software the mechanism travels intact across every long-lived E-type system — the sign-fixed trend reading, the negligence-versus-entropy diagnosis, the restructuring-rate-versus-growth-rate comparison, and the velocity-collapse forecast move without translation from OS/360 to the Linux confirmations to the never-refactored enterprise monoliths, because each supplies the same referent: accumulating complexity in an evolving codebase, measured by coupling and McCabe. Beyond software the transfer is genuinely mechanistic but it is the parents' transfer, not the named law's: legal codes accreting cross-references, organisations accumulating process, genomes accreting complexity over evolutionary time are co-instances of entropy_thermodynamic_sense and complexification, recognised by re-deriving the entropy-positive default and dropping the Halstead/McCabe apparatus — not "Lehman's second law" carrying over. And when that bare structural lesson is needed cross-domain, it is already supplied, in more general and substrate-neutral form, by the primes the law instantiates: the default direction by entropy_thermodynamic_sense, the cross-substrate accretion by complexification, the maintenance corollary by temporal_decay_and_degradation. The cross-domain reach belongs to those parents; "Lehman's law of increasing complexity," as named, stays home as the canonical software case of an entropy-positive complexity default, paired with the sixth law to teach the growth-versus-complexity tension.

Relationships to Other Abstractions

Local relationship map for Lehman's law of increasing complexityParents 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 ofincreasing complexityDOMAINDomain-specific abstraction: Software Entropy — is a kind ofSoftware EntropyDOMAIN

Current abstraction Lehman's law of increasing complexity Domain-specific

Parents (1) — more general patterns this builds on

  • Lehman's law of increasing complexity is a kind of Software Entropy Domain-specific

    Lehman's second law is the E-type-system specialization of software entropy's change-driven structural-disorder gradient.

Hierarchy paths (4) — routes to 3 parentless roots

Not to Be Confused With

  • Lehman's sixth law (continuing growth). The paired law the second is held in tension with: the sixth makes functional growth competitively required, while the second says each growth increment pays a complexity cost. The sixth pushes features up; the second tracks the internal disorder that growth incurs, reversible only by restructuring. Tell: is the claim that the system must expand to survive (sixth law), or that expansion degrades internal structure unless deliberate work reduces it (second law)? Together they produce the refactor cycle.

  • Lehman's seventh law (declining quality). The seventh concerns external fit — perceived quality falling as the environment drifts away from unchanged code. The second concerns internal structure — coupling and conceptual surface accreting as the code is changed. One is degradation from stasis in a moving world; the other is degradation from the act of changing. Tell: is the decline in fit-to-environment with no code change (seventh law), or in internal complexity from accumulated edits (second law)?

  • Technical debt. The financial metaphor for the accumulated cost of complexity and shortcuts — interest paid on deferred cleanup. The second law is the empirical trend (complexity rises monotonically under unmanaged change) that produces that cost; technical debt is the accounting framing of it. Tell: is the point the measured directional accretion of coupling/conceptual surface (second law), or the borrowing-and-interest framing of its cost (technical debt)? The law describes the rise; the metaphor prices it.

  • The physical second law of thermodynamics. The statistical-mechanics result that entropy of an isolated system does not decrease. Lehman's "entropy-positive" framing borrows this as an analogy for the direction of the complexity trend; it is an empirical regularity about codebases, not a derivation from physics, and no literal thermodynamic quantity governs source code. Tell: is entropy a derived physical law (thermodynamics), or a borrowed description of a monotone empirical trend in evolving software (Lehman's second law)?

  • The parent primes it instantiates (entropy in the thermodynamic sense, complexification, temporal decay). The substrate-neutral skeleton — an unmanaged evolving system accumulates complexity monotonically unless work is expended to reduce it — that the second law instantiates for codebases. Legal codes, organizations, and genomes accrete complexity the same way, as co-instances of these parents. Tell: strip away code paths, Halstead/McCabe metrics, and the refactor/velocity-collapse apparatus and what remains is the bare entropy-positive accretion default, carried by entropy_thermodynamic_sense/complexification, not Lehman's second law. (Treated fully in an earlier section.)

Neighborhood in Abstraction Space

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

Family — Software Evolution & Entropy (7 abstractions)

Nearest neighbors

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