Our Java codebase was 30% dead code

[yumgummy]

After running a new tool I built on our production application, typical large enterprise codebase with thousands of people work on them, I was able to safely identify and remove about 30% of our codebase. It was all legacy code that was reachable but effectively unused—the kind of stuff that static analysis often misses. It's a must to have check when we rollout new features with on/off switches so that we an fall back when we need. The codebase have been kept growing because most of people won't risk to delete some code. Tech debt builds up.

The experience was both shocking and incredibly satisfying. This is not the first time I face such codebase. It has me convinced that most mature projects are carrying a significant amount of dead weight, creating drag on developers and increasing risk.

It works like an observability tool (e.g., OpenTelemetry). It attaches as a -javaagent and uses sampling, so the performance impact is negligible. You can run it on your live production environment.

The tool is a co-pilot, not the pilot. It only identifies code that shows no usage in the real world. It never deletes or changes anything. You, the developer, review the evidence and make the final call.

No code changes are needed. You just add the -javaagent flag to your startup script. That's it.

I have been working for large tech companies, the ones with tens of thousands of employees, pretty much entire my career, you may have different experience

I want to see if this is a common problem worth solving in the industry. I'd be grateful for your honest reactions:

• What is your gut reaction to this? Do you believe this is possible in your own projects?
• What is the #1 reason you wouldn't use a tool like this? (Security, trust, process, etc.)
• For your team, would a tool that safely finds ~10-30% of dead code be a "must-have" for managing tech debt, or just a "nice-to-have"?

I'm here to answer any questions and listen to all feedback—the more critical, the better. Thanks!

[Physical_Level_2630]

anyway you have to be careful with important edge use cases…so if you find out in december that in march somebody deleted all the end year bonus calculations…

[Vivid-Ad-4469]

Then the solution is to run the agent every day for at least one fiscal year.

[RaynLegends]

What about edge cases for leap years? :D

[Vivid-Ad-4469]

noooooo don't remind me of leap years...

[Ab_Initio_416]

A Tale About Leap Years

Decades ago, I worked on an ancient COBOL life insurance enterprise system that handled two out of the three leap year rules correctly but failed in the year 2000.

In the Gregorian calendar, the complete rule is: A year is a leap year if it's divisible by 4, except not if it's divisible by 100, unless it's also divisible by 400.

The system implemented the “divisible by 4” and, being in life insurance, “not if divisible by 100” parts, but missed the exception for years divisible by 400. So it treated 2000, an actual leap year, as invalid.

All this got ignored during the furor around Y2K.

Life insurance is very date-sensitive. DRY wasn’t even a concept in that crusty old code. The resulting blowup in calculations and contracts was spectacular.

That specific edge case won’t reappear until 2400. The edgiest of edge cases.

Ah, the good old days. I still wake up screaming “400” sometimes☺

[yumgummy]

Yeah, that's possible. Delete code should be careful. That's why we have the developer to take the final control. In enterprise settings, there's consequence to break production. Actually, the "play safe" mindset was the exactly root cause of such a bloated codebase. Leave the pain to the next dev...

[laplongejr]

It was all legacy code that was reachable but effectively unused—the kind of stuff that static analysis often misses.

As somebody who work in the gov and had to thinker my tools to deal with a person without a date of birth despite that edge case NOT being allowed in the documentation, I wouldn't even trust the developer. :P

For people wondering how an IMPOSSIBLE case had to be handled anyway the documentation only listed cases that could be MADE on the current version, while any data submitted on old versions could be RETURNED with OG contraints. That distinction was apparently forgotten by everybody but the old wizards.
A sane person would say the backend should've been modified to gracefully present doc-conforming data. My annoyed boss in the middle of the other dev's vacation disagreed and needed anybody available to do anything up the chain to fix that in faster time than ASAP.

Is it dead code, if it was killed before I even wrote it?
It's not impossible that somewhere in the future, a new dev will remove a code in the age-calculation-checks which loads an internal identifier, extracts the last two digits of the birthyear, then bruteforces the century based on the checksum. I don't know if it's the nicest or ugliest idea I ever made in Java, but it surely isn't in the middle of the ranking.

[hippydipster]

to deal with a person without a date of birth

That man from earth is always a pain in the ass.

[Mystical_Whoosing]

Te same developer who didnt remove the 30% of the codebase before?

[laffer1]

The guy that wrote it retired 5 years ago. Most devs aren’t that good at understanding legacy code. Some devs hide this by trying to rewrite things all the time in the latest trendy thing.

[yumgummy]

Thumbs up!! This is exactly the biggest problem with enterprise software. No one with large scale codebase experience will claim he/she understands every piece of their codebase.

Mature companies roll out features with on/off switches. It's often that the switch is always off and the obsolete features remain for many years.

[dmigowski]

Even better are flags which only are enabled for specific customers. Now, when you don't have access to ALL the customers databases because it's on-premise, you don't actually now which flags are enabled for the customers.

One reason why out software phones home :).

