Four stages of technical investment

Technical debt is a perennial topic of conversation in any software development project. Regardless of how it’s defined (a long discussion in itself), it’s often seen as a “problem” to be “solved,” implicit in suggestions for dedicated sprints devoted to paying down technical debt.

The larger issue is software quality, whether the software is delivering the right value to the right customers, in a timely manner. Specifically, timely delivery is slowed by poor quality software which has cycles of rework preceding correct delivery.

A slightly different way to approach the challenge of software quality is focusing the conversation on technical investment rather than technical debt. This notion promotes quality-as-a-process, and allows breaking that process down into four stages:

  1. Slow the bleeding. First, ensure the rate of compounding debt decreases because “the worse it gets the worse it gets.” Slowing the bleeding means decreasing this rate at which technical debt is shipped.

  2. Stop the bleeding. In this stage, technical debt is not getting paid down much, but neither is it getting worse. Getting here is difficult and a significant win for most shops. This is the result of process changes executed in Stage 1.

  3. Restore to health. best practice is SOP in all aspects of product development both engineering and product management, with active effort investing in substandard components. Compounding effects of best practice: the better it gets the better it gets.

  4. Improve on best practice. set industry-applicable patterns built on industry-accepted best practice. Better than best should be mostly a superset of best, breaking existing rules in favor of better rules, and adding guidelines where none previously existed.

These four stages need not be mutually exclusive, and may be pursued out of order. Stable and slowly evolving parts of a code base may be less than optimal, and that might be just fine in a “don’t fix what ain’t broke” fashion.