Chesterton's Fence
Do not remove something whose purpose you cannot explain.
Chesterton's fence is G. K. Chesterton's parable about reform: coming upon a fence across a road, the sensible reply to "I see no use for this, let us clear it away" is "go away and think. When you can come back and tell me that you do see the use of it, I may allow you to destroy it."
Applied to code, it argues against deleting a guard, a workaround, or an odd-looking line simply because its purpose is not evident. Much production code encodes constraints that are invisible from the code itself — a browser quirk, an ordering requirement, an upstream bug. Removing one produces a fault that looks unrelated and reappears months later. At an interface the fence may not be in the code at all: Hyrum's Law holds that with enough users every observable behavior — error wording, iteration order, timing, even a bug — is depended on by somebody, so a property with no visible purpose can still be load-bearing for a caller nobody can enumerate.
The productive form of the principle is not conservatism but investigation: find the reason, then decide. If the fence turns out to be a real constraint, that is exactly the fact worth recording — see Code Comment, whose useful form answers "what breaks if you rewrite this?".
The principle has a mirror, and both are needed. A fence whose reason has expired should come down; keeping it forever is Technical Debt with a good story. And a fence nobody can explain because nobody wrote it down is why Documentation Rot is a correctness problem, not a tidiness one.
See also5
Defensive Default
A substituted value that papers over a missing input and hides the misconfiguration that produced it.
Method12 connections
Root Cause Analysis
Escalating past the visible symptom until you find the layer that actually produced it.
Method49 connections
Naming
Choosing identifiers so the code states its own meaning without commentary.
Method55 connections
Code Review
A second person reading a change before it lands, and the practices that make it worth the time.
Version Control & Delivery25 connections
Unreachable Code
Code no input can execute — usually a guard against a state the surrounding invariants forbid.
Testing & Verification10 connections
Related2
Nearby in the graph rather than deliberately chosen. Looser, sometimes surprising.
Linked from16
- Branch CoverageTesting & Verification
The proportion of conditional outcomes exercised — the strictest ordinary coverage metric, and the most informative.
- Bus FactorVersion Control & Delivery
The number of people who would have to leave before a project stalls.
- Cargo CultMethod
Imitating the visible form of a practice while the mechanism that made it work is absent.
- Code CommentMethod
Prose inside source code, useful only when it records a constraint the code cannot state.
- Defensive DefaultMethod
A substituted value that papers over a missing input and hides the misconfiguration that produced it.
- Documentation RotMethod
Documentation that has drifted from the system it describes, and is now worse than none.
- Five WhysMethod
Repeatedly asking why a symptom occurred, chaining each answer into the next question until the causal chain runs out.
- Hyrum's LawVersion Control & Delivery
With enough users, every observable behavior of an interface becomes a dependency for somebody.
- LegibilityMeaning & Society
Making a system countable and administrable, at the cost of the local knowledge that made it work.
- NamingMethod
Choosing identifiers so the code states its own meaning without commentary.
- Path DependenceMethod
Outcomes shaped by the sequence of past choices rather than by present merit.
- Plausible MechanismMethod
A causal explanation that was inferred rather than tested, and reads as more rigorous for being specific.
- Root Cause AnalysisMethod
Escalating past the visible symptom until you find the layer that actually produced it.
- Technical DebtMethod
The future cost of a present shortcut, metaphorically accruing interest.
- Unreachable CodeTesting & Verification
Code no input can execute — usually a guard against a state the surrounding invariants forbid.
- XY ProblemMethod
Asking for help with your attempted solution (Y) instead of your actual problem (X), so the help solves the wrong thing.