Chesterton's fence

ops cultureprogramming

The principle that you should not remove something until you understand why it was put there.

The parable: do not tear down a fence across a road just because its purpose is not obvious, because someone had a reason you may not see. In code, it is the caution against deleting the strange line, the odd check, or the legacy workaround before you learn what quietly depends on it.

Chesterton's fence is the argument that you should not remove something until you know why it was put there. The original passage describes a fence across a road: the reformer says it serves no purpose and should go, and the reply is that if you do not know why it exists, you are not yet qualified to remove it. Find the reason first, then remove it if the reason is gone.

In software this is the mysterious configuration line, the check that appears redundant, the sleep call in the middle of an initialization routine. Someone put it there, probably at three in the morning, probably after an outage. It looks like noise because the incident it prevents has not happened since it was added, which is what a working fix looks like from the outside.

The principle has a real counterweight, and stating only the first half turns it into an argument for never changing anything. Sometimes the fence was built for a reason that no longer exists, sometimes nobody remembers and nobody can find out, and a codebase that never removes anything accumulates until it cannot be reasoned about at all. The discipline is proportional investigation: spend effort finding the reason in proportion to what the fence costs and what removing it risks.

Also known as: Chesterton's gate

← All glossary entries