Proven Techniques to Tackle Tech Debt

Every time you open a file for any reason, make one small improvement before you commit: rename a cryptic variable, pull a magic number into a named constant, delete a commented-out block, add the edge case test you noticed was missing. The changes are small enough to ride along inside a normal pull request, so no approval is needed and no separate budget line appears.

Use it when the codebase is structurally sound but grubby, and when you have no mandate to do anything larger. Do not use it as a substitute for real remediation on a module that is genuinely broken - polishing the surface of a rotten design just makes the rot harder to see.

Put a facade in front of the legacy system so every caller goes through one seam. Behind that seam, reimplement one capability at a time and switch traffic to the new implementation with a flag. The old system keeps serving everything you have not migrated yet, so you are never in a state where the product does not work.

Reach for it when a rewrite is genuinely justified but a stop-the-world rewrite is not survivable - which is nearly always. It costs more calendar time than a rewrite on paper, and that is exactly the point: you can stop at any milestone and still have a shipping product.

Every technique above needs somewhere to happen. This policy reserves roughly one day a week - or a fixed slice of sprint capacity - for debt work that is planned, estimated, and demoed like any other work. Teams implement it three ways: a fixed day (every Friday), a capacity slice (two story points per developer per sprint), or a rotating champion who owns debt for one sprint at a time.

The name is borrowed, and it is worth knowing from where. Google's 2004 founders' IPO letter told shareholders the company encouraged employees "to spend 20% of their time working on what they think will most benefit Google" - a policy about self-directed projects, not about technical debt, and no study has since established twenty percent as the right share for debt repayment. So treat the figure as a convention with a memorable name, not a benchmark. What makes the policy work is that the capacity is protected and recurring; the exact fraction is yours to set.

Source: Larry Page and Sergey Brin, "An Owner's Manual" for Google's Shareholders (2004 Founders' IPO Letter), 2004.

Making it survive contact with a deadline

• Ticket it. Debt work that exists only in someone's head is the first thing cut. Work that has a ticket, an estimate, and a demo is work.
• Make the outcome visible. Report the build time you cut or the flaky test you killed in the same review where features are demoed.
• Never bank it. "We will do a double debt day next month" is how the policy dies. Unused time is lost, not accrued.
• Protect it in writing. If it is not in the team working agreement, it is a preference, and preferences lose to deadlines.

Three frameworks cover almost every case. ROI-based prioritization turns each item into hours saved per quarter against hours to fix, which is the only version a finance-minded stakeholder will engage with. The impact and effort quadrant is faster and good enough for a team backlog: quick wins first, then the big rocks that block the roadmap. The Pareto approach targets the small set of files that generate most of your incidents, found by crossing change frequency with defect counts.

Whichever you pick, sequence by where the code changes most. Debt in a file nobody touches costs nothing this quarter.

Tooling falls into three jobs. Prevention: linters, formatters, and type checkers that stop debt at the keyboard. Detection: multi-language static analysis and dependency scanners that inventory what is already there. Enforcement: CI quality gates that reject a merge which makes the numbers worse. The third one is the only one that changes behavior - a dashboard nobody is accountable for is a dashboard nobody reads.

Start with one metric you can move this quarter, wire it into the pipeline, and add the second only once the first is boringly green.