Chesterton's Fence: A lesson in second order thinking (2021)
Chesterton’s Fence – the idea that you shouldn’t remove an existing rule, norm, or system until you understand why it was put there – is examined as a tool for “second-order thinking” and a source of tension between prudence and progress. Commenters contrast its value in preventing unseen harms in evolved systems (laws, social taboos, legacy software) with the way it can ossify institutions, justify never refactoring or reforming, and become a thought‑stopping cliché. Many argue the practical answer lies in investigation, experimentation, and better documentation of why “fences” are built in the first place, rather than defaulting either to blind disruption or blind conservatism.
Core interpretation of Chesterton’s Fence
- Many emphasize the principle is not “never remove fences” but “understand why they exist before changing them.”
- It’s framed as an argument for curiosity and deeper investigation, not blanket conservatism.
- Several note it aligns with ideas like the Lindy effect and with studying history: long‑lived institutions likely encode hard‑won adaptations.
Critiques: Thought‑terminating cliché & inertia
- Some argue it often becomes a “thought‑stopping” move in politics and organizations, used to block reform indefinitely.
- Critics say the “criteria for removal” can be impossible in practice: rationales are lost, contradictory, or political.
- Others counter that it’s a heuristic, not a demand for 100% certainty; “the fence was a mistake” is a valid conclusion after reasonable inquiry.
Engineering and software examples
- Common analogy: legacy code, configs, and business rules.
- Supporters describe “paying the Chesterton tax”: tracing history before cleanup or refactor, sometimes uncovering real edge cases.
- Others point out that fear of breaking unknown things can freeze refactoring, especially when nobody understands the code but the risk of failure is high.
- Suggested mitigations: rewrites in parallel, feature flags / “scream tests,” heavy testing rather than pure historical archaeology.
Documentation, process, and burden of proof
- Strong theme: the real fix is documenting why “fences” are built, so future removals are informed and cheap.
- Some argue fences without documented justification should default to removal, pushing builders to record their reasons.
- Others respond that in high‑stakes domains (law, society) consequences can be delayed and severe, so default removal is dangerous.
Risk, experimentation, and context
- Several distinguish fast‑moving startups and software (where temporary failures are acceptable) from societies and regulations (where failures can be catastrophic).
- Some advocate a culture of frequent experimentation—multiple companies or states trying “fenceless” variants and learning from outcomes.
- Others stress that high adaptability via constant teardown may come with high “mortality,” which is acceptable for firms but not obviously for societies.
Extensions beyond systems
- Applied to social taboos, cultural norms, physiology, and personal habits.
- For internal psychological “fences,” some suggest change can precede understanding; otherwise analysis paralysis can prevent growth.