DEV Community

Saulo Dias
Saulo Dias

Posted on

You Can Probably Delete Half of Your Codebase

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 budy... )

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 and endpoint, which is not not the case when changing the location of that resource is actually your job.

In a nutshell, being conservative is not opposite with being 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.

Discussion (0)