Finding Dead Code in a Legacy App: What Actually Worked

1. Instrument Everything: For every public API endpoint, controller method, or service entry point you suspect is unused, add a log line or increment a metric. Don’t be subtle. A log like WARN: Deprecated method 'processLegacyReport' was called. Please migrate to 'generateNewReport'. is perfect. If you’re using a monitoring system like Prometheus, incrementing a counter is even better: dead_code_candidate_usage_total{method="processLegacyReport"}.inc().
2. Wait (No, Really, Wait): This is the hardest part. You need to let this run in production for a significant business cycle. A week is not enough. A month is better. A full quarter is ideal. You need to account for end-of-month reports, quarterly summaries, or other infrequent jobs that might be the only callers of that code. Patience here prevents production outages later.
3. Analyze the Results: After your waiting period, it’s time to reap the rewards. Check your logs or your monitoring dashboard. Do you have a single log entry for that method? Is the counter for that metric still zero? If so, congratulations! You have a very, very strong candidate for deletion.

This approach transforms guesswork into a data-driven decision. It provides concrete evidence to include in your pull request, making it much easier to get approval from nervous teammates or managers. It’s the difference between saying “I think we can delete this” and “I have data showing this code has not been executed in 90 days.”

Code Coverage Isn't Just for Testing

We usually think of code coverage as a metric for our test suites. But what if we could get coverage data from our application running in production? Some advanced Application Performance Monitoring (APM) tools offer this, but there’s a simpler way to get a directional clue.

Run your entire test suite—unit, integration, and end-to-end tests—and generate a combined coverage report. Now, look at the files and lines that have 0% coverage.

What this tells you: If a piece of code isn’t even touched by your most comprehensive automated tests, it’s a huge red flag. It could mean:

• The feature it supports was never properly tested (a problem in itself).
• The feature it supports was removed, but the code was left behind.

The Reality Check: Like static analysis, this is an indicator, not a final verdict. The lack of test coverage doesn’t prove the code is dead, but it gives you an incredibly accurate map of where to start your investigation. These are your prime suspects to instrument with the logging and metrics strategy we just discussed.

The Archaeological Dig: Version Control History

Sometimes the tools can’t give you the full story. That’s when you have to put on your detective hat and dig into your Git history. This is especially useful for understanding the context behind a piece of code.

Your best friend here is git log. Let’s say you’re investigating a mysterious function called calculateSpecialDiscount().

# Find every commit that ever touched this function
git log -S "calculateSpecialDiscount"

This command will show you the history of that specific string. You can trace it back to the commit where it was added. The commit message might say, “Add discount for 2018 holiday campaign.” Aha! A clue. If you know that campaign system was decommissioned in 2020, you’re onto something. This historical context is invaluable and something no automated tool can provide.

The Deletion Strategy: How to Remove Code Safely

Finding dead code is only half the battle. Deleting it without causing an incident is the other half. Never just hit delete and merge to main. That’s how you get paged at 3 AM.

Here’s the safe, multi-step process that worked for us:

1. Deprecate First: Mark the method with a @deprecated annotation and update its documentation. This signals intent to other developers. The logging we added earlier also serves as a form of runtime deprecation warning.
2. Communicate: Announce the deprecation in your team’s Slack channel or engineering-wide mailing list. Say, “We plan to remove this endpoint in Q2. If your service depends on it, please contact us immediately.”
3. Use Feature Flags: For high-risk code, wrap the logic in a feature flag. This gives you a kill switch. You can disable the code in production without a new deployment. If something unexpected happens, you can flip it back on instantly.
4. The Final Cut: After the code has been deprecated, logged as unused, and/or disabled via a feature flag for a safe period, it’s time. Create a pull request for the deletion. The PR description should be a summary of your investigation: “Removing processLegacyReport endpoint. Confirmed 0 calls in production over 90 days via metrics. Deprecation announced on [Date]. No objections raised.”

Conclusion: It's a Marathon, Not a Sprint

Clearing out the deadwood from a legacy app is one of the most satisfying tasks in software engineering. It reduces complexity, lowers cognitive load for new developers, and makes the entire system easier and safer to maintain.

The key takeaway is that there’s no single magic tool. The process that truly works is a layered approach: start with automated static analysis for quick wins, then use logging and metrics for data-driven evidence on public code, supplement with coverage reports and Git history to guide your investigation, and finally, follow a safe, methodical deletion process. It takes patience, but the reward is a healthier, more resilient codebase.