Oh no, I always get rid of stuff I don't know why it's there.
Because if it does not break when I run "make check", it's not covered by the testing and it shouldn't have been there in the first place anyway.
And if it had a use for someone, but nobody knows, removing it is also a very efficient way to figure out :)
This all depends on the nature of the business, the app, codebase, customers, processes of dev/QA/ops, etc. For example, this cavalier attitude might work at a social media startup but not at a bank.
Re:A Field Study on Technical Debt
by nothrabannosir on Tuesday July 28, 2015 @06:09PM
(#9964882)
> You should resist someone who says, "I don't know why this is here, let's get rid of it!" Only get rid of something if you do know why it's there!
I know this is orthogonal, but please try to avoid these situations by commenting code which people might wonder exactly that of, in the future. :(
Even better, write a test with a name that describes its functionality.
Thanks for posting - I hadn't really considered Chesterton's Fence as a technical metaphor but as soon as you posted I immediately thought of a person who has a habit of this very act. I'm adding this term to my lexicon.
https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
You should resist someone who says, "I don't know why this is here, let's get rid of it!" Only get rid of something if you do know why it's there!