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 is the empirical observation that the structural, behavioral, and conceptual complexity of an evolving E-type software system grows monotonically as the system changes, unless work is explicitly and continuously expended to reduce it. Each change adds code paths, coupling, special cases, and conceptual surface; absent deliberate restructuring these increments compound. The directional claim is thermodynamic: unmanaged change is entropy-positive, and reversing the direction requires non-feature restructuring — refactoring, modularization, deprecation, interface simplification.

Scope of Application

Increasing complexity lives within software engineering — the empirical-software-evolution, architecture, and maintenance subfields where long-lived codebases accumulate structure.

  • Empirical software evolution — the home; quantified on OS/360, then Linux, GNU utilities, GCC with coupling and modularity metrics.
  • Software architecture and design — fixes the sign of the complexity trend, independent of team skill.
  • Refactoring and technical-debt management — reframes non-feature restructuring as the only curve-bending force.
  • Project and capacity planning — read with conserved-throughput and growth laws, forecasts velocity collapse.
  • Software-metrics research — supplies the Halstead/McCabe/modularity operationalization of the trajectory.

Clarity

The law's clarification is that complexity has a direction — monotonically up under unmanaged change — independent of the team's intent or skill. This separates complexity-as-carelessness (fixable by trying harder) from complexity-as-default-trajectory, in which each clean change still adds a path, a coupling, a special case. It reframes accumulating cruft from negligence into the expected outcome of any change history, and non-feature restructuring from optional tidiness into the only corrective force.

Manages Complexity

Change by change, complexity accumulation looks like a vast bookkeeping problem. The law compresses it into one directional statement about a single quantity: complexity rises monotonically under unmanaged change, so the analyst reads the state off two things — accumulated change history and whether restructuring kept pace. Read with the growth and conserved-throughput laws, it makes a slow failure mode legible: feature velocity is silently reallocated toward navigating an ever-larger structure until it collapses on schedule.

Abstract Reasoning

The law licenses a sign-fixed trend reading (inferring high, rising complexity from much-change/little-restructuring without auditing increments), a negligence-versus-entropy diagnosis (classifying cruft as evolution's default, ruling out the "good team, controlled complexity" branch), a restructuring-rate-versus-growth-rate comparison, and a velocity-collapse forecast that reads an old system's decline as a destination reached on schedule rather than a surprise.

Knowledge Transfer

Within software engineering the law transfers literally across every long-lived E-type system, because its precondition — an evolving codebase whose complexity accumulates per change — holds in each case; the trend reading, the entropy diagnosis, and the velocity-collapse forecast move without translation from OS/360 through Linux to enterprise monoliths. Beyond software the portable claim is essentially the second law of thermodynamics generalized to evolving systems, recurring in legal codes, organizations, and genomes. That lesson is carried by entropy_thermodynamic_sense, complexification, and temporal_decay_and_degradation, not by Lehman's named law, whose home-bound cargo is the software-specific operationalization in code paths, coupling, and feature-velocity collapse.

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

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