For me, one of the most appealing quality improvement actions still is the deletion of code. That means, not just any code, but the code that is of no more use. Obviously, this refers to dead code—code that is not reachable at all and will therefore never be executed. This includes unused variables and fields as well as methods that are never called and commented-out code (Teamscale can tell you where these are). However, this is only part of the truth. More importantly, it refers to all the experimental code, the one-time migration code, the code of the previous version, the code of the supplementary tool that no-one used anymore and so on. In most systems we see, this accounts for a notable part of the total code volume. Beyond that, it might be worth looking at all the tiny features you thought were cool, took you a long time to implement, but no-one really uses in practice. Maybe it’s time to let go and remove them (I know this sounds awkward since common sense is that you can only add features). Andreas’ post might help you to get started.

The beauty of code deletion is that it is so easy to perform and you get rid of many quality issues instantly. In other words, the cost of deleting code is only marginal compared to the benefits you gain. The most obvious benefit is that your code base gets smaller. While we can probably neglect the reduced storage space, this means you take less time to compile and less time to test your code. If you have a solid integration setup where you compile and run your tests often, this can add up to a notable amount of time that you can save.

From the maintenance perspective, the benefit is that less code makes comprehension easier. And even though the code that qualifies for deletion is code you probably rarely look at, it is there—it appears in your file system, in your package browser, in your search results, and so on. Each time it makes navigating and searching in your code base a little more complicated.

Another benefit of code deletion is that it might allow you to simplify your architecture. Maybe the one feature once forced you to make a sub-optimal architecture decision which nowadays causes a lot of pain during maintenance of you whole system. This could, for example, be unwanted dependencies between components, code duplication causing a lot of problems, declaring entities as public which could otherwise be private, etc. When you delete the offending code, you might be able to simplify your architecture and reduce the maintenance overhead in other parts of your system.

Finally, you will significantly benefit when it comes to adaptive maintenance where you have to change you code due to a changing environment—for example when you have to migrate from one library to another. I know you thought you would never change that code :-). Suddenly you will need to adapt or even migrate tons of code that you actually don’t need, just to make your whole system work. Please note that these adaptive changes usually don’t allow you to take the time and remove this code beforehand.

In summary, code deletion is in almost all cases worth it. That means during your daily development, you should always look for code that is no longer needed and can be deleted. With today’s version control systems, it is also no problem to revert the deletion and restore the code if you made a wrong assumption and the code was in fact still needed—yes, this also happens :-).