Programming principles (also called coding principles or conventions) are guidelines that help us prevent making “unfavorable” design decisions during coding. That is why every developer should know about them and make it a habit to revisit these concepts from time to time. Chesterton’s Fence is a very old principle that is not limited to coding, but helps you in your everyday life. In essence it tells us to first attempt to understand the current state of something before we go ahead and change it.
What is Chesterton’s Fence?
"There exists ... 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.'"
Certain choices might have more complex reasons than you see at first sight, i.e. if a “fence” exists then there usually is a reason for it. We coders are lazy at heart, we would never build something that has no use at all. So before going ahead and changing the current state, we should always take a step back and try to figure out why the system is currently built as is. It is best to always assume the original author knew things we are not aware of, or had experience we can not grasp yet.
Options to figure out what the current state are the usual suspects: the documentation, (automated) tests or the issue tracker. If we are not lucky enough that those exist, maybe some code archaeology, i.e. looking through the commit history, can give us a hint. And of course - finally - there are code artifacts that are indeed illogical or do no longer make sense and, therefore, should be removed. But, taking that assumption should never be our first guess.
Wondering what is the meaning of Chesterton’s Fence in practical terms? Let’s see an example.
Tearing down Chesterton’s Fence: “That sleep makes no sense”
I did not know about Chesterton’s Fence when I started out as a programmer. As I was implementing a feature request, I stumbled over a Sleep-call in a really odd place. It was in the middle of a library for authenticating file accesses, which ensured files could only be accessed with the permissions to do so. Clearly, it made no sense to Sleep every time the CanRead method was invoked.
So I went ahead and deleted that mysterious line of code. The project had some automated tests, which all passed. Also there were no dedicated code reviews, so my tiny change made it into production.
Turns out that the Sleep was necessary for a completely unrelated component to start up correctly. That other module had very poor performance on certain operating systems so someone must’ve added a temporary buffer for that particular case. It took quite some time to figure out that my hasty removal of that weird Sleep-call prevented the product from starting correctly for a certain portion of users. A mistake with side effects like these makes you definitely more careful when changing legacy code.
Have you ever ignored Chesterton’s Fence? Let us know about any experiences you had because you hastly ignored this coding guideline. We would love to discuss them together, as each of those errors is a lesson learnt that helps others make Chesterton’s Fence stick.
Don’t forget to subscribe to our newsletter and follow us on Twitter, LinkedIn, and Facebook for getting notified on new articles about software development and software infrastructure, or if you are simply into memes.