Technical Debt as a Rework Multiplier

Higher defect density

Code with high technical debt has more defects per 1,000 lines (higher defect density) because it is harder to understand, harder to modify safely, and more likely to have missing or inadequate tests. More defects means more rework events.

Slower diagnosis

When a bug is found in high-debt code, diagnosing the root cause takes longer because the code is harder to follow. What takes 30 minutes to diagnose in clean code takes 3 hours in debt-heavy code. The diagnostic overhead is rework cost even when the bug itself is small.

Higher regression risk

Modifying high-debt code to fix one bug frequently introduces another. Tightly coupled, poorly tested code creates blast radius: a change in one place breaks behaviour in another. Each regression is an additional rework event.

Longer code review

Reviewers spend more time on high-debt code because it is harder to understand what the change does and what it might break. Longer reviews increase the time between PR creation and merge -- extending the feedback cycle and increasing the probability of merge conflicts that generate additional rework.

Implementation risk premium

Engineers working in high-debt code add time buffers to their estimates because they know the code will surprise them. These buffers are often consumed by rework. Teams that track time-to-implement vs. estimate accuracy find that high-debt areas consistently overrun estimates.

The 15-20% Sprint Rule

Reserve 15-20% of every sprint for planned tech debt paydown. Non-negotiable. This is the most consistently cited recommendation across engineering blogs, management research, and engineering economics. Less than 15% and debt tends to grow faster than it is reduced. More than 20% and product velocity suffers to the point where it creates pressure to skip paydown entirely.

The Boy Scout Rule

Leave every file you touch slightly cleaner than you found it. Rename a confusing variable. Extract a function that is too long. Add a missing test for a path you noticed. These micro-improvements, applied consistently, prevent the accumulation that turns manageable debt into crisis debt. They are also low-risk because the changes are small and scoped.

The Tech Debt Register

A prioritised backlog of known debt items with two estimates: time to fix, and estimated cost-per-quarter of not fixing (usually expressed as additional implementation time per change touching that area). Review the register monthly. Debt items older than 6 months without a paydown plan are risks that should be escalated to engineering leadership.

The Architectural Fitness Functions

Fitness functions (from the 'Building Evolutionary Architectures' book by Ford, Parsons, and Kua) are automated checks that prevent architectural drift -- the main mechanism of inadvertent debt accumulation. Examples: a test that fails if a module has more than X dependencies, a check that fails if response time exceeds Y milliseconds, a linter that fails if a module is imported from a restricted layer.