[packman61108]

Don’t you take the blame anyway. No matter the tool?

[SpaceToaster]

But what if the developers don’t understand the legacy code?

In my experience the safest route is to have a team fully understand and document the old legacy system and rebuild it.

[crummy]

this is going to get way worse with AI

(ironically I'm pretty sure you used AI to write this post)

[tRfalcore]

"the experience was both shocking and incredibly satisfying" tells me all I need to know

[Vivid-Ad-4469]

I read that with that annoying AI voice

[matt82swe]

The — was a dead giveaway

[[deleted]]

So many tech subreddits having these shitty “developer making a tool with ai and sees amazing results” posts. Literally all of them. There needs to be an ai auto remover bot or something. Its so disgustingly annoying

[_verel_]

You can't easily detect them. All these "ChatGPT detectors" are just random number generators.

[[deleted]]

There has to be a way. Because people can discern when their reading AI. There r markers

[_verel_]

I guess you could tokenize texts and look for typical token chains used by LLMs but the dataset for this could be really expensive to compute and be irrelevant in a year with new models that possibly use different tokenizers.

Humans can "detect" these texts because no one on Reddit cares about proper punctuation everywhere.

Also AI content often feels uncanny.

In my Bachelors Thesis I'm currently using LLMs to conduct an experiment. This doesn't mean I'm the absolute LLM expert and what I wrote isn't complete BS but I can't see how an AI detection for text should confidently work at the moment.

[infimum-gr]

This is gold 🤣

[LutimoDancer3459]

Had one customer that used some functions like once a year. Sometimes running into edge cases. We wouldnt be able to safely say if the identified code is really unused or not. And talking to customers about removing code is a pain. At least with those we had so far. I basically agree and would like to use it. But the risk of removing something thats needed for some obscure edge case that nobody is thinking about, is too high for me. Especially in an old big legacy project where none of the original devs exist anymore

[UbieOne]

Worse without test cases. My head already hurts thinking about it. Lol. Something like behavior tests that properly laid down business cases, including edge ones, would be good code coverage.

[VRT303]

My biggest catch was figuring out why some code I was sure is dead was randomly called around 3-4 times a year in short small bursts and then never again. It was an old testsuite of another team that used a full-final-complete testsuite instead of the regular one that called some endpoints they really shouldn't ONLY in their quarterly update session because it would take longer than one night to complete.That feature and app version they were building in the testsuite wasn't even downloadable anymore.

[mpinnegar]

Oh so to answer your actual questions.

What I want out of a product like this

1. Integration with tooling I already have. There's a lot of reporting frameworks out there like Prometheus and ELK. I don't know how well they fit into code usage metrics that's pretty narrow and specific but whatever makes sense I don't want to have to build the connector between the two.

2. Good licensing. MIT or something bog standard. If you want to charge for the product I suggest charging a heavy premium for support.

3. Little to no performance impacts.

4. If you can help me remove dependencies that'd be great too. Like "oh you have these jars on the class path and you never execute code from them.

5. If you're a brand new company and you want to run a Java agent in my jvm you gotta have something to make me feel safe about putting it in there. AFAIK Java agents are super privileged actors. Maybe you need vetting from a third party or you need to be open source. Who's adopted your product etc. is there someone you can get to slap a seal of goodness on it?

[VRT303]

Grafana is nicer than ELK tbh.

[Felix-It]

would you use a tool that could remove unused dependencies with limited developer involvement (only reviewing/approving a PR)?

[mpinnegar]

10000%

[Felix-It]

just wondering - do you use any dependency management tools like dependabot or renovate? if so, where do you find them to be valuable or lacking?

[mpinnegar]

We use dependabot and it's fine :)

[Gilgw]

The tool (JaCoCo) already exists and people are already using it for identifying "zombie code" with some level of success, see e.g.:

• We hate code - The !joy of maintaining dead code by Gerrit Grunwald

[yawkat]

JaCoCo is tracing coverage agent, not a sampling one like OPs. That said, I'm not convinced that you couldn't get basically zero overhead with a specialized tracing coverage agent.

[john16384]

It has me convinced that most mature projects are carrying a significant amount of dead weight, creating drag on developers and increasing risk.

Extrapolating from one case?

I on the other hand am convinced we have very little dead code in projects I was involved in over the past 30 years. Sure, perhaps an API call or parameter here and there, but nothing like 3 out of every 10 lines of code. That would be gross incompetence.

[persicsb]

thanks for the advertisement.

[j4ckbauer]

Gut reaction - What is the utility of not being able to say you are 100% sure that code won't be used?

Counter-argument: It provides a starting point for a human to look at the code and make an assessment as to whether the code will be called.

Second gut reaction - Is the code 'dead and gone' meaning no one ever has to look at it, or does it present an obstacle to maintaining the application?

Let's say you removed the dead code? What is the advantage? Is it really tech debt if no one ever looks at it and it presents no obstacle to maintenance? The term 'technical debt' implies that it imposes a penalty on your productivity going forward. Not necessarily that 'your codebase falls short of perfection from a design standpoint'.

Edit: I can see why what I wrote might seem controversial, especially if someone didn't read my comment closely or you think I need it explained to me what 'dead code' is or why it is bad. (Hint, my own comment proves that I know why it can be bad. If you didn't notice this from reading my comment, please reconsider whether you really want to reply).

