Chesterton's Fence

There’s a fence across a road. A reformer comes along and says, “I don’t see the use of this. Let’s clear it away.”

Chesterton’s point: if you don’t see the use, that’s exactly why you shouldn’t clear it away. The fence didn’t grow there. Someone built it for a reason. Maybe to keep cattle in, maybe to mark a disputed boundary, maybe to stop carts from falling into a ditch that’s since been filled.

Not knowing the reason doesn’t mean there isn’t one. It means you haven’t found it yet.

This comes up constantly in software.

There’s a function that looks pointless. Someone deletes it. Production goes down because it handled an edge case from 2017 that nobody remembers. There’s a process everyone hates. Someone removes it. Three months later, the problem it solved comes back.

I’ve done this. I’ve been the person who said “this is stupid” and removed the fence. The cattle got out.

Chesterton doesn’t say you can’t remove the fence. He says you can’t remove it until you understand why it’s there. Once you know what problem it solved, you can evaluate whether that problem still exists.

The sequence matters. Understand, then act. Reversing the order means discovering the fence’s purpose through the consequences of its absence. Which tends to be expensive.

The tricky part is that the people who built the fence often aren’t around to ask. The documentation doesn’t exist. The context is lost. So you have to infer the reason from the fence itself, or from traces of the problems it solved.

Sometimes the reason is genuinely obsolete. Sometimes the fence protects against something that no longer threatens. You can remove those fences. But you have to do the work of understanding first.

The reformer’s confidence that “this is useless” is usually just their ignorance talking.

Go Deeper

Books

The Thing by G.K. Chesterton — The 1929 original. Chapter 4 contains the fence passage.
Seeing Like a State by James C. Scott — What happens when reformers don’t understand systems.