Chesterton's Fence

Chesterton’s Fence is a principle that gets invoked every so often when talking about software. At a high level I’ve generally understood it to mean “don’t remove something or change its behaviour unless you know why it was put there in the first place” and I think for software that’s probably “good enough” as a summary.

If you read Chesterton’s 1929 essay where he proposes not clearing away a fence on a whim, it becomes clear that he wasn’t talking about exception handling in your god object. Sure, it’s weird that in 1929 he wasn’t writing about software development, but here we are.

"Bolivar Heights Battlefield, fence on Bakerton Road" by Beyond My Ken is licensed under CC BY-SA 4.0.

#The Fence

From “The Drift from Domesticity”, in G.K. Chesterton’s The Thing (1929):

In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. 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.”

This paradox rests on the most elementary common sense. The gate or fence did not grow there. It was not set up by somnambulists who built it in their sleep. It is highly improbable that it was put there by escaped lunatics who were for some reason loose in the street. Some person had some reason for thinking it would be a good thing for somebody. And until we know what the reason was, we really cannot judge whether the reason was reasonable. It is extremely probable that we have overlooked some whole aspect of the question, if something set up by human beings like ourselves seems to be entirely meaningless and mysterious. There are reformers who get over this difficulty by assuming that all their fathers were fools; but if that be so, we can only say that folly appears to be a hereditary disease. But the truth is that nobody has any business to destroy a social institution until he has really seen it as an historical institution. If he knows how it arose, and what purposes it was supposed to serve, he may really be able to say that they were bad purposes, or that they have since become bad purposes, or that they are purposes which are no longer served. But if he simply stares at the thing as a senseless monstrosity that has somehow sprung up in his path, it is he and not the traditionalist who is suffering from an illusion. We might even say that he is seeing things in a nightmare.

"Gilbert Chesterton" by Ernest Herbert Mills (1909) is in the public domain.

It turns out that Chesterton’s concerns as laid out in the rest of this essay are around what he saw as a breakdown of the family unit, shifting societal norms and the idea that the state could step in to take on some of the roles which had traditionally been left to the family. And you know what? He really didn’t want to take down that fence [the family]. If you have a good think about why the fence is there and then are able to explain it to him, he may allow you to destroy it. No guarantees. The main point of the exercise seems to be forcing the reader to consider why things are the way they are rather than giving them a pathway to removing obstacles they deem to be superfluous.

So yeah, Chesterton wouldn’t be a great code reviewer on your refactoring branch, but broadly, the principle is helpful. Just keep in mind that the assumption that there must be a good reason for this can be pretty dangerous in software. Stuff gets added without a lot of thought, weird stuff keeps hanging around after a botched merge conflict has been “resolved” and some people have no idea what they’re doing. Add to this the number of lines that are cranked out by LLMs and in a lot of cases, making a best effort to understand wacky code is all you can do.

I will say that legacy code that has done what it needs to do for decades requires some extra care. This code was written well before 90% of LinkedIn became a collection of thought leaders who are here to tell you that all code is disposable. Some code is just really old and really good at what it does. Respect your elders.

Which brings me to the point of all of this. Sometimes when I give an LLM an instruction, I really do want it to dig deep into why something is the way it is. I find I have more success with bug fixing when I allow it the freedom to assess whether the bug really is a bug rather than something I don’t understand. Saying “do X” will get you a diff that does X, but saying “Chesterton’s Fence” to your agent gives it the freedom to find reasons not to slash and burn a function that has pretty much done the right thing since 1998. (I’m guessing this also works with a human.)

TL;DR: When fixing a bug whose provenance you don’t fully grasp, invoke Chesterton’s Fence to get a more robust response from your LLM.

I get that the point of the TL;DR is to be at the top, but who am I to encourage people not to read the entire post?

P.S. If you think you’re generally unfamiliar with Chesterton’s work, that may not actually be the case. The Father Brown TV series is very loosely based on stories by Chesterton. I also suspect that Frasier’s restaurant critic “Gil Chesterton” is a nod to this same author, but I cannot prove it.