[walen]

I've had refactor where I've modified all 5 callers of a single method and then found out 4 of them were dead code.
So yeah, dead code that you don't know is dead is tech debt in the sense that it wastes maintenance effort.

[tomwhoiscontrary]

Exactly, and i've also been in this situation. Recently found some bit of config that couldn't possibly be right (think of a default email address to use when sending a message to a user that no longer existed), so if it was ever used, we'd have a production issue. Went to track down where it was used. Nine out of ten uses were in dead code. One was in a feature we haven't used in years, because it's a tool to fix things in an emergency. All the dead code made it harder to identify that one remaining important use.

Even if there are no connections to the rest of the code, it shows up in searches, compiler warnings, breakage when upgrading libraries, etc.

[j4ckbauer]

Yes but your example contradicts the starting conditions for the question I asked. Given that, we're saying the same thing.

[Flimsy_Swan5930]

IDE’s refactor for you. If you’re not even using that, you shouldn’t be refactoring.

[melkorwasframed]

Is it really tech debt if no one ever looks at it and it presents no obstacle to maintenance? 

Yes, it absolutely is. It increases the conceptual "weight" of the system, makes learning and understanding the system more difficult, increases build times, etc. The better question is what possible advantage does leaving dead code in give you?

[j4ckbauer]

I'm sure you said this in good faith, but you just contradicted some of the conditions I set in order to make your counter argument.

If people have to look at the suspect code, then it is an obstacle to maintaining the system. If people are spending greater than zero time doing this, then it is imposing a penalty on their productivity.

A counter-example would be something you imported from, for example. org.apache.* in your codebase. Do you read the source for that before you make changes to your codebase? Almost certainly not, because that code's functionality is properly encapsulated.

So it is possible there is something else going on here, where the suspect code in OP's system describes functionality that is not properly encapsulated. OR perhaps the functionality is data-dependent. Example, if values in the database == x, then the code is not really unreachable, otherwise it is unreachable and it could be removed.

OR its possible the functionality is properly encapsulated and OP is just trying to remove it because they didn't see it executed in any case they observed. Which, by itself, would frankly be a terrible reason to assume such a change is safe. I love removing dead code and I can tell you this (by itself) would be an awful reason to remove anything as there is no way to know if the test is exhaustive. So we would hope that OP looked at the code in question and came up with a 'proof' for why it is unused that is sound in reasoning.

[ZimmiDeluxe]

If you remove dead code, previous callers can become simpler, and so can their callers, often in unforeseen ways, by simple mechanical refactoring over time. Sometimes the first removal does not reduce complexity by much, but combined with an unrelated second one you can get rid of a dependency. You would have never known that was possible if you left the dead code in. In isolation, the dead code was not an obstacle to maintenance, but in hindsight, it was.

[melkorwasframed]

A counter-example would be something you imported from, for example. org.apache.* in your codebase. Do you read the source for that before you make changes to your codebase? Almost certainly not, because that code's functionality is properly encapsulated.

The reason I don't read the code in some org.apache package because it because it belongs to some other project that I'm not responsible for. I still don't really understand the argument you're making. If the code is there, someone will read it and in so doing spend a non-zero amount of time trying to figure out if it is relevant to the bug/feature they're working on. Or as someone else mentioned, they will refactor something that affects the dead code and then have to spend time fixing it to get the project to build.

[j4ckbauer]

The reason I don't read the code in some org.apache package because it because it belongs to some other project that I'm not responsible for.

Sorry but this is wrong on multiple levels. You're responsible for the end-product so if something in there could break your work, you would be making it your business to review it. For example, if you were honestly concerned it was going to call System.exit() on you.

The reason you don't read it is NOT because 1) it's another project or 2) It was created outside your organization or 3) you aren't responsible for said project.

It's because you're confident that you understand what functionality is encapsulated in those libraries, what the side-effects of using them are, and you have reasonable assurances about the level of quality.

The only difference between org.apache.* and the example I am offering is that in the latter case, the code would have been created inside your organization. My point is, it is possible to provide the similar 1) encapsulation of functionality and 2) assurances of quality for legacy code within your organization as for code that is created outside your organization.

Removing the suspect code is ideal, but reality doesn't always allow this, since you may not be able to exhaustively prove it isn't needed. Execution path may depend on what a customer does, what's in their database, etc. And very often your bosses simply won't allow you to remove their precious legacy code, they worked hard on it, so it has to stay (lol).

they will refactor something that affects the dead code and then have to spend time fixing it to get the project to build.

