I Deleted 4,000 Lines of Our Codebase and the Test Suite Got Twice as Fast
Nobody asked me to remove the dead code, which is exactly why it had been sitting there for six years.
Last spring I spent two weeks doing something that never shows up on a roadmap. I deleted code. Not refactored, not rewrote. Deleted. By the end, our claims-processing service was 4,112 lines lighter, and our CI run had dropped from 19 minutes to just under 9.
I work on the backend team at a mid-sized insurance company in Columbus. Our service is eleven years old, and like most eleven-year-old services, it carries the fossils of every product decision anyone ever made. Some of those fossils still had tests. Those tests still ran, on every commit, for every engineer, forever.
How I found the dead weight
I did not start with a grand plan. I started with a coverage report from production traffic, not from tests. We turned on lightweight tracing for one week and logged which handlers and modules were actually invoked by real requests. Then I compared that list against the codebase.
About 14 percent of our modules had zero production hits in seven days. Some of that was legitimately rare, like the year-end reconciliation job. But a lot of it was stuff like a fax intake adapter for a partner we stopped working with in 2019, and three different versions of a premium calculator, two of which were behind feature flags that had been set to off since before I joined.
I made a spreadsheet with four columns: module, last production hit, last commit, and who might know. That last column mattered most.
The conversations were the real work
Deleting code is easy. Convincing people it is safe to delete is slow. I sent short messages to eleven people, some of whom had moved to other teams. The message was always the same: "This module has had no traffic in seven days and no commits in three years. I plan to remove it on the 14th. Is there any reason I should not?"
Nine people replied within a day. Two of them said, roughly, "Oh god, please." One person told me the fax adapter was still contractually required to exist, which turned out to mean a lawyer had once asked about it in an email. We checked. It was not required.
The two people who never replied got a second message and a calendar reminder. Then I deleted their code too, in separate pull requests, so it would be easy to revert.
What actually got faster
The test suite went from 2,840 tests to 2,191. Most of the time savings came from a handful of slow integration tests that spun up a fake SFTP server for the fax adapter. Each of those tests took around 40 seconds. Nobody had questioned them because they always passed.
Build times dropped, but the bigger win was cognitive. New hires used to ask why there were three premium calculators. Now there is one, and the onboarding doc lost two pages.
What I would tell someone starting this
Use real traffic data, not intuition. Delete in small pull requests with boring titles. Give people a date, not a question. And keep a list of what you removed, because six months later someone will ask, and "I checked" is a much better answer than "I think it was fine."
We have not reverted a single one of those pull requests.
