Even better: instrument the fence without removing it. You get the same knowledge without the chance of breaking stuff. If it's code, put it under a anti-feature flag.
I don't like that advice at all. So many fences have been installed for lousy reasons. And the results might be hard to predict so better to actually experience them. If you make a mistake, you can always re-install.
Chesterton’s fence is one I come across a lot. People see some confusing or not ideal code and immediately want to remove it, without understanding its purpose. I like stating it as “don’t assume the previous developers were idiots.”
We keep knocking down fences and it keeps being great, the most recent being the millenia-long prohibition on gay marriage.
People put up fences for all sorts of dumb reasons. If you see a fence that seems to cause more harm than good, knock it down. In the rare situation where this leads to surprising problems, put the fence back up.
In software, most WTFs are just bad engineering. You should figure out what the code does and how you can do it better, not take a step back and contemplate the mind of its author.
Always useful to keep in mind the concept of Chesterton's fence: https://fs.blog/chestertons-fence/ If something looks stupid or weird, you may not have all the relevant information to judge.
> The article makes the point that people do not build fences for no reason.
I think it’s more than sometimes reasons go away and sometimes people do unreasonable things. I don’t think anyone thinks that people literally build fences completely randomly.
reply