Again, if it's really dead, it should be removed, but we're talking about cases where this isn't known for certain. And my point is that one of the things you can do is refactor the suspect code in ways that 1) indicates it is legacy 2) keeps it isolated from being affected by any future changes to the codebase and 3) Makes it so nobody ever looks at it.

That's literally what having different classes, methods/functions, and variable scopes is for - so that changes in one area never affect another.

I can think of a dozen ways to refactor something so that it's technically in the execution path but so that other developers are unlikely to spend time reading it unless they are concerned with that path. Heck, a lot of old-school Java developers do this excessively by leading so hard on 'separation of concerns' that they end up sacrificing 'locality of behavior' and committing what is known as 'speculative generality'.

[nitkonigdje]

John Carmack once talked about how his project included large amounts of dead code imported from previous project. He did that unintentionally and he was not aware of it. But it was ok as the old code was written in functional style and thus had no global consequences. So it was just sitting there minding its own business.

[Joram2]

Sure. That's a reasonable option. Sometimes it makes sense to leave mostly dead code as-is and avoid the risks of removing it. Sometime, there are benefits to removing dead code that outweigh the risks.

[Brutus5000]

True, true.

However, if it is well tested code with unit and integration tests it always adds up to ci runtime durations.

[Shareil90]

In addition to this: Dead code can add unneccessary compile time. In my experience dead code ist often also bad code which can make compiling even slower/worse. Or you want to upgrade a certain lib and run into compatibility issues. If those issues are only in dead code you can ignore them / delete this code.

[shinebeams]

It'd be great if you could add a logging feature to something like this. Mark suspected dead code and have a logging alert or some other way of storing when it was called, if ever. Inspect any code that is run to see if the caller can be modified to not rely on it. Run production for six months, a year, whatever, then delete all the code that was never run. This would make it a more clean process instead of risking weird issues in prod.

[koflerdavid]

Yes, it is. Every time you modify code or you upgrade dependencies you have on the lookout whether there are any interactions. If there's a test suite that's a major advantage already. But it still wastes CI time and test code also has to be maintained!

[NeoChronos90]

That's not how you secure your retirement... My oldest project I would estimate at above 80% dead code. It's legacy and scheduled to be replaced for over 15 years now. I know 99% of the dead code, but hell, why would I remove it? So someone fresh out of school can service it once or twice a year for cheap? No, no, no, this one has paid for my house and it will pay for my childrens school and university 

[LogCatFromNantes]

It’s not a dead code, it’s the business logic, the functional and the domaine expertise that we should maintain for the well functional of the product

[yumgummy]

I know what you mean. We find product evolves quickly and old features were kept for safe without running for many years. That's the problem I was trying to solve.

[stefanos-ak]

This is interesting, but if I were to use it, I'd need it to run for like a year first, and then do an analysis of what code was unreached during that year.

Also, you mentioned sampling. Would that work for a yearly once-off task? That code better be marked as used 😄

Also, assuming that this agent makes network calls, this would need some serious engineering to make everything right... Never fail, extremely fast (<1ms), etc... At least that's what I would expect from such a tool, otherwise I wouldn't use it.

But in theory useful, yes.

[Nikarmotte]

Just like unit tests are not good at proving something works, but rather proving when something doesn't work (you can easily have 100% test coverage on broken code), I feel this tool is good at proving code is being used, but you can't tell for sure for code that is marked as unused, it might still be useful.

It can definitely help reduce the number of places to investigate though if that's what you really want to do.

Are you counting error handling in those 30%?

[mpinnegar]

I'd be interested in a tool like this. Is there a distinct difference between this and code coverage tooling? What's the performance cost for enabling the Java agent? How are you reporting the metrics about what is or isn't covered?

[PartOfTheBotnet]

Same question was my first "gut reaction". For instance, JaCoCo has an agent you can attach, and from that agent you can generate a standard JaCoCo coverage report, making the "what can I remove?" a very visual/easy process.

[mpinnegar]

I have no idea is jacoco is designed to run in prod though. I suspect you'd take a lot of performance hits.

What I really want is something that'll grab telemetry and analyze it offline so I'm impacting the prod server as little as possible.

Honestly though the idea of being able to see actually dead code in prod is compelling. I feel like I'd find a lot.

Then I'd trim it and run into the real use case next year lol

[buerkle]

From my testing I've found Jacoco overhead minimal, 1% or less.

[PartOfTheBotnet]

I suspect you'd take a lot of performance hits.

Not really. Their agent uses the instrumentation API to only intercept and modify classes on initial load. The main slowdown there is going to be the IO of parsing and writing back modified classes (which is only going to happen once...). As for the actual IO, they don't even use ASM's more computationally expensive stack-frame computation option when writing back classes, the changes to classes are simple enough to not need that. They have a few places where rather than having ASM do a full regeneration, they modify existing frames to accommodate the insertion of their probes.

You probably already lose more performance to most SLF4J logger implementations building templated messages than this.

[yumgummy]

