The Hidden Cost of Unused Code

Time spent on CI, onboarding, and refactors is where dead code's costs become visible. Nobody files a ticket saying "dead code caused this." Instead, it appears as slower CI, longer onboarding, harder refactors, and larger diffs in unrelated PRs. Each cost is hard to see alone and clear only in the larger picture.

To be clear, we are not claiming that dead code is the main reason engineering teams move slowly. Architecture, staffing, product complexity, and organizational dynamics matter more. Dead code is one factor among many, not the root cause of every delay. Still, it is a factor that can be handled more systematically than most.

The CI Build Tax

On every build, the CI pipeline parses, compiles, and type-checks every repository file. Dead code consumes that work while producing nothing. In a language such as TypeScript or Java with a meaningful compilation step, an aged codebase can have a significant gap between compilation time and the code actually in use.

During early-access pilots, we measured build-time changes after removal passes. In repositories where 15 to 20% of files were removed as dead, CI build time typically fell by 5 to 10%. Results vary substantially by language and toolchain. TypeScript compilation delivers the largest gains, while Python interpretation gains less because per-file overhead is lower.

Tests often contribute more than compilation does. Dead code with test coverage, rarer than you might think but still possible, keeps tests running for code absent from production. Removing that code removes its tests too, which can account for a meaningful share of total test runtime when dead modules retain partial coverage.

The Onboarding Tax

New engineers learn a codebase by reading it. If a substantial share of that material is dead, the mental model they form is larger and less accurate than necessary. They learn an old version of how a feature worked alongside the current version. They find modules for product directions abandoned two years ago.

The cost goes beyond reading dead code. Confusion arises when dead code conflicts with live code. An old feature implementation beside the current one raises questions: which is active? Is the old one a fallback? Do different conditions use both? The new engineer cannot answer without asking someone or investigating git history.

Answering these questions takes time, and each new engineer must reconstruct the answers. Teams with high turnover pay repeatedly. Dead code is not fixed friction. Its cost grows with the number of engineers joining the team.

The Refactoring Tax

Before a significant refactoring, engineers first determine what must change. Dead code artificially enlarges that scope. A refactor that should touch 40 functions implementing the feature may appear to touch 70, because 30 of those 70 are dead implementations of earlier versions of the same feature.

The engineer planning the work must either spend time proving those 30 functions are dead and outside the scope, include all 70 and do unnecessary work, or, worst of all, edit dead functions believing they are live. That wastes time and may cause confusion during code review.

Dead code makes refactoring scope harder to judge accurately. The result is more planning time, larger PRs, and greater cognitive load for reviewers.

The Dependency Upgrade Tax

A breaking API change in a dependency requires finding every old-API call site and updating it. Dead code that calls the old API creates call sites that appear to need changes until someone establishes that they are dead.

In a 180,000-line codebase with 20% dead code, a dependency upgrade changing an API used in 100 places might include 20 dead-code call sites. The upgrading engineer does not know that initially. They must either handle all 100 call sites or spend time separating live from dead before choosing what to update.

The Review Tax

Pull request review has a fixed time window. Reviewers can review only so much code per day, and that capacity often limits team throughput. Substantial dead code makes diffs larger whenever a change touches a shared module. Reviewers must read adjacent code that is not part of the change. That means more context, more distraction, and more cognitive load per review.

This is the most dispersed part of the dead code tax. It does not appear as one measurable expense. Instead, review time rises slightly per PR, multiplied across every PR, the entire team, and as long as dead code remains.

What the Tax Actually Costs

Assigning exact figures to these costs is genuinely difficult. Team size, language, toolchain, and codebase specifics vary too much for broad generalizations. From removal projects with early-access teams, I can say that the cumulative effect on perceived velocity is consistently noticeable in the 15 to 20% removal range. Engineers who have worked in the codebase for a long time consistently call the work after removal "lighter," even when they cannot quantify the change.

The tax is real and compounds over time. Unlike most technical debt, it can be addressed systematically without redesigning architecture or rewriting features. The code simply is no longer there. That is what deletion does.