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.
How would you explain it like I'm…
The Messy Room Rule
Tangles Grow Unless Tidied
Software Entropy Law
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 (Lie group), 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¶
Current abstraction Lehman's law of increasing complexity Domain-specific
Parents (1) — outgoing typed relations
-
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
- Lehman's law of increasing complexity → is a kind of Software Entropy → is a kind of Gradual Deterioration → is a kind of Aggregation → is a kind of Transformation → is a kind of, typical Function (Mapping)
- Lehman's law of increasing complexity → is a kind of Software Entropy → is a kind of Gradual Deterioration → presupposes Time
- Lehman's law of increasing complexity → is a kind of Software Entropy → is a kind of Gradual Deterioration → presupposes Temporal Decay and Degradation → presupposes Entropy (Thermodynamic Sense)
- Lehman's law of increasing complexity → is a kind of Software Entropy → is a kind of Gradual Deterioration → presupposes Temporal Decay and Degradation → presupposes Time
Neighborhood in Abstraction Space¶
Lehman's law of increasing complexity sits in a crowded region of the domain-specific corpus (38th percentile for distinctiveness): several abstractions share nearly its structure, so a description that fits it tends to fit its neighbors too.
Family — Software Evolution Laws & Code Smells (17 abstractions)
Nearest neighbors
- Lehman's law of conservation of organizational stability — 0.91
- Lehman's law of continuing change — 0.91
- Software Entropy — 0.88
- Lehman's law of self regulation — 0.87
- Lehman's law of conservation of familiarity — 0.87
Computed from structural-signature embeddings · 2026-10-25