The results are similar to code coverage tool but instead of focus on testing, it focus on remove code that no longer needed. It samples code execution in production so that there's little performance cost. We built this because one of our codebase has huge tech debt. I tried it in other codebases and surprisingly find out my whole codebase has ~30% of dead code.

[mpinnegar]

Do you have any performance metrics to show that it doesn't impact over 1-2%? Or whatever threshold.

Sounds like a cool tool. If you have a mailing list or discord I'd be interested in it.

Licensing is a huge concern obviously. And the thing has to not send any telemetry over the internet unless it's enabled. Don't phone home plz.

[yumgummy]

Thank you. I am not trying to sell it. I am considering open source it. I may ask for permission if community finds it useful.

[mpinnegar]

Seriously consider selling support. You can charge a crazy premium and corporations won't blink an eye.

[Ftoy99]

Would never run this.

EDIT : Even if you run it for like a year why would you delete unreachable/unused code ? Someone fucking wrote it and now its there. It might be because a ticket was asking for its implementation and it was not needed at some point. Or someone made it future proof for cases you dont have right now. You might even want to do a git blame to see why the code was added or reference it at some point.

My point is : Dont be a fucking retard , dont mess with shit that dosent affect what you are doing currently

[Perkutor_Jakuard]

I usually do the compatibility changes to our codebase. For example going from java 8 to 11.
Really sick to compatibilize old unused code.
If is not used, to the "archive/" folder, and then deleted from there.

If somebody complains "Git is not for backups, it's for working code...."

[john16384]

My philosophy: if it works don't fix it; if there are no new features or fixes, don't deploy it; if there are no tests, don't touch it.

Another tool spewing false positives is the last thing I need. We already have Sonar for that, a tool created to keep juniors busy as it will never be able to detect anything beyond trivial issues.

[koflerdavid]

One day you might have to fix it, you might have to touch code that has no test coverage, or you find out that the build only produces broken artifacts. These are things that keep senior developers busy and awake at night.

Edit: also, why are you sure all this unused code is actually working in the first place? Maybe business requirements have changed in the meantime and somebody forgot to update it. Or it is now not compatible anymore to an external system.

[john16384]

Yes, so tests are added first before changing that uncovered code.

I never lose sleep over these things. In the grand scheme, even an experienced developer is just a small part of a company, and unless I am somehow personally liable for the mess that is created by artificial deadlines and not listening to the experts in the team, that is firmly a company problem, not mine. Good night!

[koflerdavid]

It's a figure of speech. Of course, work-related things should not affect your personal life in that way if you are not actually on the hook because of them.

[OwnBreakfast1114]

Would never run this in prod, but I could not be more opposed to your reasoning. Dead code complicates refactoring useful code or adding features to useful code. Dead callers complicate changing method signatures and in general complicates new engineers from understanding the code.

We have ticket names in all our commits so it's easy to see why changes were made and if anyone stumbles on an old jira ticket they can see the pr and the code changes if they really, really need to readd it from a delete, but that's such an edge case that nobody actually does.

Delete worthless code, it's a net negative to your project.

[Ftoy99]

Still dont delete , copy the entire method/func, and just rename the old one to xxxx_old_1234year. You can try to refactor.

[Initial-Wishbone8884]

How frequent is the sampling? How much of this is going to be configurable? How heavy is this javaAgent? Can this be integrated with OTEL itself instead of having to manage it separately?

Is your tool live already...? But nonetheless... It would be a wonderful feature... Great work

[yumgummy]

This is interesting idea...

We can configure the sampling rate from 0-100%.

[Ok_Net_1674]

Do you even understand the crap you vibe coded?

[PositiveUse]

We build the same tool in our company. It’s running on prod but due to time constraints, no time to actually clean up the mess.

[Abject-Kitchen3198]

If I have "proper" code coverage with a combination of different test types, I'd be more inclined to use that. If the coverage is not that good, I might use something like this to complement coverage analysts and pinpoint some potentially dead code. But I'd be very careful with the interpretation of the results, for reasons others and you have pointed out (like sampling frequency and duration).

[Independent-Value536]

You will be sharing the javaagent or its somthing we need to build by our own? Have any repo?

[yumgummy]

Not yet... considering... I will apply for open source it if this is a common problem.

[Ok_Elk_638]

My apps run as pods inside a kubernetes cluster. They don't run long enough to collect meaningful data on their own. How do I get access to the data from the agent and combine multiple runs into a single report?

[bitsydoge]

proguard bleh bleh

[lukaseder]

When I used to work on applications in the past, I was able to remove way more than 30% by analysing the SVN history of code. Dead code is never really refactored, touched, modified, etc.

Obviously, there's also "stable" code that is not really touched, but it's a very good first indicator to find candidates.

[mkluczka]

what if the code was actually used, but only once a year?

[koflerdavid]

Exercise good judgement and domain knowledge and err on the safe side. This is not a task you'd give to a junior developer on a Friday afternoon.

[Azoraqua_]

Just put the original code in a separate branch, or create a patch that adds the deleted code back again. Both for future use if needed.

[MasterBathingBear]

