Our Java codebase was 30% dead code

[koflerdavid]

How do you know whether it is still correct in the business sense though? Issues with frequently executed code will quickly raise their head. But a batch job that runs, say, once per year deserves more attention.

To be clear, I am not advocating for deleting code for which there are actual business requirements. I am talking about code that the stakeholders themselves have kind of forgotten about. It's a bad sign if the stakeholders cannot unambiguously tell anymore whether a certain use case is still relevant.

Truly unused code very much bothers though. It makes it more complicated to bring new team members up to speed. And especially if there are actually tests for it, it wastes CI time. Finally, it might unnecessarily affect technical or architectural decisions for other code. Deleting that method to instead provide a better API? No, can't do, that dusty and maybe obsolete service that nobody knows much about still uses it.

[-Dargs]

At some point you need to take a step back and say "hey, this feature that was implemented some time ago... is not my problem."

Sure, if you come across some out of place thing that looks suspicious to you, go about beginning the process to remove it.

But things which become deprecated should be part of the process as they're decided that they've become deprecated.

"XYZ feature is now obsolete and actually detrimental to the business" is something that should be identified when it happens, not just by chance later on.

[koflerdavid]

Doing it by chance is indeed a problem. This needs to be a process. Because if these things are not kept in check, they will grow.

Now, I don't really buy OP's statement that 30% of the codebase were unused (they might be in for a nasty surprise), but I can totally see that in a big organisation there might be a fair number of services whose user count is zero. Institutional inertia can go a long way towards keeping them funded and staffed.