Chesterton’s Fence in Code Reviews: Why You Should Never Delete What You Don’t Understand

TL;DR: When you find a weird piece of code and you don’t know why it’s there, resist the urge to delete it right away. Chesterton’s Fence is a simple rule of thumb: don’t tear down a fence until you understand why someone put it up. In code review, that means checking history, asking around, and only removing something once you know what it was protecting against — otherwise you risk reintroducing a bug someone already fixed once.

The problem

Picture a mid-level engineer named Priya. She’s cleaning up an old payments service before adding a new feature. Halfway through the file, she finds this:

// wait 200ms before retrying
if (attempt > 0) {
  await sleep(200);
}

There’s no comment explaining why. No ticket number. No name attached. It just looks like someone forgot to remove a leftover delay from debugging. Priya is confident, the code is cleaner without it, and the tests still pass. She deletes it, opens a pull request, and moves on.

Two weeks later, the payments service starts hammering a third-party billing API so hard during outages that the vendor starts rate-limiting every request, including the ones that would have succeeded. It takes the team most of a day to trace the outage back to that one deleted line. The 200ms delay wasn’t leftover debugging code. It was a fix for a real incident, put there by someone who left the company a year ago.

This is the exact trap the philosopher G.K. Chesterton described almost a century ago, long before software existed. He imagined a fence built in the middle of a field for no obvious reason. A certain kind of reformer sees it, decides it serves no purpose, and tears it down. Chesterton’s point: the sensible response is not to remove the fence because you don’t see its use. It’s to go find out why it’s there, and only then decide whether to remove it. In code, “the fence” is any piece of logic that looks unnecessary but was actually put there on purpose.

The “why” behind old code usually isn’t malicious neglect. It’s just knowledge that never made it into a durable place.

Why it happens

This isn’t really a story about a careless engineer. It’s a story about how context quietly disappears from a codebase over time. A few things usually cause it:

• The person who wrote it is gone. Whether they left the company or just moved to a different team, the reasoning that lived in their head left with them.
• There was no comment or ticket link. The fix went in fast, probably during an incident, and nobody circled back to document it once things calmed down.
• It was “tribal knowledge.” Everyone on the team knew about it at the time, so writing it down felt unnecessary. A year later, the team has turned over and the knowledge is gone.
• The code looks like an accident. A single conditional or a short delay doesn’t look like a deliberate decision. It looks like clutter. That makes it an easy, low-friction target for cleanup.

None of this is anyone’s fault, exactly. It’s just what happens to information that only ever lived in people’s heads or in a Slack thread from fourteen months ago. The code survives. The reasoning behind it doesn’t, unless someone made a point of preserving it.

The better approach

Chesterton’s Fence doesn’t mean “never delete anything you don’t fully understand, forever.” That would freeze a codebase solid. It means: before you remove something that looks unnecessary, spend a little effort finding out why it’s there. Only once you understand it — or you’ve made a real effort and genuinely found nothing — should you decide whether it’s safe to go.

In practice, that’s a short checklist, not a research project:

1. Read the history first. Run git blame on the line and read the commit message. Then look at the linked ticket, if there is one. This alone answers the question most of the time.
2. Search for related incidents. If your team keeps a postmortem or incident log, search it for keywords from the code or the file name. Weird-looking fixes are disproportionately likely to trace back to a real outage.
3. Ask before you assume. A quick message to the team, or to whoever’s been around longest, is cheap. “Does anyone know why we retry with a 200ms delay here?” takes thirty seconds to ask and can save a day of firefighting.
4. If nobody knows, don’t just delete it blind. Turn it off behind a feature flag or a config value instead of ripping it out entirely, and watch what happens for a while in a lower-risk environment first. If nothing breaks, remove it for real and, this time, leave a comment explaining that you checked.

The goal isn’t to block every removal — it’s to make sure someone actually checked before pulling the fence down.

It also helps to think about this as a two-axis decision: how well do you actually understand the code, and how bad would it be if you’re wrong? Something you fully understand and that’s low-stakes if you’re wrong (an unused CSS class, say) is safe to just remove. Something you don’t understand and that’s high-stakes if you’re wrong (an old auth check, a retry with backoff) deserves real investigation before you touch it.

Not every unexplained line deserves the same amount of caution — match your investigation effort to the actual risk.

Pitfalls to avoid

Chesterton’s Fence is a genuinely useful habit, but it’s easy to take too far in either direction.

The first failure mode is using it as an excuse to never clean anything up. Some engineers hear “understand it before you remove it” and quietly translate that into “never remove anything, ever, just in case.” That turns a reasonable caution into a reason to let dead code and unused feature flags pile up forever. The rule isn’t a ban on deletion. It’s a requirement to look before you leap. Once you’ve actually looked and found nothing, removing the code is the right call, not a risk you’re taking.

The second failure mode is treating a five-minute check as if it needs a full investigation. Not every unexplained line is guarding against a payments outage. Most of the time, a quick look at the git history and a message in the team channel is genuinely enough. Save the deeper digging — searching incident logs, tracking down a former teammate — for code that touches something risky: money, security, data integrity, or anything customer-facing. Match the effort to the blast radius, not to how mysterious the code looks.

Finally, don’t forget to close the loop for the next person. If you investigate a weird piece of code and figure out why it’s there, write that down in a comment or a commit message before you move on. The whole reason this pattern keeps repeating is that the last person who understood the fence didn’t leave a note explaining it. Be the one who does.