· Systems Thinking · 15 min read

Chesterton's Fence: Don't Delete What You Can't Explain

Last week I called software geology. This week it gets a name: Chesterton's Fence. A tour through roundabouts, the human appendix, and a cronjob nobody dares touch — and why 'I don't see the point' is the worst possible reason to remove anything.

Last week I called software geology. This week it gets a name: Chesterton's Fence. A tour through roundabouts, the human appendix, and a cronjob nobody dares touch — and why 'I don't see the point' is the worst possible reason to remove anything.

Last week I told you that software is geology. Layers pile up on top of one another and simply refuse to leave, like relatives after Christmas dinner. Dig into an old codebase and you’re not reading architecture, you’re reading sediment — every weird boundary a fossil of some team that has since merged, split, or been quietly reorganised into the sea.

I even handed you a corpse. Smarty 3, the PHP template engine whose authors decided to rebuild the whole thing from scratch to shed the accumulated cruft. The first beta was genuinely faster. Then it met the real world, all the edge cases that version 2 had been quietly absorbing for years came shuffling out of the dark like extras in a zombie film, and the “I’ll do it properly this time” rewrite ended up slower than the thing it replaced. The cruft, it turned out, wasn’t cruft. It was years of scar tissue, and scar tissue is there because something once tried to kill you.

What I didn’t do last week was name the beast. Because it has a name, and a gloriously smug one: Chesterton’s Fence.

So today I’m connecting a few dots I’ve been leaving all over this blog for months, apparently under the impression that nobody would notice I was making the same point in five different costumes.

The parable, for people who don’t read hundred-year-old paradox-mongers

The idea comes from G.K. Chesterton, entombed in a 1929 book called The Thing. You don’t have to read it. I read it so you wouldn’t have to. And I would like those hours back, ideally with interest. Here’s the entire argument in a single scene.

Picture a fence standing across a road. No sign, no plaque, no helpful QR code, nobody within shouting distance who can tell you who built it or why. Along comes a brisk, modern, forward-thinking reformer — the kind of man who has opinions before he has information — and he takes one look and announces: “I don’t see the use of this; let us clear it away.”

And here’s the bit everyone amputates from the quote. The clever answer is not “good idea, mate.” It’s the exact opposite. It’s: if you can’t tell me why it’s there, then I most certainly will not let you remove it. Go away. Think. Come back when you can explain what it’s for — and then, perhaps, I’ll let you tear it down.

That’s it. That’s the whole fence. Centuries of reprints and it’s basically a bloke refusing to let another bloke touch a fence.

Now notice what it does not say, because roughly everyone who cites it gets this backwards. It does not say the fence is sacred. It does not say old things are wise. It does not say you can never change anything — it literally ends with permission to demolish. It says something much narrower and far more annoying: your inability to see the point is a fact about you, not about the fence. Somebody built that thing. Someone stood in a field with post-hole diggers and a genuine reason. “I don’t get it” is the beginning of your homework, not the end of the fence.

(An aside for the pedant already flexing his fingers over the comment box: the punchy version you’ve seen on LinkedIn under a photo of a mountain — “don’t remove a fence until you know why it was put up” — isn’t actually Chesterton. That’s a paraphrase John F. Kennedy was fond of. Chesterton wrote the road and the reformer. Kennedy wrote the caption.)

The natural enemy of the fence

So who goes around demolishing fences unexamined? I’ve introduced this creature before. In my long, cynical history of data protection, I gave it a name: technocentrism. The warm, comfortable conviction that everyone who lived before us was an idiot fumbling in the dark, and that this time it’s different because we, uniquely in human history, have — choose your decade — steam, electricity, computers, the cloud, blockchain, and now the machine that autocompletes our sentences.

I once had an engineer inform me, with the untroubled serenity of a man who has never once been ambushed by his own code at 2 a.m., that he “looks to the future” and “isn’t interested in the past.” He offered this as a personal virtue. What he was actually announcing, translated into plain English, was: I intend to knock down fences I have decided, in advance and on principle, never to understand. And he was damn proud of it.

The inconvenient thing about fences is that they remain load-bearing whether or not you find them interesting. So let’s go and look at three of them — three fences flattened by people who were absolutely certain they didn’t need to ask — in ascending order of how much it ought to worry you.

Fence one: the roundabout

