Chesterton's Fence

Suppose that there is a fence spanning a road. Someone comes along and says “I don’t see why this fence is here, I say let’s tear it down”, to which their friend says, “if you don’t see why it is here, then I certainly won’t let you tear it down. Go and think about it, and when you can tell me why it is here and still think it is a good idea, I’ll go and get my work gloves and help you.”

This is a simplification of an original quote¹ from The Thing by G.K. Chesterton. It is commonly referenced as “Chesterton’s Fence”, and the concept is that we should engage in second-order thinking to examine the long-term effects of decisions and consider not just the consequences of our actions (the road is no longer blocked by the fence) but the consequences of those consequences (perhaps the fence protects against a sudden drop over the hill, or there are a herd of cattle that it keeps from wandering off).

As developers, we should heed Chesterton’s Fence and be careful to consider why our teammates or predecessors wrote the code that they did before we look at it and think “there is a better way”.

Before we make changes to something, we should first understand the reason why it was put there place in the first place. This is especially important when it comes to working with code, because making changes without understanding the reasons behind the existing code can lead to bugs and other problems.

Applying the concept of Chesterton’s Fence to our work can been incredibly useful as a way to frame how we think about changes. Before making code changes, we can take the time to understand why things are the way they are. How might the change have impacts to other parts of the codebase? Are there impacts that aren’t explicitly present in the code but would impact the user experience? This type of second-order thinking can help us to avoid making changes that break existing functionality or introduce new bugs. It can also help avoid over-engineering solutions to problems, which can lead to unnecessary complexity and reduced maintainability.

Chesterton’s Fence can be applied in a number of ways in our Ruby code. Here are a few examples of how we might use the concept in our own applications:

1. Before refactoring a method, try to understand why it was written the way it was in the first place. For example, let’s say you come across a method that uses an unusual pattern to iterate over a collection. Instead of immediately refactoring the method to use a more familiar pattern, take the time to understand why the original method was written that way. There may be intentional side-effects of the way that it’s currently done that aren’t possible with a different approach. It’s also possible that the original method was using the unusual pattern for performance reasons, or that it was using it to avoid a specific bug. By understanding the reasons behind the original code, we can make better decisions about how and whether to refactor it.
2. Before removing a piece of code, try to understand why it was included in the first place. For example, let’s say you come across a method that you don’t think is being used anywhere in your codebase. Ruby allows metaprogramming that might be making use of that method in ways that aren’t simple to find by searching the codebase, might not be tested, and might only show up in certain cases in production environments. By understanding the reasons behind the code, we can avoid inadvertently breaking our applications.
3. As a corollary to Chesterton’s Fence, we can consider how the frustration and confusion we experience in reading code later might be assuaged or avoided by others later. My favorite way to do this is by making the code very explicit with variable and method names, as well as by writing explicit commit messages that can be referenced later to understand why changes were made.

Chesterton’s Fence is a valuable principle for anyone working with code. By taking the time to understand the reasons behind the existing code, you can make better decisions about how to modify and improve it.