← Patterns

Chesterton's Fence

Core Concept

“Don’t ever take a fence down until you know the reason it was put up.”

If you encounter something that seems unnecessary or inefficient, your first job is to understand why it exists. Only after you understand the original reason can you evaluate whether to remove it.

Where It Applies

Code Changes

When you encounter a guard clause, validation, callback, or naming convention that seems unnecessary — assume it exists for a reason you don’t see yet. Adapt to the constraint before removing it. If removal is genuinely necessary, flag it for human review.

Process Changes

Before eliminating a process (“why do we have this meeting?”), understand what problem it was solving. Maybe the problem is gone and the meeting can go. Maybe the problem is hidden and the meeting is load-bearing.

Refactoring

Every “ugly” workaround in a working system was put there by someone who was staring at a bug you haven’t seen yet. The workaround is evidence. Understand the evidence before deleting it.

New Leader Syndrome

New leaders are especially prone to Chesterton’s Fence violations. They see “unnecessary” processes and want to clean house. Sometimes they’re right. Often they’re destroying institutional knowledge.

AI Agents and Automation

An agent that encounters a constraint and removes it (rather than working around it) is violating Chesterton’s Fence. This is why discovery/understanding phases matter before implementation.

The Deeper Principle

Humility before existing systems. The world is more complex than it appears. If something seems stupid but has survived, it might be stupid — or it might be solving a problem you haven’t understood yet.

Cross-References

• Software-Laws — hub for all seven laws and how they interact
• Doorman-Fallacy — closely related. The Doorman Fallacy is about misunderstanding the value of something. Chesterton’s Fence is about misunderstanding the reason for something. Both are forms of “you don’t understand what you’re about to destroy.”
• Gall’s Law — the workarounds in working systems are the evidence of successful evolution
• Goodhart’s Law — a metric is a fence: understand why it was built, but don’t over-rely on it
• Conway’s Law — boundaries can hide fences; make constraints visible across boundaries