Skip to content

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.

Core Idea

Lehman's fifth law — the law of conservation of familiarity, introduced by Meir Lehman in 1974 and refined in the 1996 eight-law restatement — is the empirical observation that the mean incremental change delivered per release of an E-type software system must be held approximately constant over the system's operational lifetime. An E-type system is one whose behavior is interwoven with and must continually respond to a real-world environment; for such a system, every release imposes a cognitive update cost on the producer community (developers, testers, reviewers who must understand what changed) and on the consumer community (users, operators, downstream integrators who must absorb what is new). When releases are pushed larger than this combined human throughput can assimilate, a "familiarity deficit" accumulates: developers lose orientation in the changed codebase, user complaints rise, defect rates spike, and the next release must be smaller as a corrective contraction — so the mean, measured across multiple release cycles, tends back toward the sustainable band. When releases are held too small for too long, different pathologies emerge (accumulated environmental drift per the first law, competitive attrition per the sixth law). The conservation operates as a soft equilibrium enforced not by a single feedback signal but by the aggregate of quality degradation, integration failures, user-complaint volume, and organizational burnout that follow when the familiarity budget is overdrawn. Lehman and Belady's quantitative basis was the OS/360 release history; subsequent replications on the Linux kernel (Israeli and Feitelson, 2010) found that the move to a strict nine-to-ten-week release train held mean per-release delta within a narrow band even as the contributor pool grew, with oversized merge attempts from staging trees producing the predicted regression spikes in subsequent releases.

Structural Signature

Sig role-phrases:

  • the E-type system — a long-lived software system embedded in and continually responding to a real-world environment, served by a producer community and a consumer community
  • the per-release delta — the mean incremental change shipped each release, the conserved quantity the law tracks
  • the absorption band — the sustainable delta range fixed by the combined cognitive throughput of developers, reviewers, users, and integrators (not by tooling or headcount)
  • the familiarity stock — the community's standing orientation in what the system does, drawn down when change outruns absorption
  • the overdraw — an over-band release accumulating a familiarity deficit: defect spikes, complaint surges, lagging integrators, disoriented developers arriving together
  • the corrective contraction — the homeostatic shrink of the next release(s), with a regression spike, that pulls the mean back toward the band
  • the conserved equilibrium — the roughly invariant per-release delta the system settles to across its operational life

What It Is Not

  • Not a production-rate limit. The conserved quantity is bounded by how much change the producer and consumer communities can absorb, not by how much code the team can write. A team can produce far more than the familiarity band allows; the law says shipping it all is what overdraws the budget, so it constrains release sizing, not coding throughput.
  • Not "smaller releases are always safer." Holding delta below the band too long is its own failure mode — accumulated environmental drift (the first law) and competitive attrition (the sixth) — not a benefit. The law prescribes a band, not a floor; under-shipping fails differently, it does not fail less.
  • Not widened by adding contributors. The absorption band is fixed by human cognitive throughput, so doubling the developer pool does not license bigger releases. A team that scales production but not absorption and then sizes releases against the larger production rate will overdraw the familiarity budget — the band is invariant to headcount.
  • Not a precise quantitative constant. "Conservation" is a soft equilibrium measured as the mean delta across many release cycles, enforced by the aggregate of defect spikes, complaints, and burnout — not an exact figure any single release must hit. Individual releases vary widely; the law is a tendency of the average, not a per-release quota.
  • Not a law of all software. It governs E-type systems only — those embedded in and continually responding to a real-world environment. A self-contained program with a fixed specification and no living user-and-integrator community has no familiarity budget to conserve, so the law makes no claim about it.
  • Not bad luck when the next release contracts. A regression spike followed by a smaller release after an oversized merge is the predicted corrective contraction — the system regulating its mean delta back toward the band — not a stumble or a slipped schedule. Reading it as misfortune misses that the law forecast exactly this signature.

Scope of Application