Drivers hate roundabouts. Specifically, they hate them for “slowing everyone down,” a complaint usually delivered at full volume from a car that is, at that precise moment, stationary at a set of traffic lights.

Here’s what they’re getting wrong. They’re staring at the speedometer at the one moment they have to slow down — entering the roundabout, easing off, muttering — and drawing a sweeping conclusion about the entire journey from that single humiliating second. But the number that actually decides when you get home is not your speed at any one junction. It’s your journey speed: total distance divided by total time across the whole drive — the lights, the queues, the pedestrian who chooses now, the school zones, all of it.

And journey speed goes up. Not because roundabouts invite you to drive like you’re being chased (please don’t, there are children and at least one dog), but because the single most expensive thing a car can do is come to a dead stop and then heave itself back up to speed again. Pulling away from nothing burns the most fuel and eats the most clock. A roundabout sells you a few seconds of slowing down and buys you the far greater luxury of almost never fully stopping — and it does this from every direction at once, instead of freezing three roads solid so the fourth can enjoy its turn at the green light like a smug only child.

The numbers are not shy. Converting signalised junctions to roundabouts is associated with something like 90% less delay, over half the stops gone, 30–50% more capacity, roughly a third less fuel burned, and — the one that really ought to end the conversation — up to 90% fewer fatal crashes. There’s one honest caveat: at a single busy junction, total delay occasionally ticks up by a fifth. Which is, if anything, the whole point in miniature. The driver is heroically optimising a local metric — my speed, right here, right now — at the direct expense of the global one — my total time, my fuel bill, and, as a small bonus, whether I arrive at all.

If that shape sounds familiar, it’s because I wrote a whole post about it: every optimisation creates a new blind spot. The roundabout is a fence disguised as an inconvenience. And I’ll confess I know this intimately, because knowing all of the above has never once stopped me from swearing at a roundabout in real time. Understanding the fence and resenting the fence turn out to be entirely compatible.

Fence two: the appendix

Let’s escalate from your commute to your own abdomen.

For most of the second half of the twentieth century, the medical consensus on the human appendix was a confident shrug. Vestigial. An evolutionary typo. A little dead-end pouch left in the first draft that nobody got around to deleting — one of those # TODO: remove? notes that quietly outlives everyone who could explain it. And so the operating logic was magnificent in its simplicity: it’s inflamed, we don’t know what it’s for, therefore it’s for nothing, therefore — scalpel. Which is roughly the reasoning I once used to throw out a small unlabelled component of the coffee machine, on the confident grounds that I didn’t recognise it. The coffee machine has views about that to this day.

Then the early 2000s arrived, and it turned out the organ that does nothing does, in fact, do something faintly important. The appendix is a dense patch of gut-associated lymphoid tissue. It’s a major site of IgA production (don’t worry, I also don’t know what that means). It appears to act as a “safe house” for your beneficial gut bacteria — a backup reservoir that can quietly re-seed the intestine after some catastrophe has evicted everyone else. Not nothing. In fact, embarrassingly far from nothing, given how casually we were binning it.

And how many people collected a complimentary allergy or autoimmune souvenir on their way out of surgery? That, I’m afraid, is a longer and much muddier post. Because — and I’m going to be scrupulously fair here, since the entire thesis of this essay is don’t leap to the conclusion you fancy — the evidence is associational, not causal, and it cheerfully points both ways. Appendectomy correlates with a higher risk of some conditions and a lower risk of others; it seems mildly protective against ulcerative colitis, for instance. It’s a genuine tangle, and nobody gets to stand on a chair and shout “they took my appendix and gave me hay fever.”

But that’s not the damning part, and here’s where Chesterton walks in. The surgeon in 1975 did not say: “I understand what this organ does, I’ve weighed it against the risk of it exploding, and in this case removal is the right call.” That would have been a medical decision — a good one, quite possibly the identical one. What he said was: “I don’t know what it’s for, so it’s presumably for nothing.” And that isn’t medicine. That’s technocentrism holding a scalpel and radiating confidence. The mistake was never in the final tally of who got sick. The mistake was travelling from I don’t understand this straight to so I’ll cut it out without stopping anywhere in between to think.

Fence three: the cronjob nobody touches

And now, home. Your own codebase, where the fences are legion and the signage is nonexistent.

