How many times have you replaced a piece of code by something else and just left the old code there because "it might be useful?"
Spoiler alert, it probably won't!
If you're not re-adding things back 10% of the time, you're not deleting enough.
— Elon Musk
If you use git or other software versioning system, please don't leave dead code behind. This is not only out of self-respect as a software engineer, but mainly out of respect for your colleagues and, most of all, the future you. If you do need that piece of code again, you can easily go through the file history and recover it.
Deprecation
If you don't have a deprecation cronogram, definitely just delete unused methods. Deprecation is serious and saying "This is obsolete and will be removed" is just adding more characters to something that shouldn't exist. And guess what? Once you leave the company or gets too busy developing new features, no one will remove it.
Just get rid of it
Believe me, if something is important, it'll will break something. In my experience, when something breaks, your (QA) team (hopefully) is the first to let you know, if you have a QA team.
Better safe than sorry?
People might get slightly inconvenienced that you broke something for removing too much, but if they know something about software development, they should congratulated you for breaking stuff, unsarcastically. (Maybe even sarcastically, if they are your buddy... )
Breaking things for removing stuff, as long as you fix it, is something to be praised by fellow developers, even though the QA team might hate you for that. By removing obsolete code, you are making your codebase easier to read and consequently easier to maintain.
Ideally, every piece of code should have a purpose. If that code is not being used by any feature, then that is just like weed on a wall, that slowly erodes the plastering until it's impossible to maintain it. At some point you just have to demolish everything and rebuild it from the ground up.
The migration hell
When it comes to APIs, if you have fully replaced an endpoint, and you are sure the old one is not being used anymore, just remove it along with all of its exclusive dependencies. If you're not sure, talk to the architecture team and make sure. If you just leave it there, you might make it harder for other developers when they need to debug something, and they will not remove it because they have no way, or no need to know if the endpoint is still being used.
Believe me when I say you don't want to work the whole afternoon just to find out you have been refactoring dead code, (so don't leave code you know to be dead for other devs to remove, because they won't!)
Be bold, be productive
Dead code not only ruins your productivity, but it also corrodes your whole team's productivity in the long run. And the reason I have put special emphasis on API endpoints is because, unless you have a very well documented API, or up to date endpoint tests running regularly, it can get really difficult to know if you can safely remove an endpoint.
In a nutshell, being conservative is not opposite with being a little bold. When it comes to software development, being conservative means to do things in a safer way, but when "safety" becomes the enemy of maintainability, that's not being conservative. That's setting oneself up for a big headache.
Top comments (0)