Alternative title: Tell me you don’t work on life crititcal software without telling me you don’t work on life critical software.

Chesterton’s Fence is an allegory, attributed to Gilbert Chesterton1, about coming across a fence for which you do not know the purpose, rather than removing it, you should figure out what the purpose is, then decide whether or not you should remove it. It is commonly extended to legacy code: you shouldn’t change or remove code unless you know why it is there in the first place. This leads to software that is difficult to maintain because it perpetuates superstition throughout the codebase.

Changing things is scary

Whilst people may not invoke it in name, I see the Chesterton’s Fence argument whenever someone argues that we shouldn’t change something because we don’t know why it is there. Maybe the person who wrote it has left the company and didn’t document it well, maybe they’re still there but it was years ago. Another one I’ve seen is that it is documented but the documentation references constraints or reasons that no longer apply — this, in particular, is a strong signal to remove it.

If you’re unable to track down how or why something is used, and can’t figure it out, then we need to relearn the lesson. The best way to do that is to remove it, forcing whatever problem was being solved to reoccur if the code is still needed. That way, at a minimum, we can properly document why the thing is needed and include more modern context. I also often find I’m much more motivated to deeply document the problem if it’s because we had a fix that was non-obvious and had to relearn it. These are the places where I find myself leaving a multi-paragraph commit message and detailed comments in the code. Often, the first time the problem is encountered it is as part of solving a larger problem so extracting the context to document it can be challenging.

But, we’ll make the same mistake

Another scenario I’ve encountered is that people vaguely remember the problem and that this was a way of solving it. There isn’t enough memory to know the exact causal link, it’s just a feeling. I know I’ve personally been guilty of this. The problem I see here is that it often introduces superstition that can spread throughout the codebase. Due to the memory only being vague it’s difficult to evaluate whether the fix is still necessary. Sure, it might be frustrating that it turns out the fix was still necessary but at least a group of people have now learnt that lesson. Some lessons have to be re-learnt, and mistakes re-made by each generation of the company. Sure, there are some that can be passed down by discussion of the history of a fix but many, in particular subtle ones, just can’t be and people have to learn through experience. People are more likely to remember the reason behind a particular fix if they’ve been surprised by it.

Dismantle it

Engaging in a Chesterton’s Fence argument leads to:

  • Superstition proliferating through the team and the code base.
  • Difficult to maintain code as it is trying to fulfill requirements that people no longer know or understand.

Sure, removing stuff you don’t understand may lead to outages but in my experience this has been the case less than you’d think. I also think that on balance, the maintainability you gain is worth it.

This is not a license to go and remove things from your codebase without attempting to understand them! You should dig into them first but if you can’t get to the bottom of them after a reasonable attempt at debugging then it is a reasonable candidate for removal.