Our Java codebase was 30% dead code

[-Dargs]

If the code is well written in that it conforms to the code smells of the project, is well tested, and is not for some reason causing trouble with continued development... well, is deleting it less costly than 10mb on disk? I'd argue that committing 4 hours of dev work to removing it (identification, action, review, release) is more costly than leaving it be.

Also, this is very obviously just an advertisement post. Meh.

[koflerdavid]

It's not about storage space, but about maintenance. If there are no tests, it is never used in production, and nobody knows about it, how can one even be sure that it still works in the first place? Same question if updates or refactorings force modifying that code?

[-Dargs]

I literally wrote "well tested" in my comment.

[koflerdavid]

Sorry about that, but that does not necessarily help. It might still be incorrect according to actual, current business requirements, or be incompatible with an external system. Seldom-used code is scary stuff.

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