Debt in all forms is becoming a big deal

“Chains of technical debt are too light to be felt until they are too heavy to be broken.” (lightly adapted from Warren Buffett).

The insidious nature of technical / process / automation debt is that it isn’t a problem until it is, and then it’s a Big Deal. The tweet below triggered the reason to write this blog post:

The friction generated by debt is capable of stopping all forward progress.  Even when it’s only incremental friction, the fact that it exists at all means that we’re not able to move as quickly / innovate as much / optimize the cost of delivery, all because we have to account for the tangible slowdowns caused by debt.   What’s worse is that it is compound debt. Compound interest is great, compounding debt is completely not great.

What do I mean by ‘compound debt’?

Imagine you own a product or service, and it’s built on top of an operating system that’s in a virtual machine. The operating system is getting long in the tooth: it’s not End of Life yet, but it’s certainly not getting the attention that it used to. But it’s expensive (in a lot of ways) to address it, so you just let it go. Keep sustaining it, but kicking the can of upgrades down the road. Not so bad, eh? Until the agents that you need to use to backup / monitor / automate / sustain the service are no longer supported on that operating system because their support matrices are more aggressive that the OS vendor. Now you can live with this for a while, but soon you start hearing from the support team of the agent that “we really need to be upgrading that OS to something that’s supported (by us)”.

Debt is starting to compound because of a single set of investment decisions (or non-decisions). Pretty soon, you’ve got a museum piece at the center of a web of back-revved supporting structures, or it’s a black hole that has limited visibility / support.  The cost of addressing this is going to be much larger than what you could have spent: thus, compound debt.

Automation debt?

Automation is not immune to debt. There’s a temptation to view automation as a fire-and-forget activity: once I’ve automated it, there’s nothing else to do. That simply is not the case: automation exists in an ecosystem itself, and invariably, a part of that ecosystem is going to change and require updates / upgrades / new capabilities to support the new or changed ecosystem.  Put more simply: your automation initiatives have to be sustained in similar ways to your software development processes, so make sure that automation debt is a topic that you’re tracking, visualizing and addressing.

So what to do about it?

Unfocus your eyes a little and think about what not addressing a known piece of debt could stop you doing, or more pointedly, what the downstream effects of having to deal with that debt will cause. The example above means that short term, you have to repeatedly explain why you’re not addressing the root cause of technical debt. Put another way? You’re going to waste a lot of time and energy justifying why technical debt has been incurred. Longer-term, more and more cost is baked into the updating of your asset and all the other supporting assets as delayed currency remains delayed.

Invest incrementally to reduce where you can. That can be as simple as currency activities, but the important thing is that you are working on it consistently. Bake currency into your product or service plan so that it remains an activity that you have eyes on.

Make it visible! FIXMEs or comments about how we need to not lose sight of the debt help, even though they may feel like not doing much at all. Introduce and keep debt items in your backlog, and use any opportunity to implement debt reduction.