You have a room full of books and you don’t even have time to read them. Every week you clean the room and have to spend a lot of time organizing and cleaning up the clutter

Wouldn’t it be reasonable to throw away things you don’t use so you don’t waste time on weekly cleaning? I think the answer is obvious.

The same is true with code in IT projects. The project is evolving, requirements, the architecture, assumptions are constantly changing. All changes/evolution cause that some code becomes unused. Some examples:

• not used API – to achieve a smooth customer/application migration we keep the old API for a while, but one day no one uses it anymore

• not needed migration scripts – we can have 200 migration scripts and a huge amount of related logic that are not used because we have the latest version on production!

• not used events/endpoints – in complex distributed systems, events/contracts change frequently, especially in distributed monolith. In that systems it is easier and less error-prone to create new logic coresponding to a new event than to change the existing logic because we are not sure who/when/how to use it. Many events and endpoints become unused.

Why should we remove unused code? Because it causes problems, such as bigger source code, longer compilation time, longer test execution, etc. but the real problems are listed below.

What problems does unused/dead code cause?

• maintenance cost

It doesn’t matter if your code is used or not, you have to maintain it. Maintenance costs a lot – reading/understanding, bug fixing, testing, updating due to new requirements, language versions, libraries, framework updates and so on. I think it costs even more to maintain unused code, because very often this code refers to an outdated solution, requires special tests, or old libraries that cause eg. security scanning problems.

• makes refactoring more difficult

Sometimes refactoring is very difficult because of dependencies to/from unused code! Sometimes you can spend hours or days refactoring code that is not being used! This is frustrating. You also have to remember that there are tests associated with the refactored code, which of course you have to change.

• misleading

You have spent a lot of time analyzing code because you are new to the project. After many days, you feel that you understand how the ‘a’ functionality works. The tech lead appreciates your efforts and praises you, but makes you aware that unfortunately, this code is unused. How do you feel?

Examples from real projects

In one project, I was learning how the application works by analyzing all the endpoints, but then I was made aware that these endpoints are not used at all, because all communication goes through one synchronization endpoint.

In another project, a large distributed system, I repeatedly analyzed the code of a complex flow. It turned out that some events were no longer used in the process. The events were not removed because everyone was afraid they would break something.

Many times in various projects I come across unused code, logic, configuration, documentation, etc.

What benefits do we achieve by removing unused code?

In a nutshell: saving time on not maintaining unused code, easier refactoring and transparency.

But one day we will need this code

I guarantee that this day will never come. Even if it does, the code will not fit the current requirements, so I’m sure you will remove it anyway 🙂

How to identifiy the unused code?

This is the hardest part. In small applications, you more or less know what’s going on. In bigger applications you can manually analyze code usage by tracking, for example, functions called on the front end. In large systems, you can use a library that analyzes code usage on production over a longer period. Removing that code will be risky due to some conditions that are very rarely used or the setting of future flags, but you get clues about what should be analyzed manually.

Summary

In every project, there is unused code that periodically needs to be removed, as it causes many real problems.

–add something about documentation, and other stuff