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 also10
Unreachable Code
Code no input can execute — usually a guard against a state the surrounding invariants forbid.
Testing & Verification11 connections
Defensive Default
A substituted value that papers over a missing input and hides the misconfiguration that produced it.
Method16 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.
Method59 connections
Code Review
A second person reading a change before it lands, and the practices that make it worth the time.
Version Control & Delivery38 connections
Plausible Mechanism
A causal explanation that was inferred rather than tested, and reads as more rigorous for being specific.
Method63 connections
Silent Failure
A failure that produces no signal, so the absence of an error reads as success.
Method73 connections
Commit Message
The note attached to each change in version control, conventionally a short summary line and a body explaining why, which becomes the main record of intent for anyone who later wonders why the code is the way it is.
Version Control & Delivery13 connections
Architecture Decision Record
A short document recording one significant technical decision, its context, and its consequences, kept alongside the code so later readers know why the system is shaped the way it is.
Version Control & Delivery9 connections
Git Blame
Showing, for every line of a file, the commit and author that last changed it, the starting point for finding out why code is the way it is.
Version Control & Delivery12 connections
Linked from21
- Architecture Decision RecordVersion Control & Delivery
A short document recording one significant technical decision, its context, and its consequences, kept alongside the code so later readers know why the system is shaped the way it is.
- 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.
- Commit MessageVersion Control & Delivery
The note attached to each change in version control, conventionally a short summary line and a body explaining why, which becomes the main record of intent for anyone who later wonders why the code is the way it is.
- 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.
- FirewallNetworks & Distribution
A filter that allows or blocks network traffic by rule, the oldest perimeter defense, and less sufficient on its own than it used to be.
- Five WhysMethod
Repeatedly asking why a symptom occurred, chaining each answer into the next question until the causal chain runs out.
- Git BlameVersion Control & Delivery
Showing, for every line of a file, the commit and author that last changed it, the starting point for finding out why code is the way it is.
- 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.
- RefactoringMethod
Changing the structure of code without changing what it does, in small verified steps, so that the next change becomes easy.
- 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.