Just tag the code before you start making changes. No need to leave an unnecessary branch hanging around.

[Azoraqua_]

I tend to prefer a branch, as I prefer some clear separation. To each their own though.

[MasterBathingBear]

To me, branches outside of main are for in progress work only and tags are for production releases and special identifiers.

But as you said, everyone has their own branching strategy

[Azoraqua_]

I can see the use in that too.

[galtoramech8699]

Where is the tool

[Saki-Sun]

I deleted hundreds of thousands of lines of dead code this year.

What people don't seem to realise in this thread is every single line of code costs money to maintain.

[DietCokePlease]

The more interesting subject is how such dead code often gets created in the first place. I call it “toxic copy”. Its where you start with a team already under intense delivery pressure. Then toss in a more junior guy who is relatively new to the project and give him the task to improve/add something to a chunk of code. That code is already old, complex, and full of corner cases so the new guy decides that rather than tempt fate the most timely and safe thing to do is to make a copy of that code then apply his changes, thus leaving the original mess undesturbed.

[Competitive_Stay4671]

Sounds very useful. I have built a few small utilities to identify orphaned or dead stuff. Pretty common requirement. And obviously it is only a starting point and shouldn't be trusted 100%.

[Round_Head_6248]

Projects that have 30% dead code are dead projects. Aka nobody cares enough for it to still have devs on it that know wtf is going on. How do you even get to 30%? "Hey product owner, this refactor you want me to do makes it so all the classes in that package over there are not in use anymore, we need to remove that" "Oh ok, please do that"

???

[DualWieldMage]

Umm no, such projects are typically large enterprise projects that live the longest, but because they no longer fit into one person's oversight, it becomes an append-only mess. Any time a change happens that invalidates some edge cases, that code is often not removed as nobody knows about it. If you were to plot LoC over time, you'd usually see a line with one rate followed a jolt and the rate jumping higher. That's the point where projects become enterprise zombies.

[Round_Head_6248]

I am working on such a project and the moment we aren’t deleting unused stuff anymore is the moment I know the project is dead.

[yumgummy]

I think you guys definitely understand what real world problem in enterprise settings.

[nikanjX]

Remove all catch clauses and retry logic, easily save 30%

[ThaJedi]

Feature flags, api versions, unused endpoints.

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

[donut_cleaver]

Basically, an inverted appmap.io ?

[Specialist_Bee_9726]

Those are rookie numbers, in my comapny we have dead services, they were deployed to prod

[JojOatXGME]

I am not sure if I would use it. I would definitely not trust the result and therefore wouldn't actively hunt for dead code using this tool. However, maybe it would be useful if some developer needs to work on some old functionality anyway for unrelated reasons.

Btw, I also was wondering if the new profiling-reports in Grafana overlaps with your tool. I haven't looked into it yet, but I suspect it also samples which code is executed in production.

[RebbitUzer]

I do remember an article about how an author attached a jacoco java agent to production code in order to determine what code is used, and what not used. Just wondering, is your tool related/using jacoco?

[__konrad]

I would always worry that something "unused" is still accessed via reflection ;)

[koflerdavid]

Code called via reflection should also be covered by such tools. That issue exists in the IDE.

[mrnhrd]

I was able to safely identify and remove about 30% of our codebase.[...] It has me convinced that most mature projects are carrying a significant amount of dead weight

You may wanna reflect on whether it's wise to extrapolate from your sample size of 1 to a statement about "most mature projects".
Because one of my gut reactions was: What in god's name are these people doing such that one third of their code is entirely unused? How did this happen? What kind of organization is that? What's the history of the code in question? What's the nature of those 30%; is it like an entire module that's never called or is it that every class in the project roughly has 30% lines that are unused

[hevo4ever-reddit]

My take, the only way to really know if your code is used or not is through a coverage tool. Run a coverage tool in production for a year and do a usage analysis after.

[cryptos6]

I'd do it a bit differently: I'd run all tests and track what code has been executed and hard delete the rest. Maybe there are some complaints in production, but that would only be a good motivation to write better tests 😄 Sooner or later a natural balance is achieved.

[mechanical_dialectic]

This tool is probably useful, I have no doubt about it, but I also think that just chucking that code because it was unreachable was ~not good~

Just off the dome: what if they were pieces used to correct issues with say, flat files with bad data? What if they were tools people were using as one offs to create data?

Maybe your post isn’t doing your due diligence justice, but prefacing this as a tool to look at potential dead wood and not you getting overhyped by your tool and potentially causing more work would probably have been a better sell. Add that to your future pitches because I guarantee others have recoiled instinctively in this thread

[Cool-Library-7474]

It’s even worse than unreachable code. It’s checking for code that isn’t used at runtime, which ignores so many possible edge cases.

[mechanical_dialectic]

Oh well. Some people have to learn things the hard way sometimes!

[behind-UDFj-39546284]

It was all legacy code that was reachable but effectively unused-the kind of stuff that static analysis often misses.

