Leveraging technical debt

There are a few basic principles I have followed both with my own development teams and with those I’ve advised over the years. A few days ago I posted one of these, and it sparked a nice conversation on LinkedIn:

You should go read the conversation, because there are some very good examples of how to deal with technical debt. However, I’ll use this post to expand the basic thought a bit.

To many, financial debt is something to avoid, but to others, it’s a tool for enabling activities that would otherwise be out of reach. Accelerating and leveraging investments, enabling to build and develop things for which capital isn’t yet available, and so forth. Of course, taking on and managing debt requires planning and discipline. Running a massive credit card balance or taking on high-interest payday loans isn’t a viable long-term strategy, although even those tools can be useful in a pinch. A mortgage on the other hand usually is a valuable long term tool, and a revolving credit facility on the other hand provides a business similar benefits a short-term credit card balance provides to an individual: liquid funds to ease cash flow management.

But what does all of this have to do with technical debt? Well, if you go to Wikipedia to learn about technical debt, you could easily come away thinking it’s a terrible thing to avoid at all costs or get rid of as soon as possible. But actually, that’s not the case at all.

Technical debt is a tool to enable delivering a product earlier than it could be done without taking the debt. You could decide to cut an important but non-urgent feature from the delivery scope to return to implement it post-launch. You could judge that polishing a side-path of your user acquisition funnel isn’t worth the effort before you have more visitors going through the main path. Or, you could decide to skip some testing and deliver a product which doesn’t reach important quality objectives. Can you tell which of these is prudent product management and which is cutting corners, about to bite your hand any day now? Of course you can. They’re all debt, though.

In the real world of limited budgets, restricted time and pressure to deliver, it is impossible to not incur technical debt. The only questions are where it happens and is it a conscious decision, or something that just happens to you, to only realize later you have a high-interest debt weighing down your assets and costing your team valuable time.

Ah, yes, interest. Although software, unlike money, does go through bit rot, turning even good code first to legacy and then to technical debt over time, it’s not really accurate to say that interest on technical debt directly causes increase on the “capital” of that debt — technical debt does have its differences compared to financial debt. Interest on technical debt is results lost due to the friction caused by the debt, or time spent dealing with the debt in increased maintenance. The latter of course does lead to lack of time to build something else, and an increase of total debt. The similarity is close enough, though: maintaining a balance of high-interest technical debt ends up costing a lot of engineering time, and time is money. You need to understand where that cost is, and address it at the source as quickly as you can.

There are several ways to address technical debt, too. My own go-to tool is to treat it similar to how the Five Whys incident management technique works: with an iterative, proportional investment tactic on every level of debt management. For most kinds of technical debt, that will mean continuous, minor improvements or refactoring to each layer of the debt: from problem resolution to process development to make the costs of the debt both lower and less frequent. I favor this approach over large-scale rebuilds because my experience is that on a very fundamental level, even in an established business, it’s very hard to know what future needs will evolve. Building “debt-free” software would require both prescience of future needs and unlimited, or at least unrealistically large budgets of both time and staff.

Sometimes it is possible to take another path, though. Most of these situations will be of the known-problem, known-solution type, things for which the issue is purely technical and well-specified, and it’s just a matter of spending the engineering time to fix it. Insourcing a formerly outsourced but expensive business process could be such a situation. Building a new implementation of a component, once the requirements have been fleshed out and the costs of maintaining the initial Minimum Viable solution are determined too high is another example. Teemu Kurppa gave a great example of the latter in the LinkedIn conversation.

Bottom line: Technical debt is a valuable product management tool, the same way financial debt is a tool for a your financial team. Product managers need to know how to apply it. Just don’t make a habit of collecting the high-interest kind.

What do you think? I’d love to have a conversation on this or any other product management related topic!