The Technical Debt Tax

Now suppose the tests give false alarms. She has to work out whether a failure means a broken check or a broken charge. The ticket still says pricing, but it has acquired an investigation into billing and another into the tests.

Verifying billing is necessary. Reconstructing the same behavior from scratch on each change is a cost worth questioning. If the engineer leaves reliable checks behind, some of today’s work can serve the next change. If she works around the problem without resolving it, the next engineer can inherit the same investigation.

In his 1992 WyCash experience report, Ward Cunningham described the time spent on immature code as interest on technical debt. He also defended shipping early and improving the implementation as understanding grew. The cost of carrying the design and the cost of improving it are different entries in the account.

That recurring extra work is the technical debt tax. It deserves attention because it consumes capacity inside apparently ordinary feature work, where a budget for new development can conceal repeated work on old problems.

Find the work that repeats

There is empirical evidence of that burden. In research published in 2019, 43 developers at six companies reported how much development time technical debt had cost them over a seven-week reporting period. Their reported average was about 23%, with substantial variation. The authors warn about both the selected sample and the difficulty of attributing wasted time correctly. The study examined reported costs, without measuring how much a cleanup would recover.

The useful inference for your budget is to investigate your own recurring work. Applying that average to payroll skips the part where you establish what your team is doing and why.

Start with completed changes in an area the roadmap will require you to touch again. Read the tickets and code reviews with the engineers who did the work. Ask them to identify the steps imposed by the existing system, then point to what made those steps necessary. A note about manually checking old billing behavior is more useful than a label saying the ticket was difficult.

Separate the requested feature from the extra investigation, workaround, or repair. If the request changes what a customer owes, working out the right charge belongs to the feature. If it changes only how an unchanged price is shown, having to reconstruct the charging logic because presentation and billing are tangled is a candidate recurring cost. Billing deserves scrutiny even in a well-designed system; the question is which part of that scrutiny the existing design makes you repeat.

The investigation into false alarms needs its own entry. Fixing those checks is an investment that may reduce future manual work. Counting the repair itself as waste would make the team look worse while it addresses the cause.

Keep waiting visible too. A ticket held up by an unanswered product question needs a different intervention from one held up by a broken billing test. Ticket timestamps show elapsed time; they don’t tell you how much engineering effort a dependency consumed. Use the engineer’s account alongside the work record, and keep estimates and disputed attributions marked as such.

If your team consistently labels commits fix and feat, their ratio can help you choose where to look. It counts commits, though, with no allowance for their size or cause. A burst of fixes might be repair work finally getting done. Feature commits can contain workarounds that leave the debt in place. Inspect the work behind the labels before drawing a conclusion.

Choose a repair against work you expect to do

Martin Fowler makes a useful limit explicit: design-related interest is incurred when you need to work in the affected code. An unpleasant but stable component can be cheaper to leave alone. The delivery-speed argument for repairing it grows stronger when planned changes repeatedly cross it. Security and reliability risks can still justify work on unchanged code; those need their own assessment.

For the pricing flow, that means identifying which planned changes would require the same investigation. If false alarms are the obstacle, restoring trustworthy billing checks may be enough. If presentation changes keep disturbing payment behavior, separating those responsibilities may address a deeper dependency. The displayed and charged amounts still need to follow the same pricing rules; duplicating those rules would create another way for the amounts to disagree.

Trustworthy checks have a burden of proof too. In this example, they must verify the relevant charge and reject an incorrect result before they can replace manual investigation. If the only way to get a green suite is to stop checking the disputed charge, manual verification is still necessary.

Include the cost of checking and releasing the repair, along with any migration it requires. For the same planned changes, compare the recurring extra effort without a repair against the repair cost plus the extra effort that remains afterward. A repaired test suite still needs maintenance, and a cleaner design still needs verification. Keep the feature scope and standard of correctness the same on both sides.

Fowler also warns that estimates of feature work, cleanup, and the hypothetical cleaner system are uncertain. A comparison tied to actual upcoming changes is easier to challenge than a return calculated over an imagined stream of future features. When a repair needs speculative future work to break even, keeping the current implementation can be the more economical choice. The value of displaced product work and the risk of changing billing also belong in the decision.

Your existing technical lead can make this comparison with the engineers who know the affected system. If you choose the repair, give it an owner, reserve capacity for it, and agree which repeated step it is meant to remove. Hiring may still be justified for additional work or missing expertise. A new engineer assigned to the same fragile pricing flow will also need a safe way to change it.

Keep recovered capacity separate from cash savings. Salaries remain payable after a refactor; the benefit is time available for other work, if the repair actually frees it. A forecast that multiplies a guessed debt percentage by the salary bill, then calls the result savings, has left both the repair cost and that condition out.

When the next comparable pricing change ships, record which manual steps disappeared and which remain. Check that the remaining verification still establishes the right charge; a smaller ticket or less scrutiny can also make the work look faster. If the same investigation is still necessary, keep its cost in the plan.