And, fortunately, I think you're the only one I've heard of who has interpret it in this other, interesting way.
It reminds me of people I’ve worked with who will always bring up edge cases in any discussion. They use their “ability” to identify edge cases to shut down conversation and present themselves as the smartest in the room. If they can think of ways this design might fail of course they must be the most qualified to do the design right? It really has a chilling effect on teams and has, in my experience, lead to really bad technical decisions.
But regarding edge cases, I’ve come to see that type of person in a different light. The way I see it, edge cases pressure test the design. Some edge cases we just don’t care about, and when someone raises them, we put them on a published list of non-goals. This acknowledges that they exist and shuts down future naysayers. But sometimes an edge case ends up mattering a lot; enough to change the direction of the design. And for that reason, I welcome the edge case hunters. If managed, it becomes a valuable source of feedback and strengthens the overall design.
But to your point, this type of individual can sidetrack the team if not managed. Having processes in place and tactics to incorporate the concern without getting stuck on it is critical, and not always easy.
In this regard, I think it’s a bit different than the fence. The fence is a barrier that already exists, while the pessimistic edge case finder is trying to build fences that don’t yet exist.
That led to a few interesting developments. 1) participants say their edge case and immediatly shelf it themselves. 2) Or, they come prepared with good reasoning why case X is important and must be treated now. Discussion itself became more constructive, too. In any case a win!
And as funny as it may seem
Some people get their kicks
Stomping on a dream
But I don't let it, let it get me down
Cause this fine old world, it keeps spinnin' around
I think Chesterton's fence is awful. It's cited as a nugget of infinite wisdom, and it's the opposite.
Anyone who's ever worked in a corporate knows how strong inertia is. Chesterton's way of thinking is the default. Cruft accrues because people are so averse to remove things from the code base. What if anyone needs this fence? Just to be on the safe side, I'll just leave it here. Little upside to remove it, lots of possible downsides. That's how people think.
And this essayist comes and writes it down as some great insight, and people can point to it and get legitimacy.
Everyone, have guts. Be brave and call a spade a spade: Chesterton's fence is the lazy guy's rationalization to leave things as they are. And to look wise doing that.
You’re imagining a danger, which you by definition cannot explain to anyone why the danger is real, and then you’re arguing that some very specific action should not be taken because it might trigger the imaginary danger.
It’s easy to look at the end result of that process and assume that one can easily move things around. But that’s not how the system came to be in the first place.
Maybe the new changes would be inconsequential. Maybe they would even make things run better. Or maybe they would be just an evolutionary dead end, eventually discarded by natural selection.
The point is that one needs to be humble and understand not just the current state of the system but also how it gradually came to be formed over time. Only then should one start proposing changes, carefully.
Once upon a time it was thought that some organs are useless (thymus in older age, appendix pretty much always). This has been revised. Nature often introduced hard-to-understand systems in order to cope with something we don't even realize is a problem.
If it's possible in the extreme, it's possible in a fine grained gradient between the two extremes. The danger isn't the infinite barrier, which I believe you posed as a thought experiment. The danger is death by a thousand cuts of new ideas that are so important that they could make the relevant concerns irrelevant.
> and by the time you have investigated it, they are building walls around your original position
Who are "they"? It seems that you are trying to blame a general principle on some kind of fight you personally are having and not winning. But that's not the point of the principle.
it wasn't supposed to be used for some 2 year old startup's SOPs, software architecture, or business decisions. The argument assumes you already have a system that has been working for a long time and was well thought out
If you must understand something to remove it you do end up with a lot of things that can never be removed. It’s a big reason that laws and regulations build forever.
It's really not any different from any other decision making process. The principle exists to encourage critical thinking, not to obstruct progress.
Congratulations, you can now opt to remove the fence. This is also discussed in the article.
Chesterton's fence is philosophical, and as always, there will be a value proposition to consider. E.g. building a new beltway that would connect two previously unconnected cities or developing trade routes completely overrides the value that a fence being used to keep wildlife 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 HARDER and investigate better. ""
Then you look at implementing process changes in the company at a higher level, there is 100% something absolutely wrong, but it may not be a problem with a physical system, but a human interaction one.
It is impossible to meet because the reason why the proverbial fence was put up is, more often than not, a mixture of misunderstandings, logical fallacies and political motives from both the one who put it up, as well as other stakeholders involved, and most importantly, none of those aspects are documented and none of the people are around anymore. You'd need nothing less than a time machine to understand why the fence was put up.
The difficulty lies in agreeing on what that point should be, and on the magnitude of any particular piece of information as evidence for or against any particular hypothesis.
"The fence was a mistake" is a completely legitimate conclusion here. The principle exists to prevent us from jumping immediately to that conclusion out of convenience, arrogance, or ignorance. It should not be interpreted as preventing us from ever reaching that conclusion after some careful consideration.
In other words, if the potential impact of an unforeseen breakage is high enough (costs us or the customer $$$), it’s not worth risking the change even if we can find absolutely no good reason for the current behavior to exist.
Example: complex spaghetti that touches billing calculations. These things are better addressed by a full rewrite/redesign followed by a long period of running both things in parallel until we’re confident that we didn’t miss anything. Maybe this is just a more complex way of removing the fence, but I think it’s more like moving away from the ground the fence is built on.
What would have been the advantage, in this situation, to ignoring the rule? What problem here is the Chestertons Fence rule causing?
EDIT: (responding to below, your issue has nothing whatsoever to do with Chestertons Fence. Making careful code changes to test then effect of removal is a great way to apply the rule. Building a separate system and testing in parallel would be an even cooler way to apply the rule)
The reality is that we don’t know if it worked. It’s possible that our conclusion that this had no reason to exist as written was accurate, and that doing nothing didn’t actually prevent anything bad from happening. It’s also possible that we saved ourselves from something we didn’t understand.
I’m not disagreeing with the premise of the fence, just pointing out that at times, even doing all of the due diligence to understand the fence isn’t enough to remove it.
Edit: I can't really respond to your response in its current form without these comments getting really difficult to understand. I disagree that this has nothing to do with Chesterson's fence. It's essentially a failure mode that can occur when applying the ideas behind the principle, i.e. there are times when learning everything we can about a barrier and believing with a high degree of confidence that the barrier isn't needed still isn't enough to remove it due to other factors. This points to the fact that this is a guideline, not a law.
I don't understand this. Implementing billing from scratch and running it in parallel to the old code is a form of doing due diligence. I.e. it is an application of Chesterton's fence. It might be an expensive application but it is one.
To me, this anecdote shows the value of documenting the why of software. I've read some time ago, to add code to systems such that, it is simple to remove it again. This discussion deepened that insight for me. This is preparing for Chesterton's fence.
That's why I closed with:
> Maybe this is just a more complex way of removing the fence, but I think it’s more like moving away from the ground the fence is built on.
In other words, it's still learning from the cautionary tale of the fence, but the end result isn't a classic removal or non-removal of the fence itself. And it's not as if the idea has hard and fast rules :)
I agree regarding the value of documentation. None of us involved in the project were at the company when the code was written, and so we were left with a dangerous task.
These arguments are exhausting, especially when we are talking about political issues.
Do you really believe that it is literally impossible to figure out that some legislative "fence" is really a moat protecting entrenched interests of the lobbyists who helped write the legislation?
This is a straw man. The fence is simply an excuse to think a bit more deeply.
But many people who invoke Chesterson’s fence do so with the intent to lobby against changing something. It’s raised not as a caution, but as a barrier. The concept gets the most airtime in political circles, and I think this has led many people to misunderstand the original point.
This is not a straw man as far as I’m concerned, and while I agree that the original intent was about careful reflection, this is often not how people engage with it.