What is Chesterton's fence?

Chesterton's fence is the principle that you should not remove a rule, a check, or a piece of code whose purpose is unclear before you have understood why it was put there. It comes from a passage in G. K. Chesterton's 1929 book The Thing, chapter "The Drift from Domesticity": there is a law comparable to a fence erected across a road, and the careless reformer approaches it saying he does not see the use of it, so it should be cleared away. The intelligent reformer answers that if you do not see the use of it, you are not entitled to destroy it: go away and think, and when you can tell me you do see the use of it, then I may let you take it down. In software it is the question anyone inheriting a legacy system runs into every week, facing a double check, a duplicated field, a cron job that runs at three in the morning and nobody can say why.

See also: Sunk cost fallacy · The sunk cost fallacy is the error of funding a project for what was already spent and cannot be recovered, rather than for the result it can still produce.

The source, and a protocol before touching anything

The original passage is not about software but about social institutions. Applied to code, the principle does not say "never touch anything you don't understand": it says the hypothesis about why something exists has to be formed and tested before acting, not after. The protocol I use whenever I inherit a system follows the same order of inquiry every time. First the version control history: the commit that introduced the line, its message, the linked ticket if one exists. Then the application logs, to see whether that branch of code still runs and how often. Then people: whoever has been in the company the longest often remembers the incident that triggered that patch, or the holiday that crashes the batch job without that check. Then the tests: a suite covering that branch often preserves, in the case name, the reason the commit never wrote down. Then whoever consumes it downstream, because a field that looks useless may be read by a report or an integration nobody ever inventoried. Only when none of these sources yields an explanation, and the logic behind the cron job or the field stays genuinely opaque, do you move to measuring it in production: instrument that branch so it records every time it fires and what it blocked, and let it run through a full cycle, month-end close included. Only if it never fires do you remove it, behind a switch that lets you put it back in minutes. Disabling it in a test environment proves little: the data that motivated the check, a defaulting customer or a public holiday, is not in test. This is the territory of software rescue: not rewriting the system, as the strangler fig pattern does, but deciding whether one thing gets touched or left alone.

An enterprise example

At a manufacturing SMB a customer order goes through two credit checks, one in the order management system and one identical-looking one, apparently redundant, in the invoicing module. The natural suspicion is leftover technical debt from an old contract. The version history shows instead that the second check was added three years after the first, with a commit message citing a specific client that defaulted precisely in the window between order approval and invoice issuance, once the first check had already expired. The check is not duplication: it is coverage for a real time-based risk. Removing it without that verification would have reintroduced exactly the incident that caused it.

When the principle should be disobeyed

Chesterton's fence, taken as dogma, paralyzes any cleanup: if every suspicious line requires an exhaustive investigation before it can be touched, modernization never starts, because the time needed to investigate grows with system size faster than the time needed to act. The principle has a cost, and that cost has to be weighed against the alternative: when investigating a single doubtful check would take weeks, involves people who no longer work at the company, and concerns a low-risk function if it turns out wrong, it is often better to leave the fence standing, isolate it with a test that documents its current behavior, and move on to the next problem. The principle exists to buy time before deciding, not to forbid the decision.