Chesterton's Fence

You come across a rather ugly fence on a property you’re now responsible for. Your first instinct is probably to tear it down. Who thought this was a good idea?

Chesterton’s Fence

This increasingly frequently mentioned principle is known as “Chesterton’s Fence”. In short, it urges that you don’t tear down a fence until you know why it stands in the first place.

On its own, this is a useful principle. Engineers are especially keen to take bulldozers to the surprises they find in codebases.

Fences are everywhere in engineering

G.K. Chesterton was writing about fences back in 1929. At that time, he was thinking about public policy reform. But as many others have noticed, this concept is especially salient in software engineering as a professional. Every day you are confronted with decisions with justifications in varying levels of opacity.

I have observed three archetypes that capture how engineers relate to proverbial fences in software projects:

The misguided visionary

This is the archetype Chesterton referenced in his aphorism. The visionary sees a fence and instantly knows it is wrong and must be removed. The developer who on day one rebases the whole git history to one commit, tags it as “legacy code”, and force pushes is likely a “misguided visionary.”

The video game protagonist

The video game protagonist goes about their day contributing within the confines of fences that are invisible to them. This could be because they simply aren’t paying attention, but more often is caused by the environment. After enough time and complexity, some fences become indistinguishable from the natural environment. The video character can be at risk of burning out or stalling. Their work can feel like toil, but it’s not always clear why. It’s because the fences are hiding in plain sight making their work harder than they think it should be. Without any clear reasons as to why things are so hard, the video character blames his or her self and their own lack of ability. It’s not obvious that there’s alternative with smarter fences.

The freerunner

Unlike the video game character, the freerunner sees the fences. But instead of questioning them when they become inconvenient, the freerunner sees them as a challenge to circumvent. They don’t destroy the fences, but will go to great lengths to implement acrobatic workarounds on top of obstacles without a full understanding of why those obstacles exist.

This can lead to an interesting phenomenon of self-replicating fences, where the freerunner’s creations function as new fences that others must seek to understand, and perhaps build new fences on top of.

If each of these three characters asked about the origin of those fences, they’d push both themselves and their team to a better place. However, a team needs two things for this to work: trust, and space. Your team must consistently so that engineers feel safe to ask the questions in the first place, and give them the space to carry out these discussions and remove or rebuild fences when needed.

What Chesterton’s fence can teach us about our own decisions

Have you ever checked in some code that you only arrived at after multiple iterations of thoughtful programming, only to be met with some variation of “why would you do it this way?”

When this has happened to me, I noticed that it’s all too easy to start feeling defensive. The question is readily interpreted as “what the hell were you thinking you ape?” It’s natural to feel this, but you have to push past it - thinking this way is assuming the worst intentions.

But next time this happens, I encourage you to think of Chesterton’s Fence. In almost every case, that’s why you’re counterpart is asking. You erected a fence for some reason. Do your fellow contributor a favor and help them understand why you thought that fence was necessary. It’s not an insult on your engineering aptitude, but an attempt to better understand the reality of the problem you’re solving.

And if you’re the reviewer, keep in mind that most code exists for some reason. Think about what details you might be missing, and ask about those before deeming pieces wrong or unnecessary.

After this discussion, maybe you’ll find the fence wasn’t actually necessary. Or, maybe it was there for a valid reason, but there’s a better solution for it than a fence. In both cases, the whole team will leave with a better understanding of the problem, and just as importantly, you’ll have built trust along the way.