James Broad

27 May 2022

Chesterton’s Fence: A mental model for software engineering

In software engineering, a large component of the work involves the modification of existing code, often not your own. The act of refactoring can be trivialised and when code that appears at face value redundant or irrelevant is whimsically removed, often with celebration. Now consider this quote from Chesterton:

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 will do well to answer: “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.”
– Gilbert Keith Chesterton from The Thing (1929)

The salient reminder is when you don’t stop to consider that someone spent time and effort creating the code that you’re vying to eradicate, it was probably contributed for good reason.

This model of second-order questioning highlights the difference between a junior and senior engineer. The experienced engineer will be aware of treading with caution through changes, channelling the Chesterton’s Fence heuristic but the inexperienced will exhibit hubris with sweeping changes and little regard for the defects left in their wake.

It seems paradoxical that if you were to encourage a junior engineer to question every modification they made, they’d probably grind to a snail's pace and feel discouraged as they’re hungry to see and demonstrate progress. A senior will have cemented scar tissue from their mistakes when not following this advice so you could say it’s an inevitable gauntlet that has to be run to reach enlightenment.