Comment by IshKebab
3 years ago
This feels like one more in a long list of well-intentioned advice that ends up being used to justify bad practices. In this case, never refactoring.
Others include:
"premature optimisation" (never worry about performance)
"Unix philosophy" (programs can't do more than one "thing"; where "thing" means whatever I want it to)
Very few pieces of advice apply 100% in all situations regardless of the context. That doesn't mean the advice should be rejected out of hand.
Asking people to take some time to investigate why something might be there before taking it out is justifying bad practices? How?
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.
Refactoring explicitly does not remove functionality, and is analogous to replacing the fence, not removing it.
Could even be the opposite ... "I have no idea why this fence is here but it's rusting away, so I'll replace with new wire."
The inverse of “premature optimization is the root of all evil” is “all bad performance is the result of sub-optimal implementation”.
“Elves seldom give unguarded advice, for advice is a dangerous gift, even from the wise to the wise, and all courses may run ill.”