Other Mental Models · OM-04

Chesterton's Fence

Other Mental Models

Before removing a rule, structure, or fence you don't understand, first find out why it was put there — the fact that its purpose isn't obvious to you is not evidence that it has no purpose.

A principle of reform holding that before tearing down or changing an existing rule, tradition, or structure, one should first understand why it was created in the first place — not seeing a purpose for something is entirely different from confirming there is no purpose, and removing things whose function you don't understand risks removing something load-bearing.

Formulated by G.K. Chesterton in his 1929 book The Thing, in the essay 'The Drift from Domesticity,' using a literal fence in a field as the illustrative example — a reformer who wants to remove a fence should first find out why it was put up, rather than assuming its absence of obvious purpose means it can be safely removed.

The Mechanism

'If you don't see the use of it, I certainly won't let you clear it away'

Encounter a rule, fence, or structure whose purpose isn't immediately obvious The urge to remove it as unnecessary or outdated arises Investigate why it was actually put there before removing it This is the step Chesterton insists must not be skipped Only remove it once the original reason is understood and confirmed no longer relevant Reform proceeds on solid, informed ground rather than a guess

Chesterton's literal example is a fence across a field with no obvious purpose — a hasty reformer removes it because they can't see why it's there; a careful reformer first finds out why it was built (perhaps to keep livestock from a dangerous ravine hidden by tall grass) before deciding whether removing it is actually safe.

01 · ABSENCE OF A VISIBLE REASON IS NOT EVIDENCE OF NO REASON

The chain of reasoning that built a structure isn't always visible to a later observer

Rules, structures, and traditions are frequently built in response to problems or incidents that are no longer visible or remembered by the people encountering the rule later — the original problem may have been solved by the very rule that now seems to serve no purpose, making its apparent purposelessness an illusion caused by its own past success.

02 · IT'S A GUARD AGAINST OVERCONFIDENT, FAST REFORM — NOT AN ARGUMENT AGAINST ALL REFORM

Chesterton's Fence counsels investigation first, not permanent preservation

The principle is frequently misapplied as a blanket argument for preserving the status quo indefinitely — Chesterton's actual point is narrower and more procedural: understand the reason first, then decide, which can still very much result in removing the fence once its original purpose is confirmed obsolete or no longer applicable.

03 · IT APPLIES DIRECTLY TO ORGANIZATIONAL PROCESSES, LEGACY CODE, AND INHERITED POLICIES

A famously common failure mode in new-leadership situations

New managers, engineers inheriting legacy codebases, and incoming leadership teams commonly encounter rules, processes, or code that seem needlessly restrictive or outdated — removing them immediately, before understanding what problem they were solving, is a well-documented and frequently costly failure mode across those domains.

Where It Fails / Inversion

Where it fails / inversion

Investigating every existing rule's original purpose before ever changing anything can itself become a costly form of paralysis — some rules genuinely are vestigial, actively harmful, and clearly no longer serving any purpose once even a modest investigation is done, and demanding an exhaustive investigation before any change becomes its own kind of unjustified conservatism.

How To Use It

Worked example · inheriting a legacy codebase or process at a new job

An engineer who joins a company and finds an oddly restrictive, seemingly unnecessary check in the codebase should look into git history, commit messages, and past incident reports before removing it — the check may have been added specifically in response to a costly past production incident that isn't visible from the code alone, and removing it without that context risks reintroducing the exact failure it was built to prevent.

How to use it

Before removing a rule, process, or structure that seems to serve no purpose, invest the modest effort required to find out why it was actually created — if the original reason turns out to be genuinely obsolete, remove it with full confidence; if not, you've avoided reintroducing a problem someone already solved.

See Also

Via Negativa → Hanlon's Razor → Path Dependence → Functional Fixedness →