Every codebase has one. A function nobody wants to touch, guarded by a check so strange it looks like vandalism: an off-by-one bound that saves the February leap-day import, a sleep(300) that prevents a race with a mainframe in another timezone, a hard-coded constant that is secretly a serial number from a 2009 tax regulation. The comment above it says // DO NOT REMOVE, the comment below says // you have been warned, and the person who wrote both left the company before you joined.
The instinct of every competent engineer is the same: this is debris, delete it. The instinct is wrong more often than we admit, and the reason is a century-old essay about fences.
The fence
G.K. Chesterton, writing in his 1929 book The Thing — the essay “The Drift from Domesticity” —, gave software engineering its most useful parable without ever seeing a computer:
There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer would do well to answer: “If you don’t see the use of it, I certainly don’t advise you to 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.”
Translate road to codebase and the parable loses nothing. The fence is the weird branch in the invoice printer, the stored procedure with the extra parameter nobody passes, the check for a condition that “can’t happen.” It was erected by someone who watched something break. The fact that you cannot see why it exists is not evidence that it serves no purpose — it is evidence that the system’s history is longer than your tenure.
Why software grows especially strange fences
Chesterton’s fence is universal advice, but software is uniquely prone to growing fences, for a structural reason: code accumulates constraints from the world faster than the world forgets them. Every production incident plants one. Every integration with an external system — especially systems you cannot see, audit, or contact — plants several. Tax rules change on schedules uncorrelated with your release calendar. Customers depend on bugs (“we’ve always exported the file with the trailing comma; our importer expects it”). The migration archive of any long-lived system is not a museum of past mistakes; it is a sediment of load-bearing constraints, most of them undocumented because documentation is the first casualty of the deadline that planted them.
There is a deeper asymmetry at work. Removing a fence that was useless costs you a cleanup PR and a small dopamine hit of tidiness. Removing a fence that was load-bearing costs an outage, a rollback, and — this is the part that compounds — a permanently degraded willingness to trust the rest of the codebase. Breakage teaches the whole team to fear the system. Tidiness teaches nothing. The expected value of deletion without understanding is negative even when the fence is usually useless.
The discipline, not the dogma
The parable is often quoted as conservatism: never change anything you don’t understand. Read it again — that is not what it says. Chesterton’s reformer is not told to leave the fence forever. He is told to go away and think, and that destruction is permitted — explicitly permitted — once the use is understood. The fence is not sacred. Understanding is the prerequisite, not preservation.
In engineering terms, the discipline looks like this:
- Blameless archaeology.
git log,git blame, the linked ticket, the incident report. Most fences have a commit message that explains them; the explanation just lives five years deep. Finding it is hours; replacing the knowledge after the outage is weeks. - Exercise the fence before demolishing it. Write the test that fails when it is removed. If you cannot construct such a test, that is information: either the fence is dead, or your test coverage cannot see what it protects. Both are worth knowing before you act, and only one of them means “delete.”
- Distinguish fence from scar. Some strange code is not a fence but a scar — evidence of an incident that cannot recur (the vendor API was fixed, the regulator changed the rule). Scars can be removed; the archaeology is how you tell them apart. A scar you mistake for a fence is clutter; a fence you mistake for a scar is an outage.
- Replace, don’t just remove. The best refactors do not delete a fence; they replace it with something that carries the same load legibly — a named constant instead of a magic number, a validation rule instead of a defensive parse, a documented invariant instead of an unexplained branch. The fence’s job survives; its weirdness doesn’t.
The fence as a message from your predecessors
There is a habit of mind that separates this from checklist archaeology, and it is closer to courtesy than to caution. The person who planted the fence was not stupid. They were, statistically, exactly as intelligent as you, working with less information than you have, under more pressure than you are under, in a system that has since drifted. The fence is their message to you across time: something here hurt me; I stopped it the best way I could. Reading it that way changes what you look for. You stop asking “why is this code bad?” and start asking “what was coming through this road?”
Teams can institutionalize this reading. An ARCHITECTURE.md that lists invariants and their origins. A tradition of writing incident learnings next to the code they concern, not in a wiki three links away. Commit messages that say why, not what. The migration to a new platform where every “temporary” compatibility branch gets a removal ticket instead of a shrug. These are all fence-maps: institutional memory that makes the next reader’s archaeology cheap.
When you get to tear it all down
The payoff of the discipline is that eventually you earn demolition. Once you can explain a fence — once you can name the load it carries, point at the ticket, write the test that proves the constraint is real — destroying it is not vandalism but graduation. Sometimes the explanation is “the constraint died in 2019,” and the deletion is pure profit. Sometimes the explanation is “the load is real, and here is the modern component that should carry it,” and the fence comes down as part of a real migration. Both are the same act: understanding converted into change.
And there is a quiet career truth hiding in the parable’s last line. The reformer who returns able to explain the fence is not the same person who walked up to it. The thinking changed them. They now know the road, the traffic, the reason the gate was shut — they have become, in the old unglamorous phrase, the engineer who understands the system. That is the person you want making the call. It is also, incidentally, the person the parable’s author would have trusted with the sledgehammer — and the only one the fence was ever waiting for.