You know the one. The cronjob that’s been running since before your first day, that nobody can explain, that sits in the corner of the crontab like a spider everyone has silently agreed not to mention. The dead code path. The feature flag guarding a case no living employee remembers. The step in the deploy process that is so obviously pointless bureaucratic barnacle that removing it feels less like a task and more like a public service.

And one fine sprint, someone — possibly you, radiant with productivity, holding a “cleanup” ticket and the serene moral authority of a person deleting work he didn’t write — rips it out. Ships it. Green build. You feel like a surgeon. You are, it turns out, being exactly the surgeon from the previous section.

Because three weeks later a very specific and very expensive thing detonates. That cronjob was the only thing re-syncing one obscure account type. That “pointless” deploy step was added, in blood, after an outage in 2019 that nobody thought to write down because everyone involved assumed they’d remember, and then all of them left. It was a fence. You couldn’t see the road it crossed, so you concluded, with great confidence, that there wasn’t one. There was. There’s always a road. That’s why someone went to the trouble of the fence.

This is the same fossil I waved at you last week — the geological layer that reads as gibberish until you work out which long-vanished team laid it down. The only thing I’m bolting on today is the discipline: before you chisel a fossil out of the rock, you find out why it’s there. Every idiotic-looking step in a process is a candidate fossilised postmortem. Somebody’s very worst night is compressed into that stratum. Read the sediment before you reach for the dynamite.

What this is emphatically NOT

Right. Before half of you rush to the comments (which don’t exist here anyway): this is not a licence to change nothing, ever, forever. I have to say this loudly, because “Chesterton’s Fence” has quietly become the favourite mental model of every architect who wants a philosophical-sounding excuse to freeze a system in amber and coast to retirement inside it, like a very well-paid insect.

The fence is not holy. Chesterton is not your great-uncle explaining that music was better when he had hair. The principle is not “we’ve always done it this way” in a bow tie. You are allowed to tear the fence down. You are, very often, completely right to — because a magnificent number of fences were erected for reasons that have since expired, and dragging those into the present is its own special idiocy, one I’ve committed with enthusiasm.

The rule is only, boringly, this: understand first, demolish second. History — in a codebase, a body, a city, a company — does not deserve worship. It deserves diagnostic respect. You dig up the reason not so you can kneel before it, but so you can hold it up to the light and decide, like an adult, whether it’s still true. Sometimes it flatly isn’t. Then swing away, and enjoy it.

The bill always arrives

Which brings me, with a grim inevitability, to the last two years.

The industry has spent them in a collective trance labelled “AI, all the way,” and in the stampede a truly heroic number of fences got flattened at once — tests, code review, cost analysis, the eccentric old habit of asking whether a thing is worth building before building it — all cheerfully bulldozed because it’s different now, because the machine writes the code, because velocity, because vibes.

It got bad enough that people began publicly celebrating lines of code again. Lines of code. A metric so hollow that we were openly mocking it decades ago — in that line usually shoved into Bill Gates’s mouth, that measuring programming progress by lines of code is like measuring aircraft-building progress by weight. Resurrecting that as a badge of productivity isn’t innovation. It’s the same old obsession with measurement I’ve complained about before, crawling straight back through the gap the moment you pull out the discipline that was keeping it out. Turn a number into a target and it stops being a measurement — a sentence I’ve written before and am now contractually obliged to keep writing until the heat death of the industry (yeah, I wasn’t first – you might have heard of Goodhart’s Law before).

And now, in the last few weeks, a bold new idea is sweeping the discourse: perhaps we should think about cost, and ROI. Revolutionary. Except it isn’t a discovery — it’s the invoice. It’s what turns up after you flatten every fence on the property at once and the road turns out to have had rather a lot of traffic on it. Technocentrism always settles the same tab. It just settles late, with interest, and almost never out of the wallet of whoever swung the wrecking ball.

The engineer’s actual job

Let me leave you with the version of all this that I’ve actually lived, since it’s the reason I bang on about it.

Management, broadly, believes the engineer’s job is to complain. To nitpick. To materialise at the worst possible moment, like a fire alarm with opinions, and explain why the exciting thing is secretly a problem. Over a decade ago — and I want to lean on over a decade, because absolutely none of this has aged a single day — a product owner I worked with took me aside and told me, with real feeling, that he thought I was sabotaging his work. That I was forever finding problems. Always in the way.

