Chesterton's Fence
Chesterton's Fence: Never remove or change anything in a system until you understand why it was put there. The person who cannot articulate a reason for a rule's existence is not qualified to abolish it — the reason may be invisible but real.
What Is Chesterton's Fence?
G.K. Chesterton, the English writer and philosopher, articulated this principle in his 1929 essay collection The Thing: Why I Am a Catholic:
"In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, 'I don't see the use of this; let us clear it away.' To which the more intelligent type of reformer will respond: 'If you don't see the use of it, I will not let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.'"
The insight: many rules, conventions, and structures exist for reasons that have become invisible over time. The original problem they solved may no longer be salient, the people who created them may be gone, and the institutional memory of why they exist may have faded. A new person who encounters such a structure without that context naturally concludes it is pointless — and removes it. This is often catastrophically wrong.
Chesterton's Fence is particularly important in three contexts: organizational change management, software engineering and system design, and regulatory reform. In all three, confident removal of apparently useless constraints is a recurring source of catastrophic failure.
How It Works
When you encounter a rule, convention, policy, or practice
that seems unnecessary or counterproductive:
Step 1: Resist the impulse to remove or change it immediately.
The fact that you can't see the purpose does not mean
there is no purpose.
Step 2: Ask: Why was this put here?
— Who created this rule or convention?
— What problem were they trying to solve?
— What would have happened without it?
— Is there any historical record of what the world
looked like before this was in place?
Step 3: Seek institutional memory.
Talk to people who were there when the rule was created.
Look for documentation of the original rationale.
Look for what problem was salient at the time.
Step 4: If you still can't find the reason after genuine effort,
proceed with extra caution:
— Remove or change in a reversible, limited way first.
— Observe the system's response carefully.
— Be prepared for unexpected negative consequences.
Step 5: If you find the reason, evaluate it:
— Is the original problem still relevant?
— Has the environment changed such that the original
solution is no longer needed or appropriate?
— If so, you can now reform intelligently rather than blindly.
Real-World Examples
Example 1: Software and the Seemingly Dead Code
A new engineer at a financial services company reviews the codebase and finds a function that appears to do nothing — it checks a condition that is always false in the current system and returns early without executing. She removes it in a refactoring pass.
Two weeks later, end-of-month processing produces incorrect results in a specific edge case involving accounts created before 2019. Investigation reveals the "dead" code was handling a legacy data format that persists in accounts created under an earlier system version. The condition that appeared always-false was actually triggered by old-format data — infrequently, but real. The "dead" code was Chesterton's Fence: it looked purposeless because its purpose was handling a situation that wasn't apparent from the current codebase.
This pattern is common enough in software that the principle has a specific application: before removing code that appears dead, instrument it to verify it is actually never executed in production, across all code paths, for long enough to catch infrequent execution.
Example 2: The Peltzman Effect — Safety Regulations
In the 1970s, economist Sam Peltzman studied the effect of US automobile safety regulations — specifically, whether mandatory seatbelts reduced traffic fatalities. His controversial finding: while fatalities per accident decreased, the total number of accidents increased, suggesting that drivers took more risks because they felt safer.
The implication for policy: safety regulations that seem to prevent harm may be producing compensating behavioral changes that partially offset the benefit. This is a Chesterton's Fence problem in reverse: removing a safety constraint (or adding one without understanding the behavioral response) produces unexpected consequences because the system's behavior adapts in ways the reformer didn't model.
Before reforming a safety regulation, understand not just the direct effect but the behavioral equilibrium the regulation is producing.
Example 3: Removing a "Bureaucratic" Approval Process
A new operations director at a mid-sized manufacturer reviews the approval process for raw material purchases. She finds that all purchases above $10,000 require three signatures — including from a VP who is often unavailable. The process appears to be unnecessary bureaucracy slowing supply chain operations.
She proposes removing the VP approval for purchases up to $50,000. Before proceeding, she interviews the VP who created the policy. The answer: six years earlier, a manager had signed a long-term supplier contract at an above-market rate in exchange for undisclosed personal benefits. The three-signature requirement was a control created in direct response to that incident. The director changes her proposal: rather than removing the control, she updates it to include a vendor pricing check against market rates (which addresses the actual risk) while streamlining the approval pathway. The fence's purpose is preserved; its friction is reduced.
When to Use It
✅ Before any significant organizational change that removes or modifies existing rules, processes, or structures.
✅ When onboarding to a new organization or codebase and encountering conventions that seem arbitrary.
✅ When proposing regulatory reform — understanding why regulations exist is the prerequisite for reforming them intelligently.
✅ For new leaders or executives taking over existing teams — resist the impulse to change everything that looks inefficient in the first 90 days.
❌ Not as an excuse to never change anything. Chesterton's Fence is a precaution before change, not a veto on change. Once you understand the purpose, you can evaluate whether the purpose is still served and whether a better solution exists.
Model Combinations:
| Combine with | Effect |
|---|---|
| Second Order Thinking | Understanding Chesterton's Fence prevents the second-order consequences of uninformed removal |
| Inversion | Ask: what would go wrong if this rule didn't exist? This often surfaces the fence's purpose |
| Pre-mortem | Run a pre-mortem on the proposed removal to surface second-order consequences before acting |
Common Misuses and Limitations
Misuse 1: Using it to resist all change. Chesterton's Fence says you must understand before removing; it does not say you should never remove. Once you understand the fence's purpose and determine it's no longer relevant, removal is fully appropriate.
Misuse 2: Concluding that inability to find a reason means there isn't one. Sometimes institutional memory has been completely lost. Inability to find the reason after genuine effort is a signal to proceed with extra caution and reversibility — not a permission to proceed boldly.
Limitation — some fences genuinely are pointless: Not all rules have good reasons. Some are cargo-culted, some are political artifacts, some outlived their usefulness decades ago. Chesterton's Fence doesn't change the analysis of genuinely purposeless rules — it requires that you do the work of determining whether the fence is purposeless before concluding it is.
Related Models
Second Order Thinking: The mechanism by which Chesterton's Fence failures manifest — removing a rule produces unexpected second-order effects.
Unintended Consequences: The broader systems-thinking model for why interventions in complex systems produce surprises.
FAQ
How long should I spend trying to understand a fence before removing it?
Proportional to the consequences of being wrong. For a minor process tweak affecting a small team, a 30-minute conversation with the team members who've been there longest is probably sufficient. For removing a financial control that affects the entire organization, you should pursue institutional memory through documentation, interviews with founders or long-tenure employees, and historical incident reports before proceeding. The higher the stakes of the removal, the more thoroughness is warranted.
What do you do when the fence's purpose is clear but outdated?
This is the ideal outcome of a Chesterton's Fence inquiry. Once you understand the purpose, you can evaluate whether it's still relevant. If the original problem no longer exists or has been solved differently, you can remove the fence with confidence — because you now understand what you're doing. The point of the principle is to produce informed reform, not to freeze the status quo.
Where can I learn more about Chesterton's Fence?
The original passage is in G.K. Chesterton's The Thing: Why I Am a Catholic (1929), Chapter 4, 'The Drift from Domesticity' — searchable online. Shane Parrish's Farnam Street blog has an article titled 'Chesterton's Fence: A Lesson in Second Order Thinking' that is an excellent modern treatment.
Apply This Model with AI
Describe a rule, process, or convention you're considering changing or removing in MindMax. The AI will guide you through the inquiry — asking questions to surface the original purpose and evaluating whether that purpose still applies.
🚀 Apply Chesterton's Fence in MindMax →
Further Reading
- G.K. Chesterton, The Thing: Why I Am a Catholic (1929) — The primary source; Chapter 4 contains the famous passage.
- Shane Parrish, "Chesterton's Fence: A Lesson in Second Order Thinking," Farnam Street (fs.blog) — The best modern synthesis.
This page is part of the MindMax Mental Models Knowledge Base.