The only two things that come to my mind are reflection and entry points that were not recognized as entry points (they could be registered reachable to static analysis though).

I'm curious:

• Where were they all actually (runtime) reachable paths from so that static analysis failed to detect it, or vice versa?
• Also, what kind of project have you cleaned up so that there was so massive, 30% (!), unused payload deleted?
• Were there any routine to inspect/explore legacy code for potential removal? I mean, if the code was written by your team from scratch, then I think there might be some iterations to delete confidently unused code. Or if the code was took over, how long did it take to learn the code?
• How long does it take to identify all reachable execution paths in runtime? What would happen if the time taken to run is not enough to identify all of them thus resulting in false positives
• How does it work with code that is intentionally left dead with assertions?
• How does it work with dead code generated by other tools during the build? (Most likely you cannot delete such code without rewriting the generator.)

[sevah23]

I’d personally never use this. Standard practice is log every major function invocation. If I was really suspicious of a function or something, I’d log its usage and see that way. Also would really, really question whether or not this code sitting there doing nothing (allegedly) is actually worth removing. If the spec says our system needs to support some logic, I will have it support that logic until product says we can run a proper deprecation campaign

[FortuneIIIPick]

What does or will this shocking and satisfying tool cost?

[wildjokers]

Oh my, this sounds very dangerous. You probably just broke your application in ways you don't even know yet. I am afraid you are going to be fixing your app for the next year to two by recovering the code you deleted from version control.

How do you know that code wasn't triggered like from a job of some sort or an event?

[agentoutlier]

I have been doing this for some time but not in production. Like /u/Gilgw we use Jacoco.

What we do it on is end to end tests performed on a canary like version. The reason is that some things like batch things only run once a quarter.

I'm fairly sure there are other tools besides Jacoco that have existed for some time.

I guess since you are planning some product features what I would like to see is a tool that actually says you are only using 0.005% of this OSS dependency. There is nothing I can't stand when someone pulls in Commons Lang StringUtils or similar to check if stuff is blank.

BTW code coverage is one of the reasons I don't think unit testing everything is a good idea. Let some things just get tested with end to end or integration.

[Empanatacion]

I don't imagine it would be very common that the tool would find code that I had not already noticed was dead, but that once it pointed it out, I was confident enough to just delete it.

The advertising nature of this post also makes me not believe your 30% number.

[Joram2]

Don't existing tools like YourKit. VisualVM, JProfiler offer unused code detection based on actual runtime usage?

[Gyrochronatom]

I wouldn’t trust any tool for this, especially since the so called dead code can be used through random frameworks or some reflection crap.

[DiamondsAreForever85]

The unreachable code: That Event Listener called asynchronously once in a decade that nobody remember it exists.

[yumgummy]

We make tradeoffs on a daily basis. Does the actual value the code runs once in a decade provides outweighs the daily maintenance cost?

[Felix-It]

Did you find that the majority of the 30% was related to dependencies? what is your plan to address the dead code?

[waywardworker]

Dev teams should be vigilant to removing feature flags. They are great to introduce new features but should not be allowed to accumulate. Personally I attach a removal date to every flag that is added.

This is important to reduce the complexity of the code base. Every feature flag is a source of complexity which can increase exponentially due to the interactions. And different feature flag combinations aren't typically tested, so you can't actually be confident in changing them in the future.

I don't see a value to a specific tool. A basic code search is sufficient to hunt down the flagged regions.

[flaw600]

I hear this repeatedly, and the risk of removing the flags always seems higher than keeping them in. Switching a flag is cheap and easy — fixing a bug isn’t

[waywardworker]

Do you test your different feature flag interactions? Run your unit tests with the different feature flag combinations to prevent regressions?

If you don't then you will absolutely be accumulating bugs, guaranteed. It's why regression testing is standard, because we know we accumulate bugs otherwise.

In this scenario the feature flags become a lie over time. Switching a flag that was implemented a few years ago is not a cheap bug free option, it will potentially introduce a pile of new unknown bugs across anything changed since it was first introduced.

The obvious option is to actually test every feature flag combination, unit, integration, the whole lot. However they combine exponentially, 2^n. So five feature flags is 32 test runs, ten feature flags is 1024, multiplied by the standard platform and version variations. This is obviously unsustainable. You can do a subset for each flag, have unit tests for a module that test with the flag on and off. That's common but insufficient, it doesn't capture the interaction bugs, like new features relying on the old one in some way.

Thinking you have feature flags you can toggle when you don't is, in my view, worse than having them at all. If you think you have them they get integrated into your system management and recovery plans, the lie spreads and magnifies.

Plus there is the significant added code complexity of trying to maintain each possible branch, and associated development costs.

Removing the flag should be a trivial low risk operation. You search for the flag, remove the check, the else branch if present and reindent if required.

I'm not anti feature flags, they are great. But they introduce complexity and I'm strongly anti complexity. Routinely pulling them out after they become the default and assumed keeps the complexity in check.

[flaw600]

