One way ratchet
Description
A doctrine that guarantees a desirable property (correctness, completeness, safety, auditability) by mandating monotonic growth: always add, never remove. The doctrine works locally — every addition is justified, every preservation is safe — but the system accumulates unboundedly over time. Without a paired pruning counter-doctrine (always-add + periodic-cull = stable system), the ratchet eventually produces bloat, slowness, or maintenance pressure that exceeds the doctrine’s original value.
The concept picks out a specific failure mode of correctness-first design: rules that are individually right but collectively produce the wrong shape because they lack a counter-rule. The diagnostic question — “if we never stopped adding, would the system stay useful?” — distinguishes one-way-ratchets that need counter-doctrines from genuinely-bounded accumulation (where natural turnover or external pressure does the pruning automatically).
Triggers
User-initiated: User describes a system that has accumulated cruft, bloat, or unmanageable size despite each individual addition being justified. Vocabulary cues: “ratchet,” “monotonic,” “always add,” “never delete,” “rot,” “bloat,” “cruft.”
Agent-initiated: Agent notices a doctrine that produces monotonic growth, asks “what’s the counter-doctrine?”, and finds none. Candidate inference: “this needs a paired pruning rule, not just a sunsetting hope.”
Situation-shape signals: Doctrines articulated as “always X” or “never not-X.” Slow CI, slow startup times, large config files, deep dependency trees. “We can’t tell what’s still needed” rhetoric.
Exclusions
- Natural turnover — biological systems with cellular replacement, populations with births + deaths, codebases with employee turnover: the prune happens without explicit doctrine.
- External pressure that prunes — markets remove failing products; users remove tools they don’t use; the system has implicit pruning even without internal counter-doctrine.
- Truly bounded resources — when storage or computation is finite and binding, the system can’t ratchet unboundedly; the constraint forces selection.
- Append-only is the right shape — git history, audit logs, scientific publications. The concept would mislead if applied to systems where monotonic growth is the design point, not the failure mode.
Relationships
- doctrine — the correctness rule is a doctrine; the counter-rule is also a doctrine. The pair is what stabilizes the ratchet.
- graduation-promotion — graduation is a one-way ratchet by default (promotion without demotion produces accumulation); explicit demotion is the counter-doctrine.
- asymmetric-gate — one-way-ratchet is the limiting case of asymmetric-gate.
- hysteresis — ratchets produce hysteresis: state depends on full history, reversal requires explicit work.
- cargo-cult — copying the add-doctrine without the prune-doctrine is a canonical cargo-cult instance (“we test like Google does!” — without Google’s culling discipline).
Examples
Government regulations
Domain: public-policy
“always pass new rules to fix this incident” without a sunset-clause counter-doctrine produces regulatory accretion that strangles the original purpose.
Dependency lists
Domain: computer-science
“always add, never remove dependencies” produces NPM-pocalypse; the counter-doctrine is dependency-pruning passes.
Backup retention
Domain: computer-science
“never delete a backup” without a counter-doctrine produces unmanageable archives.
Configuration accumulation
Domain: computer-science
“we never remove config flags” leaves cruft that nobody understands; the counter-doctrine is a periodic “what’s actually used?” audit.
Lehman’s Laws of Software Evolution (1980) — Law III (Self-Regulation), Law VI (Continuing Growth), Law VII (Declining Quality); grounded in longitudinal studies of large software systems through the 1970s, most famously OS/360 at IBM.
Domain: computer-science
Manny Lehman’s longitudinal studies of large software systems through the 1970s — most famously OS/360 at IBM — produced a set of empirically observed regularities he formulated as “laws of software evolution.” The 1980 statement was empirical rather than prescriptive: Lehman wasn’t recommending growth, he was reporting that he could not find systems-in-active-use that escaped it.
Three of Lehman’s eight laws line up directly with the one-way-ratchet structure. Law VI — Continuing Growth states that the functional content of an E-type (evolving) system must continually increase to maintain user satisfaction over the system’s lifetime; users adapt to the system, push its boundaries, and surface new requirements that compound. Law VII — Declining Quality states that the perceived quality of an E-type system will appear to be declining unless rigorous adaptation and evolution effort is expended to compensate; complexity grows and the system drifts toward unmaintainability. Law III — Self-Regulation is the structural counterweight: the evolution process is self-regulating, with measurable trends and statistical regularities — meaning organizations do respond, via release-cadence discipline, refactoring cycles, and resource allocation, even when no one named the doctrine explicitly. (Related laws — Continuing Change and Increasing Complexity — capture adjacent facets: features added are locally justified, and the aggregate is monotonic growth with declining quality unless complexity-management work happens.)
Inference: Read together, the three laws describe a ratchet that is sometimes balanced by an unnamed counter-rule and sometimes is not. The systems that escape Lehman’s quality-decline trajectory are the ones in which the self-regulation step is explicit — periodic complexity-pruning, dependency-pruning, test-suite pruning — rather than implicit. The diagnostic for any long-running codebase: are Continuing Growth (Law VI) and Declining Quality (Law VII) being balanced by a named, scheduled, observable Self-Regulation move (Law III)? If the answer is “we hope to refactor eventually,” the ratchet is unbalanced and the decline is on the books.
Log retention
Domain: computer-science
“always log, never lose” exhausts storage; log rotation is the counter-doctrine.
Memory accretion in code review
Domain: computer-science
“always add a comment when reviewing” + no counter-doctrine produces noise that drowns signal.
Refactoring (Fowler 1999) — refactoring as the prune-doctrine paired with the build-doctrine.
Domain: computer-science
Martin Fowler’s Refactoring (1999) named the prune-doctrine that has to exist alongside the ordinary build-doctrine for a codebase to remain workable. Without an explicit refactoring practice, software is a one-way ratchet: every correctness-driven addition (a defensive check, a special case, a defensive abstraction) is monotonically retained because no actor is incentivized to prune it. Each retention is locally correct; the accumulated mass is what becomes the problem.
Inference: Any system whose correctness incentive points only toward addition needs a paired pruning incentive to stabilize. The diagnostic transfers to test suites, configuration files, log retention policies, dependency lists, government regulations, and concepts catalogs — wherever the local-correctness reasoning is asymmetric, the global mass grows without a counter-doctrine.
Test suites that only grow
Domain: computer-science
“we never delete tests” produces a slow CI that nobody trusts; the counter-doctrine is quarterly test-relevance review.