You're reading old code and you find a line that makes no sense, a random Sleep, a bizarre conditional, a comment that says "do not remove." The instinct is to clean it up. A hundred-year-old principle called Chesterton's Fence says otherwise: don't, until you understand why it's there. That weird line is load-bearing more often than you'd think.
Key Takeaways
- Chesterton's Fence: don't remove something until you understand why it was put there (the principle).
- In code, "obviously useless" lines are often load-bearing for reasons that aren't visible locally.
- The safe move is to find the reason first, then decide, rather than delete and discover.
- It's the discipline that makes changing legacy code safe.
The Principle
The idea comes from G.K. Chesterton. Imagine a fence across a road that seems pointless. The reformer says "I don't see the use of this; let's clear it away." The wiser response: "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" (Chesterton's Fence). The point is subtler than "the fence is sacred": not seeing a reason is different from there being no reason.
Why Code Is Full of Fences
Software is built by many people over years, reacting to bugs, outages, and edge cases nobody documented. So a codebase accumulates fences: lines that look arbitrary but encode hard-won knowledge. The classic example: a programmer finds a Sleep call in the middle of an authentication library, decides it's obviously pointless, and deletes it, only to discover the Sleep was a buffer that let a completely unrelated, slow-starting component come up correctly on certain operating systems (Chesterton's Fence in software). The line looked useless locally. Its reason lived somewhere else entirely.
This is the same insight behind why old code carries hard-won bug fixes: the cruft is often the accumulated scar tissue of real problems.
The Discipline
Chesterton's Fence is a simple habit: before you remove something you don't understand, find out why it's there. Check the git blame and the commit message. Ask the person who wrote it, if they're still around. Search for the bug or ticket that introduced it. Often you'll discover a real reason and leave the fence standing. Sometimes you'll find the reason is genuinely obsolete, and now you can remove it safely, with confidence instead of a guess. Either way you decided with knowledge (a mental model for engineers).
| Instinct | Chesterton's Fence |
|---|---|
| "This looks useless, delete it" | "Why is this here?" |
| Remove, then discover the reason | Find the reason, then decide |
| Break something invisibly | Change safely |
A Concrete Version
A new engineer, cleaning up, finds a strange retry-with-delay wrapped around one specific API call. It looks like over-engineering, so they simplify it away. Two weeks later, that call starts failing intermittently in production, because the delay was working around a known rate limit on the third party's side that nobody documented in the code. The "cleanup" reintroduced a bug someone had already solved. Five minutes of git blame would have shown the commit: "add backoff for ACME rate limit, see incident #214."
The Honest Counterpoint
Chesterton's Fence is not an excuse to never change anything, and treating every line as sacred is its own failure, that's how codebases calcify into museums nobody dares touch. The principle is about understanding rather than preservation. Once you understand why a fence is there, you're fully entitled to tear it down if the reason is gone. The rule adds one step, find the reason, and that step is cheap: usually a git blame and a commit message. It buys you the right to change confidently instead of gambling.
What This Means for Teams
Respecting Chesterton's Fence is a hallmark of engineers who work safely in code they didn't write, which, as we've covered, is most of the job. A junior deletes the confusing line; a senior asks why it's there first. That instinct to understand before changing is exactly the judgment we screen for in how to verify a senior engineer, and it's what keeps a team from re-solving the same bugs. It also depends on the practices that preserve the reasons: good commit messages, documentation, and a healthy bus factor. See available engineers.
Frequently Asked Questions
What is Chesterton's Fence?
A principle from G.K. Chesterton: don't remove or change something until you understand why it was put there. Not seeing a reason isn't the same as there being no reason.
How does it apply to code?
Codebases accumulate lines that look arbitrary but encode hard-won fixes for bugs, outages, and edge cases. Before deleting "obviously useless" code, find out why it exists, often via git blame or the original ticket.
Isn't this just an excuse to never refactor?
No. The principle is about understanding, not preservation. Once you know why a fence is there and the reason is obsolete, you can remove it confidently. It adds one cheap step: find the reason first.
How do I find why code exists?
Check git blame and the commit message, search for the bug or ticket that introduced it, and ask the author if they're around. Good commit messages and docs make this fast.
The Bottom Line
The weird line you want to delete is load-bearing more often than it looks, because code accumulates fixes nobody documented in place. Chesterton's Fence adds one cheap step before you remove something you don't understand: find out why it's there. Then decide with knowledge instead of gambling, and stop re-solving bugs someone already fixed.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
