A cautionary tale:
Allow me to set the scene. Two software engineers are in a Slack huddle as they discuss a refactor to the codebase they have been working of weeks:
Me: "This code is completely useless. It must be outdated and left over from a previous iteration of the app. I'm going to delete it."
My smarter, better-looking coworker: "What did it do?"
Me: blank, empty stare recognizing I have no idea
And that is when my coworker introduced me to the concept of Chesterton's Fence.
The Analogy
From the man himself, G. K. 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.”
The principle can be summarized as something like this: If you come across a fence that seems to have no purpose, rather than rushing to tear it down, first seek to understand why it was built in the first place. It may be that there was a good reason for its existence that isn't immediately apparent.
The Application
As programmers, we often encounter "fences" in our codebase that seem outdated, unnecessary, or downright illogical. The eager, reformist, instinct is to refactor or eliminate them immediately. But applying Chesterton's wisdom, we should first take the time to understand why that piece of code exists.
Could it be solving a problem that is no longer present but may reappear? Could it be supporting functionality that seems irrelevant but is, in fact, vital in certain edge cases? Could it be a necessary 'ugliness' due to hardware constraints, business requirements, or tech debt that we should be aware of?
Just as Chesterton warned against tearing down fences without understanding their purpose, we should caution ourselves against altering code without fully grasping why it was written that way. An apparent 'messy' piece of code might be a brilliantly crafted solution to a problem you've yet to encounter.
The Take Away
So, the next time you encounter a piece of code that seems like an outdated 'fence', remember Chesterton's advice: understand it before you rush to dismantle it. Our job as software developers isn't just to write code - it's to read, understand, and respect the wisdom that often lies in the lines written by others before us.
Or perhaps it is simply just out of date code that should have been deleted months, or even years, ago. However, you would be smart to ensure that you have an understanding of its purpose, and any continued use, before removing said code.
Top comments (1)
Good reading