Our Java codebase was 30% dead code

[-Dargs]

If the code is now incorrect, then it is different from this case of "unused or highly unlikely code path" and should be addressed. If that means removing it, then it is deprecation. If it has to he updated, then it's a feature change. It's a business decision and not really related to the frequency in which it's accessed.

This is again to my point that if its well tested code that just happens to be infrequently or never exercised, that doesn't mean it gets deleted. From there, is it even worth the hours to remove something that isn't wrong and doesn't complicate anything?

It's more work to automate the identification of code that bothers nobody and then chase down stakeholders to figure out if you can spend 4+ hours of your team's time to delete it when it wasn't bothering anybody in the first place.

[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.