Comment by jimnotgym
3 years ago
I had an interesting case of this recently.
A predecessor seemed to have a series of processes, each of which seemed to be dealing with the errors created by the previous process. However, their notes made it clear that they thought that the mistakes had an external cause, blaming 'the system'. I felt that I could remove all of the steps and replace them with a correct first step. As an advocate of Chesterton's fence, I found it hard to simply accept that my predecessor had built a fence around a phantom, but it seems to be the case. By not finding any reason for the fence I kept hunting for the same phantom. This is the limitation of the model, the erector of the fence may have been wrong.
Seems like you applied the principle correctly here. When you first saw the fence, you did your best to find a reason for its presence. You only concluded that the fence had no purpose after you ruled out sensible alternatives.
The principle is not that all fences necessarily have a purpose for their presence, it's that we should assume by default that any fence with an unknown purpose has or had a legitimate purpose at some point, until we are confident otherwise.
I also applied another mental model from my experience. There seemed to be a lot more steps in the process than were necessary. The solution seemed too complex for the problem.
It seems like this worked correctly: you found notes describing their reasoning, but did not find their argument conclusive or persuasive. Not every fence exists for good _reasons_; Chesterson's Fence simply recommends identifying what those original reasons were, so you can evaluate their legitimacy before proceeding.
Their predecessor also did a good job realising that it might be hard for GP to apply Chesterton's fence because there wasn't an obvious reason, and leaving notes documenting that (lack of good) reason.
Somewhat related-- I remember tracking a bug to a poorly documented commit in a codebase. The dev had changed the memory allocation routine to multiply the requested size by 8 in order to fix "a crasher."
Removing that "fix" immediately triggered a series of crashers that led like breadcrumbs to the part of the code which contained the actual bugs being papered over.
Instead of Chesterton's fence, this is something like "Chad's bandaid." If you immediately strip these away the real problems stick out like a sore thumb and you can properly fix them.
Or the situation may have changed, making it impossible to find the original reason.
It is a step at the end of a decade+ old system. My predecessor was only there for a year. I can't imagine how anything could have changed in this case. Upstream is a legacy product that runs without updates from the vendor. I have now from my predecessor when he left saying that he can't get anything changed at the vendor, because there is noone left there who knows how to change anything on this product.
But I agree, as a generalisation the situation could have changed.
I think this parable is simply about identifying the reason for something. It says nothing about if that thing is wrong. It's about simply getting to the point where you can begin to question the reason.