Conservation of familiarity lives within software engineering — specifically the empirical-software-evolution and release-engineering subfields where E-type systems are built and shipped — and its reach is bounded there; reached for outside software it becomes a fresh instance of the parent primes (conservation_laws, absorptive_capacity, homeostasis), not the named law transferring.

  • Empirical software evolution — the home turf, where the law is one of the eight Lehman laws; it was first quantified on the OS/360 release history (Lehman and Belady) and is the canonical case of a conservation law emerging from a cognitive rather than physical bound.
  • Release engineering and cadence design — supplies the rationale for fixed-interval release trains, reframing a per-release delta cap from process ceremony into the engineered match to the producer-plus-consumer absorption band.
  • Open-source project management — the Linux-kernel nine-to-ten-week train held mean delta within a narrow band even as the contributor pool grew, with oversized staging-tree merges producing the predicted regression spikes; Apache, Eclipse, and GCC share the structure.
  • Software-quality and defect analysis — reads a post-release cluster of defect spikes, complaint surges, lagging integrators, and disoriented developers as one diagnosis (a familiarity budget overdrawn) rather than separate incidents.
  • Release planning and roadmapping — converts roadmap sizing from "how much can we ship?" into "what mean delta can this community absorb across many releases?", flagging the invariant that adding contributors does not widen the band.

Clarity

The law's clarifying force for a release manager is that it pulls apart two capacities a roadmap silently conflates: the rate at which a team can produce change and the rate at which the producer and consumer communities can absorb it. Plans are normally sized against the first — story points, throughput, how much code the team can write a sprint — and the absorption ceiling stays invisible until a too-large release lands and the symptoms arrive looking unrelated: a defect spike, a surge in user complaints, integrators falling behind, developers disoriented in their own codebase. Naming conservation of familiarity lets the engineer read those scattered symptoms as one diagnosis — a familiarity budget overdrawn — and recognize the corrective contraction that follows not as a stumble but as the system regulating back toward its sustainable per-release delta.

It also reframes release-size from a free variable into a roughly conserved one, which sharpens the planning question. Instead of asking "how much can we ship this release?" the practitioner asks "what mean delta can this producer-plus-consumer community sustain across many releases, and is this release inside that band?" — and sees that the answer is set by human cognitive throughput, not by tooling or staffing alone, so that simply adding contributors need not raise it. The law thereby makes a cadence discipline (a fixed-interval release train holding delta within a narrow band) legible as the engineered response to a real constraint rather than mere process ceremony, and marks oversized merges as the predictable cause of the next release's regression, not bad luck.

Manages Complexity

A long-lived E-type system's release history is, on its face, a tangle of social, cognitive, and organizational variables — developer orientation in a shifting codebase, reviewer throughput, user complaint volume, integrator backlog, defect injection, the burnout of an overloaded team, the drift of the surrounding environment. To predict how a given release will land, an engineer would otherwise have to weigh all of those against each other for that specific release. Conservation of familiarity collapses that sprawl into a single conserved quantity: the mean incremental change per release, which must stay inside a band set by the combined cognitive throughput of the producer and consumer communities. The whole question "will this release go well or badly?" reduces to comparing one scalar — the size of this release's delta — against that absorption band, and the scattered symptoms (defect spike, complaint surge, lagging integrators, disoriented developers) need not be diagnosed individually; they are read together as the single condition of a familiarity budget overdrawn.

The compression carries a definite branch structure, so the analyst reads off the regime rather than re-deriving the dynamics each time. Delta inside the band: sustainable, no corrective due. Delta above the band: a familiarity deficit accumulates and the next release must contract — so the regulation that follows an oversized merge is expected, not a stumble, and the regression spike in the subsequent release is its predicted signature rather than bad luck. Delta held below the band too long: a different failure mode, the environmental drift of the first law or the competitive attrition of the sixth, rather than the familiarity pathology. Crucially, because the band is fixed by human cognitive throughput and not by tooling or headcount, the analyst also reads off a counterintuitive invariant directly — adding contributors does not widen it — which is why a fixed-interval release train holding delta within a narrow band registers as the engineered match to the constraint rather than process ceremony. A many-dimensional, per-release judgment becomes a one-dimensional reading of delta against a band, with three labeled branches and a known correction in each.

Abstract Reasoning

Conservation of familiarity licenses a set of release-engineering reasoning moves, all keyed to one comparison: this release's delta against the absorption band fixed by the combined cognitive throughput of producer and consumer communities.

Symptom-to-cause diagnosis (diagnostic): The characteristic move is to take a cluster of seemingly unrelated symptoms arriving after a release — a defect spike, a surge in user complaints, integrators falling behind, developers disoriented in their own codebase — and infer a single hidden cause: a familiarity budget overdrawn by an oversized delta. The law lets the engineer reason FROM the co-occurrence of those surface signals TO the diagnosis that the release exceeded the absorption band, rather than chasing each symptom as its own incident. The signature is precisely the bundle: any one symptom alone is ambiguous, but their joint appearance in the wake of a large release is the fingerprint of a familiarity deficit.

