Technical debt is a common worry amongst development teams. A long method, a near-duplicate web service, an old bit of tech stack. Our collective experience tells us that technical debt is bad, something to be avoided. Clean Code tells us how to avoid it and Joel Spolsky tells us never to rewrite because of it.

The whole of our collective experience drives us towards a bit of a dichotomy, a line in the sand that divides all parties into two groups. There are the intrepid software developers who see all technical debt as an intrinsic evil to be eradicated and avoided at all costs. The more business-oriented parties see efforts to remove technical debt as a sort of unnecessary geek gold plating that distracts from delivering on more important tasks.

One speaker I remember hearing proposed to bridge the gap by looking at technical debt as a form of risk to be managed. The rationale was that debt is not regarded as intrinsically bad in the business world. In fact, it is a necessity and excess liquid assets are even considered bad for the overall financial health of a company. If, however, we re-frame technical debt as risk the picture becomes clearer. There are risks, to be sure. Risk that support will falter, risk that security will be breached, risk that code will not be extensible in ways that are found to be desirable and so on.

Discussing the risk associated with technical debt is a good thing. The severity of risk is a strong factor in the importance of resolving any form of technical debt. I think a blanket relabeling of technical debt as technical risk would be doing ourselves a disservice.

A blanket relabeling would only be kicking the can down the road for a few years. At some point the message backing technical risk would become stale as the stated risks never seem to quite materialize. Then there is the fact that it would be almost laughable to refer to some of these things as a risk. How much of a risk is a method that is just a little too long?

I find the concept of technical debt is useful because debt is a form of risk, even in the financial world. The key, I think, is to place our handling of technical debt on a rational basis, almost like a balance sheet of some kind. If we can minimize the amount of emotion from the equation, we can have a much better conversation about how to deal with the debt on our code base.

At the end of the day, not all technical debt is created equal any more than all financial debt. It comes down to a cost/benefit analysis. For example, let us say that we are faced with putting some hacks into a product in order to make a deadline. The software developer would recoil a bit. Mar the code to make an arbitrary date? Irresponsible. Poor craftsmanship. An efficiency minded individual sees double work, first now and then later - and recoils as well.

Financial debt is (virtually) never interest free, so it costs more to pay for something through debt than if it were all paid in cash upfront. Nonetheless, it sometimes does make sense to take on that overall spend to have something sooner. Done right, this is due to opportunity cost. The extra effort paid to settle the debt amounts to less over all than the opportunity that would be lost if we had to wait. Software development is much the same. It might well make sense to take on the technical debt if, by doing so, we net an amount of opportunity (otherwise to be lost) that exceeds the full cost of effort.

In the example of trying to make a date we would need to ask whether making the date generates enough opportunity to be worth the effort of removing the hacks. This approach assumes, of course, that the payment of technical debt is non-optional. That payment is mandatory is what makes financial stewards weigh debt in a non-flippant fashion. It seems like there is an opportunity to mix the payment of technical debt into agile planning, ideally by making payments - that is, dedicating a portion of each sprint’s story points to resolving technical debt.

It also relies on the ability to quantify our technical debt which is something I don’t think we have a great handle on, as an industry. I think, if we can make all this happen - quantifying our debt and associated risk, making payments on our debt and discussing a “balance” with our stakeholders - we can make decisions about technical debt that are in the long-term best interests of all.