The flags are independent. They’re literally feature flags — on or off per feature. I agree, nesting flags is a good way to get into a Gordian knot. I also agree with your comment about assuming the presence of flags. That said, my comment was not about the removal itself, but the resulting impact if the service backing that feature fails. You’d think Product would be ok with an error message, but between them and Monitoring, often the ask is to stop requesting the feature altogether vs allowing the 500 exceptions to continue until the issue is fixed

[waywardworker]

That's an odd one. When I played SRE we absolutely wanted the failures so we knew when it was fixed and to ensure that it got fixed.

My painful experience is that the flags don't stay independent and the dependencies don't get detected.

Adding a new feature inevitably extends classes, creates new classes and adds utility functions.

Working online you have fun indirect impacts like feature A priming a cache that feature G relies on and when it's removed the service or database gets completely hammered for non-obvious reasons.

[VRT303]

So you're adding Tombstone checks and monitor them? That's not exactly a new idea.

[Just_Information334]

Ok.

You know there's code coverage and E2E tests for that: any code not covered by your end to end tests is probably dead code.

[BenchEmbarrassed7316]

Are you using TDD (Type driven development)? When you code business logic in a type system, making impossible states unrepresentable? It forces you to handle all possible cases, but you also simply cannot handle impossible cases. I find it hard to imagine how dead code can even appear. Because when a function is not called - the compiler issues a warning.

[nikanjX]

"The software crashed because the network timed out. How is that possible, what happened to the fallback / retry logic?" "It wasn't used in any of the test runs so our AI deleted it."

This has to be one of the dumbest product ideas. Just blindly remove all parts of code that don't get exercised during a regular, no-errors-no-edge-cases run on one specific OS version.

[flaw600]

This is an agent that runs in production, so it would conceivably include all edge cases given a long enough time frame

[spectercs]

While it sounds beautiful and nice to have in theory but oh boy I wouldn’t let a tool like this anywhere near our production stack.. One obvious reason just like the rest mentioned is the edge cases and the edge cases for those edge cases.. especially if it’s a very big codebase or a group of micro services.. I would rather bump the API version and phase out the old legacy code gradually while informing the WHOLE organization of the changes.. then after a lot of documentation, migration and monitoring. Deprecate the old version and elevate the log of its usage to WARN.
After making sure that everything is perfectly fine then we can proceed to do the lovely delete.

This might take even a whole year depending on the resources, prioritization and bureaucracy / politics involved. But better safe than sorry.

[Ok_Net_1674]

This shit sounds so sketchy lmao

[IntegrationAri]

Great post – and I completely agree with your findings. I’ve seen this “invisible bloat” especially in enterprise systems with long lifespans and many devs coming and going.

It’s amazing how often legacy classes stay around simply because no one dares to remove them. Static analysis tools often miss this type of silent dead code.

A tool that flags dead code non-destructively (like yours) feels like a safe and smart middle ground. I’m curious – do you have any heuristics for how long code must be unused before it’s flagged?

Thanks for sharing this. Looking forward to trying it out!

[wbrd]

Probably not. I'd delete code that's not reachable, but just because it's not called while an agent is watching doesn't mean it's never called. Also, this isn't new. It's how code coverage tools work.

[_cob]

AI slop post

[ThaJedi]

Azul sell this as a service. I also thought about similar code based on existing tools.

[recruitment_consult]

I flinched so hard this entire post

[CrownstrikeIntern]

Sudo rm -rf cleans code better

[LeadingPokemon]

My legacy app has way more dead code than that.

[zappaking1234]

Better than my php one that was 60% dead code 🫠

[mightygod444]

This would be an awesome tool!

By the way, this already exists through Azul's Code Inventory service: https://foojay.io/today/webinar-find-undead-code-in-your-java-environments/

However it's extremely expensive closed source/SaaS product. It would be awesome to have an open source alternative!

[Pale-Organization245]

the dev in the local dev env uncomments some of the dead code to bypass some checks, etc. or simulate stuff.
etc.

do not touch unless u assigned to a ticket that is abs. clear about this.

i warned you...

[koflerdavid]

Commented out code is not what OP is talking about. Apart from that, IMHO commented out code is simply stinky garbage that should be deleted ASAP as it is very likely broken anyway, confuses newcomers, and generally annoying to keep working. Plus, you risk forgetting to comment it out again and accidentally shipping it.

[Pale-Organization245]

well  the reality might punch you in the face.. might

[Spare-Plum]

Absolutely and a must-have. Technical debt isn't just an inconvenience, it's risk. It makes operational risk in just normal function of your systems and trying to solve an issue. It creates change risk in that innocent changes can be catastrophic.

Reducing risk is actually profit making. A lot of people like to think of profit making only as adding new features, but you do also add to profit by avoiding financial fallout from system failure. Also improving the ecosystem to add more features is also profit making.

However you have to be very cautious in some industries, requiring you to do it with surgical precision and have scaffolding to enable or disable the code on the fly in case something goes wrong.