Contraction-as-regulation reading (diagnostic/predictive): When the next release comes in smaller after an oversized one, the move is to read that contraction not as a stumble or a slipped schedule but as the system regulating back toward its sustainable per-release delta. The law predicts this correction: an over-band delta forces the subsequent release to shrink, so the regression spike and the contraction that follow an oversized merge are the expected signature, not bad luck. The reasoning runs FROM an observed over-band release TO a forecast of the corrective contraction and the regression in the following one-to-two releases.

Feasibility forecasting of a roadmap (predictive/interventionist): Given a familiarity budget — the mean delta this producer-plus-consumer community can absorb across many releases — the move computes whether a proposed acceleration is sustainable, and predicts that any forced acceleration above the band buys a compensating quality crash or forced contraction rather than durable throughput. The intervention lever is release sizing: hold mean delta inside the band across cycles and the system stays healthy; the engineered instrument for doing so is a fixed-interval release train that caps per-release delta, which the law reframes from process ceremony into the deliberate match to the constraint. Reasoning runs FROM a target change-rate TO whether it can be sustained, and TO the cadence discipline that would keep it inside the band.

Regime boundary-drawing (boundary-drawing): The law partitions the planning space into three labeled regimes and tells the analyst which correction each implies, read off rather than re-derived. Delta inside the band — sustainable, no corrective due. Delta above the band — familiarity deficit accumulates, next release contracts, regression spike expected. Delta held below the band too long — a different failure mode entirely (environmental drift per the first law, competitive attrition per the sixth), so the move is to stop attributing those pathologies to the familiarity mechanism and route them to their own laws. Drawing that third boundary is what keeps the law from being over-applied to every release problem.

Invariant-under-staffing inference (boundary-drawing/predictive): Because the band is set by human cognitive throughput and not by tooling or headcount, the move yields a counterintuitive prediction directly: adding contributors does not widen the absorption band, so a team that scales its production capacity but not its (and its users') absorption capacity will overdraw the familiarity budget if it sizes releases against the larger production rate. The reasoning runs FROM "we added developers" to "the sustainable per-release delta is unchanged" — blocking the natural but wrong inference that more contributors license bigger releases. The Linux release-train history, holding mean delta in a narrow band even as the contributor pool grew, is the move's confirmation.

Knowledge Transfer

Within software engineering — its home domain — conservation of familiarity transfers as a working mechanism across the full range of E-type systems, and the transfer is literal because the precondition (a long-lived system embedded in and continually responding to a real-world environment, served by a producer and a consumer community) is what defines an E-type system in the first place. The diagnostics, the corrective-contraction reading, and the release-sizing intervention move without translation from the OS/360 history on which Lehman and Belady first quantified the law, to the Linux kernel (where the strict nine-to-ten-week release train held mean per-release delta within a narrow band even as the contributor pool grew, with oversized staging-tree merges producing the predicted regression spikes), to other long-lived systems — Apache, Eclipse, GCC, large commercial codebases — that share the same structure. What carries across these substrates is the conserved quantity itself (mean code delta per release), the absorption band set by combined producer-plus-consumer cognitive throughput, and the three labeled regimes with their corrections; the vocabulary travels because the referent — a release of an evolving software system — does not change. The law is the software-evolution specialization of a conserved-quantity discipline, and within software the specialization is the point.

Beyond software the transfer is best characterized as a shared abstract mechanism carried by the parent primes, not by Lehman's fifth law as named — with direct invocation of "conservation of familiarity" outside software being analogy. The genuinely portable claim underneath the law — that a socio-technical system has a bounded human-absorption capacity per cycle, and overdrawing it triggers compensating degradation that forces the system back toward a sustainable rate — really does recur across domains, but it travels as the more general patterns the law instantiates: conservation_laws (a roughly invariant quantity held across the system's life), cognitive_load and absorptive_capacity (the human bound on how much novelty a community can metabolize per increment), and homeostasis (the overshoot → degradation → corrective-contraction regulatory loop). Those primes carry the lesson cross-domain as mechanism; the cargo that stays home-bound is exactly the software-specific content — that the conserved quantity is mean code delta per release, that the absorption band is set by developers, testers, reviewers, users, and integrators, that the symptoms are defect spikes, reverts, and merge regressions, and that the engineered remedy is a fixed-interval release train. When the law is reached for outside software — a legislature enacting reforms too large for constituents and administrators to absorb, a curriculum over-revised faster than teachers and students can keep up, an organization restructured beyond what its staff can re-learn per cycle — that is a fresh instance of the parent primes, recognized by re-derivation, not the named law transferring; the move renames the artifact (code delta → statute, syllabus, org chart) and borrows the conservation-plus-contraction shape while the software-specific machinery stays behind. So the honest instruction is that the cross-domain lesson should be carried by conservation_laws, absorptive_capacity, and homeostasis, with conservation of familiarity standing as the canonical software example of how such a conservation law can emerge from a cognitive rather than a physical bound. (See Structural Core vs. Domain Accent.)

