Chesterton's Fence: Don't Remove What You Don't Understand

What is Chesterton’s fence?

Chesterton’s fence is the rule that you should not get rid of something until you understand why it exists. If a policy, process or structure looks pointless, the first step is to find out what it was for, not to remove it.

The idea rests on a simple observation: things usually get built for a reason. The reason may be outdated, mistaken or no longer relevant, but you can only judge that once you know what it is. Removing a fence because you can’t see its purpose assumes your view is complete, and it often is not.

You meet fences everywhere:

• A strange step in an approval process.
• A line of code that looks redundant.
• A family tradition, a building regulation, a clause in a contract.
• A habit your team follows that nobody can explain.

Where it comes from

The principle comes from the English writer G. K. Chesterton. In his 1929 book The Thing, he described two kinds of reformers who come across a fence or gate across a road. The first, the “modern type” in his telling, sees no use for it and says to clear it away. The more intelligent type answers that if you don’t see its use, you certainly may not clear it away: go and find out what it is for, and once you can explain it, you may be allowed to remove it.

Chesterton’s point was that structures are rarely put up by people who were simply foolish. Someone, at some cost, decided this fence was worth building. That does not make the decision right, but it makes it worth understanding.

The parable became popular well beyond Chesterton’s original essay. Today it is cited in engineering, management, law, policy and software, usually as a check on confident, fast change. It overlaps with second-order thinking: the reason for a fence is often a second-order effect someone saw years ago.

How to use Chesterton’s fence

1. Notice the urge to remove. The trigger is a thought like “this is pointless” or “why do we even do this?” Pause there.
2. Ask why it was built. Look for the history: documents, version control, old emails, meeting notes, the person who set it up.
3. Ask the people closest to it. Those who live with the fence daily often know what it prevents, even if they can’t articulate the rule.
4. Dig to the root cause. If the first answer is shallow (“because the manager wanted it”), keep asking. The five whys technique works well here.
5. Check if the reason still holds. Circumstances change. A rule built for a problem that no longer exists may be safe to drop.
6. Weigh cost against purpose. Even a valid fence can cost more than it saves. Decide with both in view.
7. Remove it reversibly. If you go ahead, try it in one team, one region or behind a flag before removing it everywhere. Prefer reversible decisions.
8. Leave a note. Whether you keep it or remove it, write down why, so the next person does not have to repeat the search.

3 real-world examples

Business

Say a new operations manager finds that every refund over a certain amount needs a second signature, which slows down customer service. It looks like bureaucracy. Asking around, she learns the rule was added after a past case of refund fraud. She keeps the control but raises the threshold and makes the second approval faster, removing most of the delay without reopening the original risk.

Personal life

Say you inherit a family habit of keeping cash at home and checking the house’s main water valve every autumn. It seems old-fashioned. A conversation with an older relative reveals that the house once flooded when pipes froze during a power outage, and nobody could get to an ATM for days. You may decide the cash is no longer needed, but the valve check stays.

Tech

In a hypothetical codebase, a developer finds a short delay inserted before a network call, with no comment. It looks like a mistake and slows things down. Checking the version history reveals it was added to work around rate limits on an external service. The developer replaces the arbitrary delay with proper retry logic and a comment explaining it, instead of deleting it and causing intermittent failures in production.

Common mistakes

• Using it to block all change. “We’ve always done it this way” is not Chesterton’s fence. The principle demands a reason, not just a history.
• Stopping at the first answer. “It’s policy” explains nothing. Find the problem the policy was solving.
• Assuming the original reason still applies. Fences outlive their purpose. Understanding is the step before deciding, not a reason to keep everything.
• Researching forever. For small, reversible fences, a quick check and a careful test can be enough.
• Building fences without notes. The best way to respect the principle is to leave a short record of why you added a rule.

The bias that drives most fence-smashing is the Dunning-Kruger effect: people new to a system can be most confident about what in it is useless, precisely because they don’t yet know what it handles.

Chesterton’s fence vs first-principles thinking

These two models can look opposed. First-principles thinking breaks a problem down to basic truths and rebuilds it, often ignoring how things are currently done. Chesterton’s fence warns against discarding current structures before understanding them.

They work best as a pair. Use first principles to imagine a better design, then use Chesterton’s fence to check what the old design was quietly handling before you replace it.

The Mentarium take

Chesterton’s fence is often quoted as a defense of tradition, and that undersells it. It is a tool for better change. The reformer who knows why a fence exists can remove it with confidence, or redesign it so the original problem stays solved. The reformer who doesn’t is gambling, and the bill often arrives months later, when nobody connects the new problem with the old fence.

Our practical rule: the cost of finding out should scale with the cost of being wrong. A pointless form field gets five minutes of investigation and a quick test. A safety procedure, a legal clause or a core piece of infrastructure gets the full search, ideally with a few people who remember its history. When in doubt, make the removal small and reversible, and watch.

It also pairs naturally with the Lindy effect: a fence that has survived for decades in a changing environment has probably been doing something. That’s not proof, but it shifts the burden of evidence to the person who wants it gone.

Finally, build fences you’d want to inherit. Every rule, check or workaround you add should come with one sentence explaining why. It costs nothing now and spares the next person the search. The Mentarium Field Guide covers this and the other models for changing systems, organized by the situation you’re facing. For more models like this one, browse the mental models library.