I told him the truth, which was that sabotage genuinely hadn’t crossed my mind (partly because it would have required even more meetings). My job, I said, is to surface the risk. Your job is to weigh it. If you look at a risk I’ve flagged and decide it’s acceptable — wonderful. Truly. That’s your call, and I’ll help you ship the thing with a smile. But to make that call, you have to know what you’re accepting. Otherwise you haven’t made an informed decision. You’ve made a lucky guess wearing the costume of leadership.

He went away and thought about it — which, you’ll notice, is precisely what Chesterton’s second reformer is ordered to do. I’d like to claim I planned that. I didn’t.

And here’s the part I actually think about. Once he’d sat with it, he didn’t merely tolerate the nitpicking — he came to want it. When our paths eventually parted, he said, out loud and in front of people, that working with me had been one of the most valuable experiences of his career. I’m not telling you that to buff my own halo (all right — a little; the halo doesn’t buff itself). I’m telling you because the shift is the entire point. He stopped seeing the man who checks the fences as an obstacle, and started seeing him as the man who makes sure you know exactly what you’re tearing down before you tear it down.

That’s not a personality upgrade. That’s just, at long last, understanding what the fence is for.

P.S. The image illustrating this post is a riff on a popular meme: the gate that stands guard over nothing, no fence in sight. Instinct says: absurd. But there could be hundreds of reasons. A property marker, so the owner has legal standing on trespassing. A removed — perhaps only temporarily — electric fence, which is what the Wikimedia description actually suggests. Some regulation requiring a gate. Or maybe sheer sentiment: the one surviving piece of a family home that burned down, kept standing on purpose. We don’t know. Which is, of course, the whole point.

Photo: Sergei Gutnikov, CC BY-SA 3.0, via Wikimedia Commons.

The principle and its historical demolitions

The original parable, and three fences torn down by people who never asked what they were for.

4 sources
  • Archive.org G.K. Chesterton 1929Accessed: 2026-08-09

    The 1929 essay collection whose chapter "The Drift from Domesticity" contains the fence-across-a-road parable. The snappy "do not remove a fence until you know why it was put up" is a later paraphrase popularised by John F. Kennedy, not Chesterton's own wording.

  • Insurance Institute for Highway Safety (IIHS) Wen Hu 2026Accessed: 2026-08-09

    Converting conventional intersections to roundabouts is associated with large reductions in delay and stops, higher capacity, and steep drops in injury and fatal crashes — the counterintuitive fence that looks like an obstacle and is actually a throughput valve.

  • American Association for Anatomy Michel Laurin, Mary Lou Everett, William Parker 2011Accessed: 2026-08-09

    One of the papers dismantling the "vestigial organ" story: the appendix as gut-associated lymphoid tissue and a "safe house" for commensal flora. Note the honest caveat — later associations with allergic and autoimmune conditions are correlational and run in both directions.

  • Widely attributed to Bill Gates (apocryphal) attrib. Bill Gates 2000Accessed: 2026-08-09

    The line comparing lines-of-code to aircraft weight is universally attributed to Gates with no reliable source or date. Cited here as folklore, not gospel — which is rather the point of a post about not repeating things you haven''t checked.

Back to Blog

Related Posts

View All Posts »
You Think Your Legacy Is Bad? The Law Has Been in Production Since 1215

You Think Your Legacy Is Bad? The Law Has Been in Production Since 1215

Every anti-pattern you curse at 4am has a legal twin. A tour through carrot jam, immortal Japanese floppy disks, a British reform that broke a statute from 1881, the euro's continent-scale adapter pattern, a 'temporary' Polish tax still running fifteen years later — and three clauses of Magna Carta that have been live in production since 1215. Because law is just the oldest legacy codebase on Earth.

Conway's Law: The Mirror You Can't Outsmart

Conway's Law: The Mirror You Can't Outsmart

Conway's Law is not a rule you break — it is a mirror. Your architecture is a fossil of an org chart that no longer exists, and the real bill it hands you is not ugly code but the cost of coordination.

The World Rhymes: From Galaxies to Kubernetes

The World Rhymes: From Galaxies to Kubernetes

Whirlpools look like galaxies. Veins look like rivers. And crowd panic looks mathematically identical to boiling water. Why patterns repeat across systems and how noticing them makes you a better engineer.