I’ve talked previously about technical debt. Should we stop other work to address it? What is the cost of delay? And that we should watch out for technical bankruptcy. But these are “stop the world” questions. What proportion of our time should we be spending on it on a regular basis? Is 5% too little? 10%, 15%…?

One obvious way to assess this is to introduce a Plan Do Study Act (PDSA) feedback loop—plan the work, do the work, study the results, and finally act to make any changes in our approach (presumably increasing or decreasing our time). Then we go through the sequence again, and continue to ensure we are always optimising and adjusting.

But we still need to pick a starting point. We could go by gut feel. Another approach is to consider how much we’re compromising our technology in the usual course of our work.

If our projects regularly come in on time, without compromises, then we should expect our tech debt to be pretty minimal. Any tech debt we do have will be the result of unforseen consequences (a later understanding of what is more or less important to our system) rather than known compromises at the time.

But if our projects regularly run over, and we’re rushing to finish them off, then it’s likely we know that we’re compromising our code as we go. If we regularly would have liked an extra 10% of time on our projects then we can probably say we’d like most of that time back to address the debt. If we think we regularly underestimate by, or need, 50% more time then we’re likely building up much bigger debt that needs more time to be addressed. In fact it’s really worse than that because tech debt gets more difficult to address the longer we leave it.

The most reliable approach, in this and other matters, is usually PDSA. But we can use a little bit of on-the-ground intelligence to pick a good starting point.

Photo by Martin Clifton