Comment by IshKebab
3 years ago
Not at all what I was saying. I said it ends up being used to justify never refactoring.
You'll get a situation where there's some code and nobody knows why it's there even after investigation. Can we remove it? No of course not - do you not know about Chesterton's fence??!
There's actually a second reason why this advice is bad. It's basically victim blaming. The onus is on the person leaving a weird fence around to explain why it shouldn't be removed; not on the person finding a weird fence to have to guess a reason. You can say "well, bad people exist; you'd better assume there's a reason", but that's the same logic that leads to "bad people exist; don't wear attractive clothing".
It's actually good advice if the only thing you care about is not being raped. But people quite reasonably care about other things (like enjoying life).
Similarly Chesterton's fence is not bad advice if the only think you care about is not breaking your code. But people quite reasonably care about other things (like maintainability).
This all makes it the worst kind of advice - technically correct but unwise.
Hmm, I take the exact opposite conclusion from what you've said. Don't take it out until you can demonstrate with high confidence that it won't break things in production. Lower maintainability is probably going to be less harmful than breakage (not to mention choosing the hills you're willing to die on).
But then again it depends on the kind of company. Small and scrappy? Move fast and break things. Big and established? Be cautious.