Why Technical Debt Talk Goes Nowhere

Discussions about technical debt often spiral. Someone raises the need for a large refactor, another person points out the value of small daily improvements, and soon the conversation has expanded beyond any actionable scope. Engineering teams end up frustrated because every valid observation pulls the discussion in a different direction, and no single remedy fits all the distinct problems lumped under the "debt" label.

During a recent team discussion on remediation strategies, four distinct categories of debt emerged. Each demands a different response, a different planning horizon, and a different level of organizational support.

Rewrites Are Rarely Pure Debt

What might be called "yearly debt" is the kind that leads teams to conclude a rewrite is the only path forward. Sometimes that conclusion is correct; in other cases, a system may need methodical, piece-by-piece replacement while it continues running, according to the Ship of Theseus principle.

Often, though, this isn't debt at all. The system may be struggling not because of poor past decisions, but because the product grew or the market evolved. Treating growth pains as debt distracts from addressing the actual problem of scale. A system might also work fine for a long time without major intervention, even if it wouldn't survive at Google scale. Labeling the situation as debt wrongly implies blame when the reality may be success or changing circumstances.

Distinguishing Monthly, Weekly, and Daily Debt

Monthly debt requires several months and a dedicated team. The problem is clear, a solution is vaguely understood, and maybe a proof of concept exists. Or the team shipped something that succeeded beyond expectations and now needs to stabilize it. Realistically, the payoff can extend past a year, but the scope differs from a rewrite. Work at this level needs a case made to product or engineering leadership, along with assigned people and clear goals — or an explicit decision to accept the tradeoffs.

Weekly debt fits on a sprint board as a card or issue. A typical example: while implementing a feature, an engineer finds a cleaner approach that could also simplify adjacent code. Adding that change to the current pull request would make review unwieldy, so the work gets logged separately. The discoverer needn't be the one to do it. Leaving it unscheduled, however, creates parallel code paths and permanent complexity.

Daily debt barely qualifies as debt. It's the opportunity to improve code already being touched, such as extracting methods with clear names after struggling to understand a confusing section. These changes can take an hour or two and may ride along with the current PR. Daily debt rarely feels significant; it manifests as code that doesn't feel ergonomic, code that is simply annoying to work in.

Why Teams Skip the Small Fixes

Two factors prevent engineers from addressing debt at these scales. First, anxiety about time. Even in a healthy culture, shipping pressure exists, and calculating the right budgetary percentage is hard. Fixed numbers like five or ten percent conflate very different kinds of debt that require wildly different time commitments, and annual or monthly projects are handled differently from daily or weekly ones.

Second, tedium. Refactoring doesn't win recognition. Product launches and code deletion earn praise, but quiet improvements rarely do. Engineers without a strong sense of confidence, especially juniors, may decide the time isn't worth spending if positive effects won't be recognized.

The 25 Percent Rule

A meaningful remedy requires dedicating a quarter of engineering effort to debt in its various forms. Less than that fails to address the full spectrum. The allocation breaks down as follows:

  • Ten percent for daily debt: Four hours weekly to make code already in active work better. This time should not be treated as extra overhead. It codifies refactoring into the team's culture, so engineers feel explicitly encouraged to use it. This isn't a mandate to hunt for bad code; it empowers engineers to improve what they are already touching.
  • Ten percent for weekly debt: On an individual level, this opportunity may not surface every week, but teams should be comfortable adding such tasks to their boards. Combing the allowance across four engineers yields 16 hours, enough for one member to work a card or two over two days. Carving out this time prevents momentum-shattering context switches and allows someone else to pick up improvements.
  • Five percent for monthly and yearly debt: Two hours of weekly planning sessions go to the intellectual work of understanding known problems and priorities. This won't itself complete the project; rather, it routinizes the analysis of open systems, lets teams decide whether to tackle anything at all, and feeds agenda into existing backlog or long-term strategy meetings.

Debt Reduction Is Cultural

Repaying technical debt depends less on allocating chunks of calendar time for grand fixes than on consistently modeling good behavior in daily work. The goal is to make refactoring praiseworthy, to detect when code entropy shifts from inconvenient to obstructive, and to recognize when good enough is acceptable and when improvement is the necessary next step.