Chesterton's fence
the fence in the field · reformer burden of proof · chesterton's fence principle
The rule that you should not remove something until you know why it was put there. G. K. Chesterton's point in 1929 was epistemic rather than conservative: not knowing the reason is a fact about you, and it disqualifies you from judging the thing.
In practice
The odd approval step everyone routes around exists because of something that happened before anyone currently employed was hired. Finding out what takes an afternoon, and removing it without finding out can take a year to undo.
The common mistake
Using it to block every change. The rule says find out why, and then decide. A fence whose reason has been found and no longer applies should come down, and Chesterton says so explicitly.
Chesterton's image, from The Thing in 1929: you come across a fence in a field with no obvious purpose. The modern reformer says there is no use for it, let us clear it away. The right answer is: go away and think. Come back when you can tell me what it was for. Then I may let you destroy it.
The argument is about knowledge, and it is worth separating from the politics it is usually attached to.
The actual claim
Someone built the fence. It cost them effort and they had a reason. You do not know the reason.
Your not knowing is a fact about your information, and not a fact about the fence. Treating an absence of visible purpose as evidence of absent purpose is the error, and it is a common one because the cost of building was paid long ago and is invisible, while the cost of the fence being there is visible every day.
So the burden falls on the person proposing removal, and it is a burden of finding out rather than of justification. Chesterton is explicit that a fence whose purpose is known and no longer applies should be removed. The rule is not that old things are good.
Where the fences are
The weird approval step. Almost every one traces back to an incident. A client was double-billed, a contractor was paid twice, something shipped that should not have. The step is somebody's scar tissue, and it usually outlives the risk.
The clause in the contract. Boilerplate looks removable until you find the dispute that caused it.
The undocumented condition in the code. The branch that checks a state nobody can reproduce. It is there because it happened.
The rule nobody enforces. These are the interesting ones, because a rule that is not enforced has often already failed and the fence is a ruin rather than a fence.
The other error, which is equally expensive
Applying the rule to everything produces paralysis, and organizations that cite Chesterton constantly are often ones that cannot change anything.
Three qualifications keep it useful.
Investigation is time-boxed. The rule says find out, not launch an inquiry. If an hour with the people who were here and the commit history yields nothing, the fence has no institutional memory left, and that is itself information.
Reversibility changes the standard. A fence you can put back cheaply deserves much less investigation than one you cannot. Deleting a config flag and deleting a database are not the same decision, and treating them the same is the failure mode.
Some fences were never reasoned. Someone copied a template, or cargo-culted a practice from a previous job. Not everything that exists was decided.
Why this matters more as a company ages
Every incident leaves a fence. None of them is ever reviewed, because reviewing them is nobody's job and removing one carries a risk that the person who removes it owns personally.
The result is process debt: an accumulation of steps, each individually justified at the time, collectively making the work slow in a way no single step explains. New people route around them, which is worse than either keeping or removing them, because the fence still costs and no longer protects.
The discipline that works is periodic and deliberate. Take the fences one at a time, find out what each was for, and remove the ones whose reason has expired — with the knowledge that they were reasons, which is exactly what stops the removal from being reckless.
Concept web
Open the full webQuestions
What is Chesterton's fence?
The principle that you should not remove something until you understand why it was put there. G. K. Chesterton gave the image in 1929, arguing that not knowing the reason is a fact about the reformer rather than about the thing.
Is Chesterton's fence an argument against change?
No. Chesterton says explicitly that once the purpose is known and found not to apply, the fence should come down. The rule places a burden of finding out on the person proposing removal, not a burden of never removing.
When does Chesterton's fence not apply?
When investigation turns up nothing after a reasonable effort, when the change is cheaply reversible, and when the thing was never actually reasoned — copied from a template or carried over from someone's previous job.