Examples

Canonical

The law's founding evidence is Lehman and Belady's study of IBM's OS/360 operating system across its successive releases through the late 1960s and early 1970s. Tabulating the number of modules handled (added or changed) per release, they found that the incremental growth did not scale up freely with the system's size or the team's capacity; instead the mean change per release stayed roughly constant, and releases that pushed a large increment tended to be followed by a corrective, smaller release before growth resumed. The per-release delta behaved like a conserved quantity fluctuating around a stable band rather than a free variable the organization could set at will — the observation that became the fifth of Lehman's laws of software evolution.

Mapped back: OS/360 is the E-type system; modules-changed-per-release is the per-release delta, the conserved quantity. Its staying roughly constant across the release history is the conserved equilibrium, held within the absorption band fixed by what the producing and consuming communities could assimilate. A large increment followed by a smaller next release is the overdraw and its corrective contraction observed directly in the data.

Applied / In Practice

Israeli and Feitelson (2010) tested the law on the Linux kernel's full release history. After the kernel adopted a strict time-based release train — a new release roughly every nine to ten weeks regardless of how much was ready — the mean change shipped per release stayed within a narrow band even as the contributor pool and total codebase grew by orders of magnitude over the study period. The cadence discipline is the engineered match to the law: by fixing the interval, it caps the per-release delta near the sustainable band rather than letting release size float with production capacity. Attempts to merge oversized staging trees in a single window produced the predicted after-effect — regression and instability spikes in the following releases, the familiarity budget overdrawn and then repaid by contraction.

Mapped back: The kernel is the E-type system; per-release change is the per-release delta, and the release train holds it inside the absorption band. That the band did not widen as contributors multiplied confirms it is fixed by cognitive throughput, not headcount. Oversized merges are the overdraw; the subsequent regression spikes and settling are the corrective contraction pulling the mean back to the conserved equilibrium.

Structural Tensions

T1: Production capacity versus absorption capacity (a paid-for output rate the law says you cannot use). The law's central insight is that release sizing is bounded by what producer and consumer communities can absorb, not by what the team can produce — and these two capacities routinely diverge. An organization that scales its engineering can generate far more change than the familiarity band allows, and there is real competitive and stakeholder pressure to ship it. Holding output down to the absorption band leaves paid-for production capacity idle; shipping to the production rate overdraws the budget and buys a quality crash. The tension is that the law asks a team to throttle a capability it invested in, to a ceiling set by other people's cognition, and offers no way to convert surplus production into durable throughput. The mismatch is structural, not a scheduling error. Diagnostic: Is release size here being set by what the team can produce (and is under pressure to ship), or by what the producer-plus-consumer community can actually absorb — and what is the plan for the surplus production capacity?

