Software maintenance accounts for 50 to 80 percent of a system's total lifecycle cost, according to decades of engineering research summarized in the peer-reviewed literature on maintenance economics. A large share of that money is spent touching things nobody currently understands....
Software maintenance accounts for 50 to 80 percent of a system's total lifecycle cost, according to decades of engineering research summarized in the peer-reviewed literature on maintenance economics. A large share of that money is spent touching things nobody currently understands. Chesterton's Fence is the principle that keeps that work from turning into an accident: do not remove a rule, a process, or a strange piece of code until you know why it was put there.
The principle is not from a management book. It comes from the English writer G.K. Chesterton, in his 1929 collection The Thing, in an essay called "The Drift from Domesticity." The passage is short and it has outlived almost everything else written that year.
Chesterton imagined a fence built 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,'" he wrote. The wiser reformer answers: "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." The full text is preserved by the American Chesterton Society.
The reasoning underneath it is plain. As the modern definition puts it, reforms should not be made until the reasoning behind the existing arrangement is understood. The fence did not grow there on its own. Someone had a reason, and the burden of proof sits with the person who wants to remove it, not the person who left it standing.
Chesterton's own words for the stakes are worth keeping close. The gate, he noted, was not set up by sleepwalkers who built it while unconscious, nor by lunatics who happened to be loose in the street. A human being placed it there deliberately, for a purpose that made sense at the time, and that purpose may or may not still hold. The point of the parable is not reverence for the past. It is humility about how much of the past you actually understand.
I study behavioral psychology, and this is the part I find fascinating. The people most likely to tear down a fence they do not understand are often the most capable people in the room. Competence and confidence combine into a shortcut: you see something that looks redundant, your mind jumps to "this is obviously useless," and you act before doing the slower work of understanding context.
Chesterton's Fence is a direct check on that shortcut. It does not say keep everything. It says earn the right to remove it by first being able to explain why it exists.
That explanation load is the whole point. A gate you can justify is a gate you can safely take down. A gate you cannot justify is a gate you do not yet understand, which means you are not qualified to judge it. This is the same discipline behind good technology decisions under cognitive bias: the bias you cannot see is the one steering the choice.
The clearest modern version of this shows up in legacy code, where it has become a working rule for careful engineers. The pattern is almost a genre now. A developer joins a project, finds a function that "makes no sense," a mess of conditional checks that "can be a single line," or a method with no obvious caller, and deletes it with a clean conscience.
Then something breaks in production, usually far from where the change was made. One widely shared write-up of the principle tells the standard story: a method that looked unreferenced was in fact called dynamically by a job that ran once a quarter. The code was not dead. It was just quiet.
A second example makes it vivid. Engineers at one company found a mysterious Sleep call sitting in their startup path and removed it as obvious cruft, as Symflower documents. The product then failed to launch for a slice of users, because that pause gave an unrelated component the time it needed to initialize on slower systems. The buffer looked useless. It was load-bearing.
This is why maintenance is so expensive. A meaningful fraction of the 50 to 80 percent maintenance figure is not new features at all. It is the cost of relearning why the last generation of decisions was made, and of repairing the damage when someone skipped that step. Treating maintenance as the job rather than the launch starts with respecting the parts you did not build.
The principle is a check, not a museum. It is not an argument for keeping everything forever, and it is not an excuse to avoid change. Chesterton's own conclusion was that once you can explain the fence, you may well be right to destroy it.
Plenty of fences deserve to fall. A rule written for a regulation that no longer applies, a manual approval step that guarded a system you retired two years ago, a nightly export feeding a report nobody reads: these are real. The discipline is not "never remove." It is "remove on the basis of understanding, not on the basis of not understanding."
That distinction matters because the opposite failure is just as common. A team that cannot explain any of its rules and refuses to touch any of them is not being careful. It is being paralyzed by accumulated mystery, and that paralysis compounds until the whole system becomes untouchable. Understanding is what lets you both keep the fences that work and clear the ones that do not.
Turning the principle into practice is mostly about doing cheap research before making an expensive change. The work is not glamorous, but it is fast compared to a production incident.
Start with the record. In code, that means the commit history, the pull request that introduced the line, and the ticket it referenced. A one-line commit message from three years ago often names the exact bug the "useless" code was fixing. In a process, it means asking who wrote the rule and what went wrong right before it appeared, because most rules are scar tissue from a specific incident.
Then ask the people who were there. Institutional knowledge is a fence in its own right, and it walks out the door when someone leaves, which is why institutional memory that survives turnover is worth building deliberately. If nobody can explain a rule and nobody is left who wrote it, that is not permission to delete it blindly. It is a signal to test carefully in an environment where being wrong is cheap.
Finally, make the change reversible. Remove the fence behind a flag, keep a fast rollback, and watch the system before you commit. Reversibility converts a guess into an experiment, which is the whole reason we build backups and staging environments before we build confidence. Good engineering makes the cost of being wrong small.
There is a respect dimension to all of this that is easy to skip. The people who came before you made their decisions inside real constraints: tight budgets, conflicting requirements, and deadlines that did not care about elegance. You have no proof you would have done better under the same pressure. Assuming the fence is stupid is usually a failure of imagination about the conditions that produced it, not evidence that you are smarter than the person who built it.
There is a real tension here, and it is worth naming honestly. Removing things is usually the right instinct. Systems drift toward complexity, and the discipline to subtract is rarer and more valuable than the urge to add. Chesterton's Fence is not a rebuttal to that instinct. It is the safety rail that keeps subtraction from becoming vandalism.
The two ideas work together. Bias toward removing, and require understanding before you do. That pairing is how you avoid both failure modes: the team that never cleans anything up, and the team that "simplifies" a system into an outage. It is also why the same caution applies to the tasks you should never automate, where a human step often turns out to be a fence guarding judgment, not inefficiency.
Two adjacent biases make this harder in practice. The sunk cost fallacy pushes you to keep a system because of what it already cost, which is the wrong reason to keep a fence. The endowment effect pushes you to overvalue what you already own, which is the wrong reason too. Chesterton's Fence is not either of those. It does not say keep it because it is yours or because it was expensive. It says understand it, then decide.
Held that way, the principle is calm rather than conservative. It is a way of respecting the work that came before without being trapped by it, and it is one of the quieter habits behind deciding what to build in-house and what to let go. We build systems this way on purpose, and it is a recurring theme across the Kief Studio blog and the free engineering resources at kief.dev.
Chesterton's Fence is the principle that you should not remove a rule, structure, or piece of code until you understand why it was put there in the first place. It comes from G.K. Chesterton's 1929 book The Thing, where he pictured a reformer who wants to clear away a fence across a road without knowing its purpose. The wiser reformer insists on understanding the reason before tearing it down.
No. It is a check on careless removal, not a ban on change. Chesterton himself said that once you can explain why the fence exists, you may be right to destroy it. The principle simply moves the burden of proof onto the person removing something, so that decisions are made from understanding rather than from not understanding.
In legacy code it warns against deleting anything that looks unused or redundant before you know its role. Common cautionary examples include a method that turns out to be called by a quarterly job, or a stray pause in a startup routine that gives an unrelated component time to initialize. The safe practice is to read the commit history, ask the people who wrote it, and make the change reversible before committing to it.
Confidence combined with competence creates a shortcut. A skilled person spots something that looks inefficient, concludes it is useless, and acts before doing the slower work of understanding context. That is exactly the reasoning gap Chesterton's Fence is designed to close, which is why it is a discipline rather than an instinct.
No, the two work together. Bias toward removing complexity, and require understanding before you remove. That pairing avoids both failure modes: the team that never cleans anything up, and the team that simplifies a system into an outage. Chesterton's Fence is the safety rail that lets subtraction stay safe.
Only 20 percent of executives say their organizations excel at decision making, and most report that much of the time they spend on it is used ineffectively. A large share of that waste comes from treating reversible decisions as if they were permanent. Amazon has a name for the...
Survivorship bias overstates the typical mutual fund's reported returns by roughly 1.6 percentage points a year, according to the University of Chicago's Center for Research in Security Prices: surviving U.S. stock funds averaged 8.8 percent over the decade ending 2003, while counting...
In a set of experiments published in 2011, people who assembled a plain IKEA storage box valued it 63 percent higher than an identical prebuilt one. The IKEA effect, named by the researchers who ran that study, is the bias that makes you overvalue what you built yourself. It quietly...
Work With Us
Kief Studio builds, protects, automates, and supports full-stack systems for businesses up to $50M ARR.
Newsletter
Strategy, psychology, AI adoption, and the patterns that actually compound. No spam, easy to leave.
Subscribe
