Lehman's law of conservation of familiarity

Hold the mean change shipped per release of a long-lived software system roughly constant, because the producer and consumer communities have a bounded capacity to absorb novelty, and overdrawing it forces a corrective contraction.

Version

v3 · 2026-09-28 · History · 2 corrections

Domain-specific #

621

Domain group

Applied Sciences & Engineering

Origin domain

Computer Science & Software Engineering

Subdomains

Information Technology, Software Engineering → Computer Science & Software Engineering

Core Idea

Lehman's fifth law is the empirical observation that the mean incremental change per release of an E-type software system — one whose behavior must continually respond to a real-world environment — stays approximately constant over the system's life. Every release imposes a cognitive update cost on producers and consumers; when releases outrun this combined throughput, a familiarity deficit accumulates and the next release must contract, so the mean returns toward a sustainable band.

How would you explain it like I'm…

Only So Much New at Once

When people keep improving a big computer program, each new version changes about the same amount on average. If they change too much at once, the builders and the users get confused and lots of things break. Then the next version has to be smaller to catch up. It is like learning new songs: you can only learn so many at a time.

The Steady Update Size Rule

Lehman's law of conservation of familiarity is a pattern people noticed in software that has to keep up with the real world. Every new version makes the people who build it and the people who use it learn what changed. There's only so much they can absorb at once. If a release changes too much, people get lost, bugs pile up, and complaints rise, so the next release ends up smaller. Over time, the average size of each change stays roughly steady. It's an observed tendency, not a strict rule.

Conservation of Familiarity

Lehman's law of conservation of familiarity is Lehman's fifth law of software evolution. It observes that the average amount of change per release of an E-type system stays roughly constant over the system's lifetime. An E-type system is software tied to a changing real-world environment. Every release has a learning cost, both for developers and testers and for users and integrators. When releases are too big for people to absorb, a 'familiarity deficit' builds up. Developers lose track of the code, defects and complaints rise, and the next release has to shrink. Releases kept too small for too long cause other problems, such as falling behind the changing world. It is an empirical tendency, not a guarantee, and tests on the Linux kernel only partly confirmed it.

 

Lehman's law of conservation of familiarity is Lehman's fifth law, first published in 1980 and restated in the 1996 eight-law set. It holds empirically that mean incremental change per release of an E-type system stays approximately constant over its operational life. The mechanism is cognitive throughput. Producers must understand what changed, and consumers such as users, operators, and integrators must assimilate what is new. Oversized releases overdraw this familiarity budget, producing disorientation, defect spikes, integration failures, user complaints, and burnout. A corrective contraction follows, pulling the multi-release average back toward a sustainable band. Releases that are too small invite environmental drift (first law) and competitive attrition (sixth law). The equilibrium is soft and enforced by many signals together, not by one feedback loop. The evidence base is the OS/360 release history. A 2010 study of 810 Linux kernel versions over 14 years found small changes between development releases but large differences between production versions, a partial confirmation.

Scope of Application

The law lives within software engineering — the empirical-software-evolution and release-engineering subfields where E-type systems are built and shipped.

• Empirical software evolution — the home turf, one of the eight Lehman laws, first quantified on OS/360.
• Release engineering — the rationale for fixed-interval release trains capping per-release delta.
• Open-source project management — release sizing in long-lived open-source systems such as the Linux kernel, a later and only partial test of the law.
• Software-quality analysis — reading post-release symptom clusters as one overdrawn-budget diagnosis.
• Release planning — sizing roadmaps by what a community can absorb, not what a team can produce.

Clarity

The law pulls apart two capacities a roadmap conflates: the rate a team can produce change and the rate communities can absorb it. It lets scattered symptoms — defect spikes, complaint surges, lagging integrators — read as one diagnosis (a familiarity budget overdrawn), and reframes release-size from a free variable into a roughly conserved one set by human cognitive throughput, not staffing.

Manages Complexity

A tangle of social and cognitive variables collapses into one conserved quantity: mean change per release, compared against an absorption band. "Will this release land well?" becomes a one-dimensional reading with three labeled branches — inside the band (sustainable), above it (deficit, contraction due), or held below too long (a different failure mode) — each with a known correction.

Abstract Reasoning

The law licenses symptom-to-cause diagnosis (a symptom bundle implies an overdrawn budget), a contraction-as-regulation reading, feasibility forecasting of a roadmap against the band, regime boundary-drawing across three labeled zones, and an invariant-under-staffing inference (adding contributors does not widen the band).

Knowledge Transfer

Within software engineering the law transfers literally as mechanism across every E-type system, since that precondition defines the domain, carrying from OS/360 to Linux, Apache, and GCC. Beyond software the portable claim — a socio-technical system has bounded human-absorption capacity per cycle, and overdrawing it triggers corrective degradation — travels as the parents Conservation Laws, Absorptive Capacity, Cognitive Load, and Homeostasis, not the named law; the software-specific cargo stays home.

Relationships to Other Abstractions

Current abstraction Lehman's law of conservation of familiarity Domain-specific

Parents (2) — outgoing typed relations

• Lehman's law of conservation of familiarity presupposes Lehman's law of self regulation Domain-specific

  The fifth law's mean release-delta band presupposes the third law's regulating loop that converts overdraw into corrective contraction.

• Lehman's law of conservation of familiarity is a decomposition of Carrying Capacity Prime

  The familiarity band is a sustainable load envelope specialized to how much change a software community can absorb per release.

Hierarchy paths (3) — routes to 3 parentless roots

• Lehman's law of conservation of familiarity → presupposes Lehman's law of self regulation → is a decomposition of Homeostasis → is a kind of, typical Discrepancy-Driven Correction → is a kind of Feedback

Show alternative paths (2)

Neighborhood in Abstraction Space

Lehman's law of conservation of familiarity sits in a moderately populated region (45^th percentile for distinctiveness): it has near-neighbors but no dense thicket of look-alikes.

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

Nearest neighbors

• Lehman's law of conservation of organizational stability — 0.91
• Lehman's law of continuing growth — 0.88
• Lehman's law of declining quality — 0.87
• Lehman's law of increasing complexity — 0.87
• Lehman's law of continuing change — 0.87

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