T2: Too large versus too small (the band is a squeeze, and both walls fail differently). The law prescribes a band, not a floor, so release sizing is caught between two failure modes. Overshoot the band and a familiarity deficit accumulates — defects, complaints, disoriented developers, a forced contraction. But undershoot it for too long and different pathologies bite: environmental drift (Lehman's first law) as the system falls behind its changing world, and competitive attrition (the sixth) as rivals out-ship. The sustainable band can be narrow, and a release manager steering away from one wall steers toward the other. This makes "ship less" not a safe default but a move that trades one failure for another, and the law refuses the comforting rule that smaller is always safer. The tension is a genuine two-sided constraint with no slack direction. Diagnostic: Is this release at risk of overdrawing familiarity (too large) or of accumulating environmental drift and competitive attrition (too small) — and which wall is the binding one for this system right now?

T3: Descriptive conservation versus prescriptive lever (a law enforced by pain, or a knob you set). The law is stated as an empirical regularity: mean delta tends to stay constant because overdraw triggers degradation that forces a contraction — a homeostatic loop that operates whether or not anyone plans for it. But the entry also wields it prescriptively: size releases to the band, adopt a fixed-interval release train. These two readings sit in tension. If the equilibrium is genuinely enforced ex-post by defects and burnout, then the release train merely anticipates an inevitable correction and "conservation" is a fact about outcomes, not a choice. If release size is a free lever the planner sets, then the "law" is really just prudent management dressed as physics, and its predictive authority is weaker. The concept oscillates between an iron regularity that regulates you and a discipline you elect. Diagnostic: Is the observed constancy of per-release delta here being enforced by the system's own corrective pain regardless of planning, or is it the visible result of a cadence discipline the team deliberately chose — and does calling it a "law" overstate the former?

T4: Soft mean-across-cycles versus an actionable per-release limit (a robust average that poorly guides the next release). "Conservation" is explicitly a soft equilibrium — the mean delta across many release cycles, enforced by aggregate symptoms, with individual releases varying widely and no exact figure any single release must hit. That statistical softness is what makes it a robust law rather than a brittle constant. But it also blunts the law as a planning instrument: a manager sizing this release gets a band, not a number, and cannot tell prospectively whether a given delta is a tolerable outlier or an overdraw until the post-release symptoms arrive. The property that makes the regularity durable (it is a tendency of the average) is the same property that makes it weak for the concrete decision it is invoked to guide. The tension is between the law's honest imprecision and the crisp per-release limit a roadmap needs. Diagnostic: Is this release's delta being judged against a defensible estimate of the community's sustainable band, or against a false-precision number the "soft mean" law does not actually license — and will overdraw only be visible after the fact?

T5: A fixed cognitive band versus absorptive capacity you can engineer (invariant to headcount, but invariant to everything?). The load-bearing counterintuitive claim is that the band is fixed by human cognitive throughput and does not widen with contributors or tooling — which correctly blocks "we hired more, so we can ship more." But taken strictly it also implies absorption cannot be raised at all, and that is contestable: documentation, modular architecture, automated testing, staged rollout, backward compatibility, and clear abstractions plausibly do increase how much change a community can metabolize per cycle. If absorptive capacity is partly engineerable, the band is not a hard constant but a slow-moving variable, and "invariant to headcount" is really "invariant to naive staffing." The tension is between the strength the law draws from treating the band as a cognitive given and the design reality that some investments genuinely widen it. Diagnostic: Is the absorption band here truly fixed, or has it been artificially narrowed by poor modularity, thin documentation, and no rollout staging — investments that could widen it rather than more contributors that cannot?

T6: Autonomy versus reduction (a named Lehman law or the software instance of a cognitive conservation loop). Conservation of familiarity is a specific software-evolution law with irreducibly local cargo — the conserved quantity is mean code delta per release, the communities are developers, testers, reviewers, users, and integrators, the symptoms are defect spikes and merge regressions, the remedy is a fixed-interval release train — and within software it transfers as literal mechanism across every E-type system (OS/360, Linux, Apache, Eclipse, GCC). But beyond software it does not travel as the named law: the portable claim — a socio-technical system has bounded human-absorption capacity per cycle, and overdrawing it triggers compensating degradation that forces it back to a sustainable rate — is carried by the parents conservation_laws, absorptive_capacity / cognitive_load, and homeostasis. A legislature over-reforming or a curriculum over-revised is a fresh instance of those primes, recognized by re-derivation, not the fifth law transferring. The tension is between a law that earns its own software-specific apparatus and the recognition that its cross-domain lesson belongs to those parents — with this law standing as the canonical case of a conservation law emerging from a cognitive rather than physical bound. Diagnostic: Resolve toward conservation_laws / absorptive_capacity / homeostasis when the point is bounded human absorption outside software; toward the named law when sizing releases of an evolving software system against its producer-plus-consumer band.

Structural–Framed Character

Lehman's law of conservation of familiarity sits at mixed on the structural–framed spectrum, leaning framed — it has a genuine structural core (a homeostatic conservation loop bounded by absorptive capacity) but is bound to human software-development communities and human cognition, and is a named empirical law of a specific discipline, which pull it toward the framed side.

Evaluative weight is nil-to-low and points structural. The law is a descriptive regularity about release sizing; it grades nothing and renders no verdict, merely predicting that mean per-release delta tends back toward a sustainable band. Even the "overdraw/degradation" language names a dynamic, not a fault.

Human-practice-bound is the criterion that tilts it framed, and does so distinctively. The equilibrium is real and self-enforcing (defect spikes, burnout, and contraction operate whether or not anyone plans for them, so it is not observer-constituted), but its entire substrate is a human socio-technical practice — a producer community and a consumer community — and, uniquely, the conserved quantity is bounded by human cognitive throughput. The entry's own headline is that this is "a conservation law emerging from a cognitive rather than a physical bound," which makes it more practice-bound than a physical conservation law: strip the human communities and their finite capacity to absorb novelty and there is nothing to conserve.

Institutional origin is mixed: the named law is Lehman's fifth, one of eight, first quantified on OS/360 — a discipline-born empirical construct — but the homeostatic-conservation dynamic it points at is a general regulatory pattern, not an institutional invention. Vocab-travels is low: per-release delta, E-type system, absorption band, release train — all software-bound. Import-vs-recognize is, in the entry's own terms, bimodal: within software the mechanism transfers by recognition across every E-type system, while beyond software a legislature over-reforming or a curriculum over-revised is a fresh instance of the parent primes recognized by re-derivation, not the named law transferring — analogy on the label, mechanism in the parents.

The portable structural skeleton is a homeostatic conservation loop bounded by absorptive capacity — a system with finite per-cycle absorption holds a throughput quantity roughly invariant, and overdrawing the bound triggers compensating degradation that forces contraction back to the sustainable band — genuinely a composition of homeostasis (the overshoot-degradation-correction loop), absorptive_capacity/cognitive_load (the bound), and conservation_laws (the resulting invariant). As the entry establishes, that skeleton is what conservation of familiarity instantiates from those umbrella primes in a software register, not what makes "Lehman's fifth law" itself travel: the cross-domain reach belongs to those parents, while the domain-accented cargo — code delta, the developer/user communities, defect spikes and merge regressions, the release-train remedy — stays home. Its character: a structurally real cognitive-conservation homeostatic loop dressed in software release-engineering vocabulary and a named-law identity, structural in skeleton but pinned by its human-community substrate and cognitive bound to mixed-leaning-framed rather than a free-floating prime.

Structural Core vs. Domain Accent

This is the section that decides why conservation of familiarity is a domain-specific abstraction and not a prime, and it carries the case for its domain-specificity in the same breath.

What is skeletal (could lift toward a cross-domain prime). Strip the software away and a thin, portable structure survives: a socio-technical system has a bounded per-cycle absorptive capacity; a throughput quantity is therefore held roughly invariant across the system's life; and overdrawing the bound triggers compensating degradation that forces a corrective contraction back to the sustainable band. The portable pieces are abstract: a finite absorption bound, a conserved throughput quantity, a band (not a floor) with a different failure mode on each side, and a homeostatic overshoot-degradation-correction loop. That skeleton is genuinely substrate-portable — it is a composition of conservation_laws (the roughly invariant quantity), absorptive_capacity/cognitive_load (the bound on how much novelty a community can metabolize per increment), and homeostasis (the overshoot → degradation → contraction loop). But this is the core the law shares, not what makes it Lehman's fifth law.

What is domain-bound. Almost everything that makes the law operational is software-evolution furniture that does not survive extraction. The conserved quantity is specifically mean code delta per release of an E-type system. The communities that fix the absorption band are software-specific: developers, testers, reviewers, users, and downstream integrators. The overdraw symptoms are software symptoms — defect spikes, reverts, merge regressions, disoriented developers, lagging integrators. The engineered remedy is a fixed-interval release train that caps per-release delta. The evidentiary base is the OS/360 release history and the Linux-kernel nine-to-ten-week train, and the law's very identity is positional — the fifth of eight Lehman laws, with under-shipping routed to the first (environmental drift) and sixth (competitive attrition). The decisive test: remove the release, the code delta, and the producer/consumer software communities and it is no longer conservation of familiarity but the bare cognitive-conservation loop — which is exactly what an over-reformed legislature or an over-revised curriculum is, a fresh instance of the parents with none of the release-engineering apparatus.

Why this does not clear the prime bar. A prime's vocabulary travels and its transfer is recognition of the same mechanism, not analogy. Conservation of familiarity's transfer is bimodal. Within software the law travels intact as literal mechanism — the conserved delta, the absorption band, the three labeled regimes and their corrections, the invariant-under-headcount inference — recurring as recognition across every E-type system (OS/360, Linux, Apache, Eclipse, GCC), because the precondition (a long-lived system embedded in a real-world environment, served by producer and consumer communities) is what defines an E-type system. But these are variants of one substrate. Beyond software the named law does not transfer: a legislature enacting reforms too large for constituents and administrators to absorb, a curriculum over-revised faster than teachers and students can keep up, an organization restructured beyond what staff can re-learn per cycle are fresh instances of the parent primes, recognized by re-derivation — the move renames the artifact (code delta → statute, syllabus, org chart) and borrows the conservation-plus-contraction shape while the software machinery stays behind. And when the bare structural lesson is wanted cross-domain, it is already supplied, in more general form, by the parents — conservation_laws, absorptive_capacity/cognitive_load, and homeostasis — of which Lehman's fifth law is the software instance and the canonical case of a conservation law emerging from a cognitive rather than a physical bound. The cross-domain reach belongs to those umbrella primes; "conservation of familiarity," as named, carries the code delta, the developer/user communities, the defect-and-merge symptoms, and the release-train remedy as software-engineering baggage that stays home.

Relationships to Other Abstractions

Local relationship map for Lehman's law of conservation of familiarityParents 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 of cons…DOMAINDomain-specific abstraction: Lehman's law of self regulation — presupposesLehman's law ofself regulationDOMAINPrime abstraction: Carrying Capacity — is a decomposition ofCarryingCapacityPRIME

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

Parents (2) — more general patterns this builds on

  • 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

Not to Be Confused With

  • Lehman's fourth law (conservation of organizational stability / work rate). The other "conservation" law in the set, and the easiest to swap with this one by name. The fourth conserves the activity rate (the average effective global work rate on a system stays roughly invariant across its life); the fifth conserves the change absorbed per release (the delta the communities can assimilate). One is about how fast the organization works; the other about how much novelty the audience can metabolize. Tell: is the invariant the team's work/effort rate (fourth law) or the incremental change shipped per release against a familiarity budget (fifth law)?

  • Lehman's first and sixth laws (continuing change; continuing growth). These name the opposite failure mode — the pathologies of shipping too little: environmental drift as the system falls behind its world (first law) and competitive attrition / functional-content pressure (sixth law). The fifth law's mechanism is the overshoot side (a familiarity budget overdrawn); under-shipping is routed to these siblings. Tell: is the problem change outrunning absorption (fifth law), or the system stagnating and drifting behind its environment (first/sixth laws)?

  • Brooks's law. "Adding manpower to a late software project makes it later" — a claim about communication and onboarding overhead raising coordination cost as a team grows. It resembles the fifth law's headcount-invariance ("more contributors do not widen the band") but the mechanism differs: Brooks is about intra-team coordination cost; conservation of familiarity is about the producer-plus-consumer community's cognitive absorption of change. Tell: is the constraint the overhead of coordinating more people on a task (Brooks), or the bounded rate at which developers and users can assimilate shipped change (conservation of familiarity)?

  • Physical conservation laws (energy, momentum). The metaphor's source — exact invariants derived from physical symmetry. The fifth law borrows the word "conservation" but is a soft, statistical equilibrium enforced by aggregate degradation and bounded by cognitive, not physical, throughput; individual releases vary widely and no exact figure is conserved. Tell: is the quantity conserved by a hard physical law (energy/momentum) or a mean-across-cycles tendency enforced by defects, complaints, and burnout (conservation of familiarity)?

  • The parent primes it composes (conservation laws, absorptive capacity / cognitive load, homeostasis). The substrate-neutral skeleton — a system with bounded per-cycle absorptive capacity holds a throughput quantity roughly invariant, and overdrawing it triggers compensating degradation that forces contraction — that the fifth law instantiates for software releases. A legislature over-reforming or a curriculum over-revised is a fresh instance of these parents, not the named law. Tell: strip away code delta, releases, and the developer/user communities and what remains is bare cognitive-conservation homeostasis, carried by the parents, not Lehman's fifth law. (Treated fully in an earlier section.)

Neighborhood in Abstraction Space

Lehman's law of conservation of familiarity sits in a crowded region of the domain-specific corpus (14th 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