Contents
Systems & Strategy
Section 1
The Core Idea
In 1929, G.K. Chesterton posed a deceptively simple thought experiment in The Thing: Why I Am a Catholic. Imagine you encounter a fence erected across a road. A modern reformer looks at it and says, "I don't see the use of this; let us clear it away." The more intelligent reformer replies: "If you don't see the use of it, I certainly won't 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."
That's the entire principle. Before you remove something — a rule, an institution, a process, a line of code — you must first understand why it exists. Not whether you like it. Not whether it seems outdated. Why someone, at some point, thought it was necessary enough to build.
The principle sounds conservative. It isn't, or at least not in the way people assume. Chesterton wasn't arguing that fences should never come down. He was arguing that the act of understanding why a fence was built is a prerequisite to removing it wisely. The reformer who understands the fence's purpose can remove it with confidence — and often should, because the original reason may no longer apply. The reformer who doesn't understand it is gambling — and the history of reckless reform is a graveyard of lost bets.
The distinction matters because it separates Chesterton's Fence from simple conservatism. A conservative says "don't touch it." Chesterton says "understand it first, then do what the understanding warrants." The principle is fully compatible with radical change — provided the radical has done their homework. Some of history's greatest reformers were also its most thorough students of the systems they dismantled.
Software engineering provides the starkest modern illustration. In August 2012, Knight Capital Group deployed code that reactivated an obsolete trading function — a piece of logic that hadn't been fully removed during a previous update because no one understood what it did. In 45 minutes, the defunct code executed 4 million erroneous trades, generating $7 billion in unwanted positions. Knight lost $440 million before the market opened the next day. The company, which had operated for seventeen years, was effectively destroyed within an hour. The fence they tore down wasn't decorative. It was load-bearing, and nobody checked.
Every experienced software engineer has a version of this story. The "dead" feature flag that turns out to gate a critical fallback path. The redundant database index that silently prevents a query from taking down production during peak traffic. The seemingly pointless sleep timer that exists because a third-party API rate-limits without returning an error code.
Hyrum's Law — "with a sufficient number of users of an API, all observable behaviors of your system will be depended on by somebody" — is Chesterton's Fence stated in engineering terms. The fence may look pointless. Somebody is leaning on it. And the larger the system, the more likely that "somebody" is a critical downstream process you've never heard of.
The pattern scales to policy. When the United States repealed key provisions of the Glass-Steagall Act in 1999 — removing the wall between commercial banking and investment banking that had stood since 1933 — the rationale was modernisation. Glass-Steagall was a Depression-era artifact. Markets had evolved. The fence was old, and old fences must be unnecessary fences. Within a decade, the commercial banks now free to engage in speculative trading had accumulated enormous exposure to mortgage-backed securities. The 2008 financial crisis wiped out $7.4 trillion in US stock market value in eleven months. The fence existed because people who lived through the 1929 crash understood something the 1999 reformers had forgotten: when banks gamble with depositors' money, the consequences are catastrophic and systemic.
Nassim Taleb connected this directly to his Lindy Effect — the idea that the longer something has survived, the longer it's likely to continue surviving, because its persistence is evidence that it serves some function, even if that function isn't immediately visible. A regulatory fence that stood for sixty-six years isn't arbitrary. It's Lindy.
The Chesterton fence principle applies in both directions: not only to physical fences and formal regulations, but to informal norms, cultural practices, institutional habits, and organisational rituals that may encode hard-won wisdom in a form that's illegible to outsiders. The Japanese concept of kata — formalised patterns of movement in martial arts — looks like meaningless repetition to an untrained observer. It's actually a compressed encoding of centuries of combat experience, preserved in physical form precisely because the reasoning behind each movement is too complex to transmit verbally. The fence doesn't have to make sense to you. It has to have made sense to someone. Your job is to find out who, and why.
Section 2
How to See It
Chesterton's Fence appears wherever someone dismantles something they don't understand and discovers — too late — that it was structural. The signal is always the same: a change that seemed obviously good produces consequences that seem obviously bad, and the consequences were predictable to anyone who understood the original system. Watch for the pattern across domains.
Software Engineering
You're seeing Chesterton's Fence when a developer removes a "dead" code path or an apparently useless database index, and production breaks within hours. At Cloudflare in July 2019, an engineer deployed a regular expression rule update to the company's Web Application Firewall. A single regex — one that looked innocuous in testing — caused global CPU exhaustion, taking down Cloudflare's entire network for 27 minutes and affecting millions of websites. The existing rule set had been built incrementally over years, each rule responding to a specific attack pattern. The new rule interacted with old rules in ways that weren't obvious from reading any single rule in isolation. The "fence" was the carefully balanced interaction between rules, not the individual rules themselves.
Business
You're seeing Chesterton's Fence when a new CEO eliminates a seemingly bureaucratic process, and six months later the company faces a compliance violation or quality failure. When Ron Johnson left Apple to become CEO of J.C. Penney in 2011, he eliminated the retailer's coupon and promotional pricing system — a messy, seemingly irrational patchwork of markdowns and sales events. Johnson replaced it with "fair and square" everyday low pricing. Rational. Clean. Modern. Revenue dropped 25% in a single year. The couponing system existed because J.C. Penney's customers were psychologically anchored to the ritual of "finding a deal." The promotions weren't waste. They were the mechanism through which customers gave themselves permission to buy. Johnson didn't understand the fence. He tore it down. He was fired seventeen months into the job.
Public Policy
You're seeing Chesterton's Fence when a government deregulates an industry and the resulting failures expose why the regulation existed. Australia's electricity market deregulation in the early 2000s was designed to increase competition and lower prices. Generators discovered they could profit more by withholding supply during peak demand, creating artificial scarcity. South Australia experienced a statewide blackout in September 2016 — partly because the deregulated market had created insufficient incentives for maintaining reliable baseload generation. The regulations weren't just bureaucratic friction. They were the mechanism ensuring the lights stayed on.
Personal life
You're seeing Chesterton's Fence when you drop a long-standing personal habit — a weekly review, a daily walk, an early bedtime — because it seems unnecessary, and within weeks something that previously ran smoothly begins to degrade. The habit was doing invisible maintenance work. You didn't notice until it stopped. Tim Ferriss has spoken about eliminating his morning journaling practice because it felt like a productivity drag, only to find his decision-making quality deteriorated within two weeks. The fence was a cognitive reset he only valued once it was gone.
Section 3
How to Use It
The operational test is straightforward but consistently resisted: before removing, modifying, or circumventing any existing system, practice, or constraint, articulate — in writing, not just in your head — why it was originally put in place. The "in writing" part is essential. Mental models of why things exist are vulnerable to motivated reasoning; written investigation creates an auditable record that forces honesty.
Decision filter
"Can I explain why this exists? If not, I don't yet have the information I need to decide whether to keep it or remove it. The inability to explain the fence is itself the argument for leaving it standing — until I can."
As an engineer
Before deleting code, deprecating a feature, or removing a dependency, trace its history. Run
git blame. Read the commit message. Find the original author if possible. Search the issue tracker for the ticket that spawned the code. The code that looks dead may be a safety valve that activates only under rare conditions — race conditions, edge cases in date parsing, fallback behaviour during third-party API outages.At Google, the practice of requiring "tombstone comments" — explanations of why dead code was intentionally left in place — exists precisely because engineers learned the hard way that removing "unused" code often broke systems in production environments that testing couldn't replicate. Stripe takes a similar approach: their internal documentation requires that any removal of a feature flag or deprecated code path includes a written explanation of the original purpose and an explicit statement of why the removal is safe. The fence doesn't have to be elegant to be necessary.
As a manager
When a process seems pointlessly bureaucratic, investigate before you streamline. Talk to the people who created it — if they're still at the company. Check the issue tracker, the incident retrospectives, the compliance audit trail. Often the process exists because of a specific failure — a legal exposure, a quality incident, a compliance finding — that institutional memory has since forgotten. The process outlived the memory of why it was needed. This is the most common form of Chesterton's Fence in corporate life: procedures that persist after the crisis that created them has faded from collective recall.
When Marissa Mayer became CEO of Yahoo in 2012, she eliminated the company's remote work policy — a practice that had been in place for years. The rationale: in-office collaboration would reignite innovation. The remote policy existed, in part, because Yahoo had acquired dozens of small companies whose best engineers lived nowhere near Sunnyvale. Forcing them into the office didn't produce collaboration. It produced resignations. Understanding why the fence stood — retaining distributed talent — would have led to a more surgical intervention.
As a reformer
The strongest position for a reformer is one who can articulate the case for the thing they want to change better than its defenders can. This is Chesterton's actual test — not "do you agree with the fence?" but "do you understand it well enough to steelman it?" If you can't make the strongest possible argument for keeping the fence, you haven't done enough homework to earn the right to remove it.
When the UK reformed its National Health Service in 2012 under the Health and Social Care Act, critics argued that the existing Primary Care Trust structure was being dismantled without adequate understanding of what it actually did — the coordination between GPs, hospitals, and community services that PCTs managed informally. The reform created Clinical Commissioning Groups that reproduced many of the same functions under different names, at a transition cost estimated at £3 billion. By 2022, the government reversed course entirely, abolishing CCGs and creating Integrated Care Boards — effectively rebuilding a version of the structure it had spent a decade dismantling. Understanding the fence before demolishing it would have saved billions, years of disruption, and the institutional knowledge lost during two unnecessary reorganisations.
Common misapplication: Chesterton's Fence gets weaponised as a universal argument against change. "You can't prove why this exists, therefore we must keep it" is a perversion of the principle. Chesterton didn't say fences should never be removed — he said you should understand them first. An investigation that reveals the fence was erected for reasons that no longer apply is a legitimate basis for removal. The principle demands inquiry, not inertia.
The second misapplication is using the principle to demand an impossible standard of proof. "Until you can explain every possible reason for this fence, you can't touch it" sets a bar that can never be met — every system has infinite possible justifications, and demanding exhaustive explanation is paralysis wearing the mask of prudence. A good-faith Chesterton investigation requires understanding the primary reason the fence was built, not every conceivable reason it might still be useful. Using it to block all reform is the mirror image of the error it was designed to prevent.
Section 4
The Mechanism
Section 5
Founders & Leaders in Action
The leaders who transformed institutions most successfully were the ones who took the time to understand what they were transforming — and preserved the fences that were still structural, even when they looked outdated from the outside. The pattern across these cases is consistent: the best reformers aren't the ones who destroy the most. They're the ones who investigate the most thoroughly and then destroy with precision.
Jeff BezosFounder & CEO, Amazon, 1994–2021
Bezos's six-page memo policy is Chesterton's Fence in corporate practice. When Amazon executives and board members repeatedly suggested replacing the memo with PowerPoint — faster to produce, easier to present — Bezos refused.
He understood why the fence existed: narrative structure forces the writer to think through their argument completely, including the logic connecting each claim. A sentence has to follow logically from the previous sentence. A bullet point doesn't. PowerPoint enables presenters to hide logical gaps behind charisma, visual design, and the social pressure of a live audience. The memo eliminates all three escape routes.
The same instinct governed his approach to Amazon's Leadership Principles. As the company scaled from hundreds to over 1.5 million employees, many argued the fourteen principles were too rigid, too specific, or too numerous for a modern tech company. Executives arriving from Google or Facebook — companies with looser cultural frameworks — pushed to simplify them.
Bezos maintained them because he understood their function wasn't inspirational — it was operational. The principles created a shared decision-making language that scaled across tens of thousands of teams without requiring centralised control. "Customer Obsession" wasn't a poster on the wall. It was the reason Amazon let customers return products with no questions asked, even when the return rate on certain items exceeded 20%. "Bias for Action" wasn't aspirational. It was the reason teams could launch experiments without executive approval. Removing or diluting the principles would have looked like modernisation. It would have been amputation.
His 2016 shareholder letter drew the line explicitly: "Day 2 is stasis. Followed by irrelevance. Followed by excruciating, painful decline. Followed by death." But the path to avoiding Day 2 wasn't tearing things down indiscriminately. It was understanding which processes served the mission and which had become proxies — then eliminating the proxies while reinforcing the essentials. The six-page memo survived because it was structural. The processes Bezos killed — like the early-2000s editorial model for product recommendations, replaced by algorithmic personalisation — were fences whose original purpose had been superseded by better mechanisms. The investigation happened. The fence came down. That's the principle working correctly.
Ray DalioFounder, Bridgewater Associates, 1975–2022
Bridgewater's "Principles" — over 200 codified decision rules — are the most elaborate system of institutional fences in modern finance. Each principle was generated by a specific failure or near-miss. Principle #11, "Understand that you and everyone else has blind spots," exists because Dalio's early career featured a catastrophic wrong call on the 1982 Mexican debt crisis that nearly bankrupted his firm.
When new employees questioned why certain practices existed — the mandatory "radical transparency" meetings, the real-time feedback ratings, the "baseball card" profiles of every employee's cognitive strengths and weaknesses — Dalio's response was always the same: trace the principle back to the incident that created it.
Understand the fence before you propose moving it. If you can articulate why the principle was created and demonstrate that the underlying risk no longer exists, Dalio was open to modification. If you couldn't, the principle stood.
The approach had real costs. Bridgewater's culture was polarising — employee turnover in the first 18 months reportedly exceeded 30%, and the radical transparency practices drew intense criticism from organisational psychologists. But the practices that seemed irrational to outsiders existed because specific governance failures had nearly destroyed the firm at earlier stages. Dalio's core insight was that institutional memory is fragile — people forget why the fence was built within a few years of the crisis that built it — and that the only defence against this amnesia is explicit codification of the reasoning behind every rule. Every principle at Bridgewater includes not just the rule itself but the story of the failure that necessitated it. The story is the Chesterton investigation, preserved in writing so that future employees don't have to rediscover the hard way why the fence was erected.
Satya NadellaCEO, Microsoft, 2014–present
When Nadella became CEO in February 2014, the pressure to demolish was enormous. Ballmer-era Microsoft was synonymous with bureaucracy, internal competition, and the failed Nokia acquisition. The stock had been flat for a decade. Analysts were calling for radical restructuring. Some suggested splitting the company. The reflex — the one most turnaround CEOs follow — was to tear everything down and rebuild from scratch.
Nadella applied Chesterton's Fence with surgical precision instead. He killed Windows Phone and wrote off the $7.6 billion Nokia acquisition — understanding that those fences had been erected to protect a mobile strategy that had permanently failed. The mobile window had closed. Android and iOS owned the market. The fence no longer protected anything worth protecting.
He dismantled the stack-ranking employee review system — understanding it existed to create accountability but had metastasised into a culture of internal sabotage where employees competed against colleagues rather than competitors. The original purpose (performance differentiation) had been swallowed by the perverse incentive (political survival).
But he kept the enterprise sales relationships, the Office franchise, and the Azure cloud infrastructure — understanding that these fences were structural, not decorative. Azure's early-mover advantage in enterprise cloud had been obscured by the company's Windows-centric narrative, but the underlying asset was sound. He also preserved Microsoft's research division, which many analysts had called an expensive vanity project. The research lab's work on large language models — specifically the partnership with OpenAI that began with a $1 billion investment in 2019 — became the foundation of Microsoft's AI strategy, contributing to the Copilot suite and a reported $13 billion total investment by 2023.
By 2024, Microsoft's market capitalisation had grown from roughly $300 billion to over $3 trillion. The transformation worked because Nadella distinguished between fences that had outlived their purpose and fences that were still bearing weight — and the distinction was always grounded in understanding why each fence existed, not merely whether it looked modern.
Linus TorvaldsCreator & Maintainer, Linux Kernel, 1991–present
Torvalds has spent three decades as the most visible practitioner of Chesterton's Fence in software. The Linux kernel — running on everything from Android phones to 90% of the world's top 500 supercomputers — has an absolute rule: you do not break userspace. Any kernel change that causes existing programs to fail is reverted, regardless of how "correct" the new behaviour is.
The principle is ruthlessly applied. In a famous 2012 mailing list exchange, Torvalds rejected a patch that would have fixed a longstanding inconsistency in how the kernel reported memory usage. The fix was technically correct — the old behaviour produced misleading numbers.
But existing monitoring tools depended on the "incorrect" behaviour. Changing it would break those tools in production systems worldwide. "We do not break userspace," Torvalds wrote. "It doesn't matter that the old behaviour was 'wrong.' Programs depend on it." The technically correct fix was operationally dangerous because it ignored the fence — the accumulated dependency of thousands of programs on the existing, imperfect behaviour.
This is Chesterton's Fence at industrial scale. Every quirk, every inconsistency, every "obviously wrong" behaviour in the kernel exists because some program, somewhere, relies on it. Torvalds understands that the fence — even an ugly, irrational-looking fence — may be load-bearing for systems he has never seen. The burden of proof is always on the person proposing the change, never on the existing behaviour.
The philosophy has made Linux the most reliable operating system kernel in history — and one of the most conservative in its interface guarantees. Torvalds's emails on the subject are legendarily blunt: "Breaking user programs is simply not acceptable. I don't care what your technical argument is." That's the Chesterton fence principle articulated by someone who maintains software running on billions of devices. The fence doesn't have to be beautiful. It has to be understood before it can be moved.
Section 6
Visual Explanation
The decision tree for Chesterton's Fence is binary at its core: either you understand why the fence exists, or you don't. Each branch leads to a fundamentally different set of actions — and critically, the "No" branch doesn't lead to "keep the fence forever." It leads to "investigate until you can move to the Yes branch." The principle is an inquiry protocol, not a preservation mandate. The diagram below makes the logic explicit.
Chesterton's Fence Decision Tree — The principle reduces to a single question: do you understand why it was put there? Everything else follows from the answer.
Section 7
Connected Models
Chesterton's Fence sits at the intersection of epistemological humility and institutional design. Its connections are unusually rich — reinforcing models that counsel patience, creating productive tension with models that counsel boldness, and leading naturally to harder questions about when preservation becomes pathology and when prudence becomes paralysis.
Reinforces
Lindy Effect
Taleb's Lindy Effect — the longer something has survived, the longer its expected remaining life — is the quantitative backbone of Chesterton's Fence. If a practice has persisted for a hundred years, Lindy reasoning says it has survived a hundred years' worth of attempts to remove it, and its survival is statistical evidence of hidden utility.
Chesterton's Fence explains why Lindy works: things persist because they serve functions that may not be visible to casual observers. Together, the two models create a powerful default: the older the fence, the higher the burden of proof for removal. Taleb made this explicit in Antifragile, arguing that "what Mother Nature does is rigorous until proven otherwise; what humans and science do is flawed until proven otherwise." The practical implication: a sixty-year-old regulation should require a far more thorough investigation before removal than a six-month-old internal policy.
Reinforces
Second-Order Thinking
Chesterton's Fence is, at its core, an argument for second-order thinking applied to removal decisions. The first-order effect of removing a fence is visible and immediate — less friction, lower cost, fewer steps. The second-order effects — the regulatory violation, the system failure, the institutional knowledge loss — are invisible until they arrive.
Howard Marks's framework maps directly: first-level thinkers see the fence and see waste. Second-level thinkers see the fence and ask what downstream function it serves that isn't obvious from the surface.
The 1999 Glass-Steagall repeal is the canonical case — the first-order effect (deregulated banks, more competition, more innovation) was visible and celebrated. The second-order effects (concentrated risk, moral hazard, systemic fragility) arrived nine years later and nearly collapsed the global financial system. Chesterton's Fence is the forcing function for tracing these second-order consequences before committing to removal.
Tension
First Principles Thinking
First principles thinking says: decompose to fundamentals, discard inherited assumptions, rebuild from scratch. Chesterton's Fence says: inherited structures encode knowledge you may not possess, and discarding them without understanding is reckless. The tension is real and productive.
Musk's first principles approach to rocket design worked because he had the physics knowledge to identify which aerospace conventions were genuine constraints and which were inherited bureaucracy. Without that depth, first principles becomes exactly the kind of ignorant reform Chesterton warned against — someone tearing down a fence while claiming they've "reasoned from fundamentals."
The resolution: first principles thinking should include a Chesterton investigation as one of its steps. Understand the existing system before you replace it. Know why the incumbent solution exists before you build the new one. The two models are antagonistic only when practitioners skip the investigation — which, in practice, they frequently do.
Tension
[Via Negativa](/mental-models/via-negativa)
Via Negativa — improvement through removal rather than addition — directly challenges Chesterton's Fence. Taleb himself advocated both principles, which creates an apparent contradiction: how can you counsel removing things (Via Negativa) while also counselling against removing things you don't understand (Chesterton's Fence)?
The resolution is sequencing. Chesterton's Fence applies first: determine whether you understand the function. Via Negativa applies second: once you've confirmed something is genuinely unnecessary, remove it rather than adding a workaround. A doctor who stops prescribing a medication the patient doesn't need (Via Negativa) should first verify the medication isn't managing a condition the patient has forgotten about (Chesterton's Fence).
The two models aren't contradictory. They're sequential — and the sequence matters enormously. Apply Chesterton's Fence first. If the investigation clears the fence for removal, apply Via Negativa with confidence.
Leads-to
Status Quo Bias
The dark twin of Chesterton's Fence. Status quo bias — the irrational preference for current conditions simply because they are current — is what happens when Chesterton's principle degenerates from genuine inquiry into reflexive conservatism. "We've always done it this way" sounds like Chesterton's Fence but is actually its corruption — the conclusion without the investigation.
The difference is the critical diagnostic skill. Legitimate application demands that you investigate why the fence exists and then decide based on findings. Status quo bias skips the investigation and declares the fence sacred by default. In organisations, this corruption is pervasive — large companies invoke "process" and "governance" to protect entrenched power structures, citing institutional wisdom that was never actually investigated.
The path from Chesterton's Fence to Status Quo Bias is the path from intellectual humility to intellectual laziness, and it's a well-worn path in every bureaucracy. The antidote: always ask the person citing Chesterton's Fence whether they've actually investigated why the fence exists. If they have, listen carefully. If they haven't, they're not applying the principle. They're hiding behind it.
Leads-to
Reversibility
Once you've understood why the fence exists and decided to remove it, the next question is: can you put it back? Reversibility is the natural successor because it addresses the residual risk that even a thorough Chesterton investigation might have missed something.
Bezos's "one-way door / two-way door" framework captures this precisely: irreversible removals demand Chesterton-level investigation. Reversible removals can proceed more quickly because the cost of being wrong is recoverable.
Software feature flags are the engineering implementation — you can "remove" a code path by flagging it off, observe the consequences, and re-enable it instantly if problems appear. The combination — understand before removing, and prefer reversible removal when possible — is the complete risk management protocol for institutional change.
Section 8
One Key Quote
— G.K. Chesterton, The Thing: Why I Am a Catholic (1929)"If you don't see the use of it, I certainly won't 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."
Section 9
Analyst's Take
Faster Than Normal — Editorial View
Chesterton's Fence is the most underappreciated model in the entire toolkit — and the most frequently misapplied. Not because people haven't heard of it. The phrase has become common enough in software engineering and policy circles that it's practically a meme. The problem is that almost everyone applies it backward.
The usual invocation goes: "We can't change this because Chesterton's Fence." Full stop. No investigation. No attempt to understand why the fence was built. Just a citation of the principle as a conversation-stopper. I've heard this in boardrooms, sprint retrospectives, and policy debates — always from people who have never read Chesterton and don't realise they're perverting his argument.
This is the exact opposite of what Chesterton proposed. He didn't argue for preservation. He argued for comprehension as a prerequisite to action. The principle demands that you do the intellectual work — trace the history, talk to the builders, understand the failure that prompted the fence — before you decide. The decision itself could go either way.
The founders who apply this model most effectively are the ones dismantling things, not preserving them. Satya Nadella killed Windows Phone. Dalio's Bridgewater modifies its own principles when investigation reveals the original reasoning no longer applies. The power of the model isn't in what it preserves — it's in the quality of understanding it demands before any change. A reformer who has done the Chesterton investigation and concluded the fence should go is operating from far greater strength than one who never bothered to ask.
Where I see the model fail most often is in technology companies between Series B and IPO. Growth creates pressure to "streamline" and "professionalise." New executives arrive from larger companies and immediately identify processes that look inefficient — and they're often right that the processes look inefficient. The mistake is confusing visible inefficiency with actual waste.
The onboarding documentation that nobody reads — until a production incident reveals it contained the only record of a critical system dependency. The weekly meeting that seems redundant — until its absence means two teams build conflicting features for three months. The approval workflow that adds two days to every deploy — until its removal means a junior engineer pushes unreviewed code that takes down the billing system. I've watched this cycle at half a dozen companies: new leader arrives, identifies "obvious" waste, removes it confidently, and six months later the organisation is dealing with problems that the "waste" had been silently preventing.
The operational test I recommend: before removing any process, policy, or system, require that the person proposing removal write a one-page document answering three questions. First, why was this created? Second, what problem was it solving? Third, does that problem still exist? If they can't answer all three, the removal isn't ready. This isn't bureaucracy. It's the minimum viable Chesterton investigation — and it takes less time than recovering from the consequences of uninformed removal.
One final observation. The model's value increases with institutional age and complexity. A three-person startup has few fences, and the founders remember why each one exists. A 10,000-person company has thousands of fences, and the people who built most of them have left. The half-life of institutional memory is roughly three to five years in most organisations — shorter in high-turnover environments like tech. After that window, the fence stands but the knowledge of why it was built evaporates. This is why documentation isn't optional. It's the mechanism by which Chesterton's Fence remains applicable as organisations scale. Without it, every fence becomes a mystery, and every new leader faces the same temptation: the fence looks pointless, so it must be pointless. The cycle repeats. The consequences accumulate.
Section 10
Test Yourself
The following scenarios test whether you can distinguish between legitimate Chesterton's Fence reasoning, its misapplication as status quo bias, and situations where the fence has been studied and should come down.
The principle is subtle — the line between prudent investigation and reflexive conservatism is thinner than most people realise. Pay attention to whether the person in each scenario has done the investigation or merely cited the principle.
Is this mental model at work here?
Scenario 1
A new CTO at a fintech company discovers that every database migration requires sign-off from three senior engineers — a process that adds two days to every release. She investigates and learns the policy was created after a 2019 incident where an unreviewed migration dropped a production table containing $2.3 million in transaction records. She keeps the policy but reduces the required reviewers to two and adds an automated pre-check.
Scenario 2
A government committee reviewing occupational licensing rules discovers that interior designers in three US states require a six-year apprenticeship and a state exam. When asked why, no committee member, industry representative, or historical record can identify a specific safety incident or consumer harm that prompted the requirement. The committee recommends maintaining the requirement 'out of an abundance of caution.'
Scenario 3
A startup's engineering team wants to replace their monolithic application with microservices. The tech lead asks each engineer to document which parts of the monolith they want to extract and why those parts were originally coupled together. Two engineers discover that the payment and inventory modules share a database transaction because a 2020 bug caused inventory to decrement without payment capture, costing $180K. They keep those modules coupled while extracting the rest.
Scenario 4
A hospital administrator eliminates the requirement for nurses to keep handwritten medication logs alongside the electronic system, calling it 'redundant paperwork from the pre-digital era.' Three months later, a software update corrupts the electronic medication records for an entire ward. With no handwritten backup, the staff cannot verify which patients received which medications during a 14-hour window.
Section 11
Top Resources
The best thinking on Chesterton's Fence spans conservative philosophy, software engineering, policy analysis, and Taleb's broader framework of institutional robustness. Start with the original source, then move to the practical applications in code and governance.
01
Primary source
The original source. Chapter III, "The Drift from Domesticity," contains the fence passage that launched the principle. The rest of the book is Catholic apologetics that most readers skip, but the fence metaphor transcended its context entirely and has been cited in fields Chesterton never imagined — software engineering, regulatory policy, organisational design. Available free on Project Gutenberg. Read the original before reading anyone's interpretation of it.
02
Book
Taleb extends Chesterton's Fence into a full framework for institutional robustness, connecting it to the Lindy Effect and the precautionary principle. His argument — that old practices carry embedded information invisible to current observers — is the most rigorous modern treatment of the idea. The chapters on iatrogenics (harm caused by well-meaning intervention) are directly relevant to anyone making removal decisions. Taleb's insight that the burden of proof should be on the person intervening, not on the existing system, is Chesterton's Fence quantified and operationalised.
03
Essay
Spolsky's essay about Netscape's catastrophic decision to rewrite its browser from scratch is Chesterton's Fence applied to codebases. The "old code" that looked ugly and redundant contained years of accumulated bug fixes and edge-case handling — each ugly line fixing a specific browser incompatibility or platform quirk. Rewriting it didn't just duplicate the functionality — it re-introduced every bug the old code had already solved. Netscape's rewrite took three years, lost the browser wars to Internet Explorer, and nearly killed the company. Essential reading for any engineer inheriting a legacy system and feeling the itch to rewrite.
04
Book
Scott documents how modernist states destroyed functional local institutions — agricultural practices, urban layouts, naming systems — by imposing legible, rational alternatives that performed worse than the "irrational" systems they replaced. The most thorough empirical investigation of what happens when reformers ignore Chesterton's Fence at civilisational scale. His case studies of Brasília's urban planning, Tanzanian villagisation, and Soviet collectivisation all demonstrate the same pattern: confident reformers who didn't understand the systems they were replacing, producing results worse than what they destroyed.
05
Book
The software engineering practitioner's guide to applying Chesterton's Fence to codebases. Feathers's central argument — that legacy code is code without tests, and that understanding must precede modification — is the technical implementation of Chesterton's principle. His techniques for safely characterising and modifying code you don't fully understand — "characterisation tests," the "seam" model, dependency-breaking techniques — are directly applicable to anyone inheriting systems built by others. The book's implicit argument: the uglier the code looks, the more likely it's doing something important that you don't yet understand.
Related playbooks
Cross-cluster links: people, companies, and models that connect to this topic.
Why this matters next
mental modelsOccam's razor
Occam's razor gives the next useful perspective on how Chestertons Fence works in practice.
mental modelsInversion
Inversion gives the next useful perspective on how Chestertons Fence works in practice.
mental modelsIncentives
Chesterton's Fence applied the Incentives mental model
mental modelsDunning-Kruger Effect
Chesterton's Fence applied the Dunning-Kruger Effect mental model
mental modelsSecond-Order Thinking
Chesterton's Fence applied the Second-Order Thinking mental model
mental modelsFirst Principles Thinking
Chesterton's Fence applied the First Principles Thinking mental model
Frequently asked questions
What is Chesterton's Fence?
Chesterton's Fence is the principle that you should never remove a rule, process, or institution until you understand why it was put there in the first place. G.K. Chesterton argued that a fence across a road exists for a reason — and the person who doesn't see the reason is exactly the person who shouldn't be allowed to remove it. In business and engineering, this mental model prevents well-intentioned reformers from breaking systems they don't fully understand. Before dismantling anything — a policy, a codebase pattern, a team ritual — first understand the problem it was solving. The fence may be ugly, but it might be the only thing between you and a stampede.
How do you apply Chesterton's Fence?
To apply Chesterton's Fence, identify situations where this framework is relevant, then use it as a lens to evaluate your options and decisions. The model is most useful when combined with other complementary mental models.
What category does Chesterton's Fence fall under?
Chesterton's Fence falls under the Psychology & Behavior category of mental models. Other models in this category can be found on the Psychology & Behavior hub page.
Why is Chesterton's Fence important?
Chesterton's Fence is important because it provides a structured way to think about problems that would otherwise be approached with intuition alone. Understanding this model helps you avoid common reasoning errors and make better decisions.
Where does Chesterton's Fence come from?
Chesterton's Fence is discussed in the tradition of G.K. Chesterton.
Continue exploring
AHANBEBECDCB
Mental model
Availability Heuristic
We judge the likelihood of events based on how easily examples come to mind, not
Mental model
Anchoring
The first piece of information encountered disproportionately influences all sub
Mental model
Bandwagon Effect
People adopt beliefs, behaviours, and trends simply because others have — popula
Mental model
Bystander Effect
The more people present during an emergency, the less likely any individual is t
Mental model
Cognitive Dissonance
When beliefs and actions contradict, the resulting psychological discomfort driv
Mental model
Confirmation Bias
The tendency to seek, interpret, and remember information that confirms existing
More like this, in your inbox
I send a newsletter every week — free, no spam, unsubscribe anytime.