Don't tear down the fence until you know why it's there

In 1929, G.K. Chesterton described an imaginary reformer walking down a road who comes upon a fence stretched across it for no reason he can see. “I don’t see the use of this,” the reformer says; “let us clear it away.” To which Chesterton has the wiser man reply: no. “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 point is not that fences are sacred. It’s that not understanding why something exists is precisely the wrong reason to remove it — because the failure to see the reason is a fact about you, not about the fence.

This is, quietly, one of the most important principles in software, and it goes against a deep engineering instinct. We are trained to clean up, to simplify, to delete. And most of the time that instinct is right and good. But every codebase of any age is full of fences: a null check that guards against nothing you can find, a retry with an oddly specific delay, a workaround with a comment that just says “don’t remove this,” a step in a deploy script that seems to do nothing, a config flag no living person set. The confident, tidy-minded move is to sweep them away — this is obviously cruft. And sometimes it is. But often that “pointless” null check is the scar tissue around a production incident from three years ago, the fix for a bug that will silently come right back the moment the guard is gone. The code looks useless for the same reason the fence does: the thing it was protecting against isn’t visible from where you’re standing, precisely because the protection is working.

So the discipline is small and specific: when you hit code you want to remove and can’t explain, treat the not-understanding as a stop sign, not a green light. Read the blame. Find the commit, the PR, the ticket, the incident that put it there. Ask the person whose name is on it, if they’re still around, or the oldest engineer who might remember. The goal isn’t reverence — it’s earning the deletion. Chesterton’s wiser man isn’t saying the fence can never come down. He’s saying you have to be able to state why it went up before you’re allowed to take it down. Once you can — “this guarded against a malformed payload from a vendor we no longer integrate with” — you can remove it with total confidence, and should, because now the deletion is informed instead of lucky.

The obvious objection is that this could justify keeping every piece of cruft forever — cargo-cult reverence for code nobody understands, which is its own serious disease. But that’s a misreading, and an important one to correct. Chesterton’s Fence is not “never remove things.” It’s a gate, not a ban: it puts understanding between you and the delete key, and once you’ve passed through it, removal is not just allowed but encouraged. A codebase where nobody dares touch anything is as broken as one where everyone deletes freely; the principle threads exactly between them. It also cuts the other way as a build rule — when you’re the one erecting a fence (a guard, a workaround, a special case), leave a note on it. The comment that says why, the linked incident, the test that encodes the reason, is you being kind to the future reformer, giving them the understanding they’ll need to eventually, safely, take your fence down.

None of this is a proven law; it’s a reasoning principle. But the failure it names is one every experienced engineer has lived through — the clean, confident refactor that removed the “unnecessary” thing and brought back a ghost. The lesson isn’t to stop cleaning up. It’s that in an old system, “I don’t understand why this is here” and “this is safe to remove” are two completely different statements, and the entire craft is in never letting yourself mistake the first for the second.