Technical Debt As Debt

Bad Debt by Nick Youngson CC BY-SA 3.0 Pix4Free.org

When technical debt is raised within an organisation, it is sometimes brushed off as being little more than the desire of prima donna developers to spend time polishing and reorganising code for purist reasons rather than any practical benefit, but I would argue that to be so dismissive could be a costly mistake. Good software engineers are as conscious of the financial realities of their workplaces as anyone else, and the term "technical debt" is actually an accurate description of the nature of the trade-offs that are made during development - and the risks that come with them.

The same set of questions that might apply to a loan in the traditional sense could also be asked by a prudent team or organisation deciding whether to incur a particular technical debt - with this in mind, here are some parallels to consider.

1. What are you borrowing for?

All but the richest of us would need to take out a mortgage to buy a home, and in many countries, would need to take out sizeable loans to pay for higher education. A majority of people would likely consider these to be worthy reasons to apply for credit, but would regard borrowing the same for a holiday, a piece of jewellery, or some designer clothes to be unwise. In software, the thought process should be no different - is the debt-producing work in question intended to address a considered investment, a real need, or a mere want?

2. How much are you borrowing?

In money terms, this is a straightforward one - the currency value of the loan. The parallel in code would be asking the size and nature of the compromise being made between the ideal solution and the solution about to be implemented. This definitely isn't just a matter of the number of lines of code, but a question of the pervasiveness, permanence, and external visibility of the changes.

3. What's the interest rate?

I think the best way to think about this in development terms is "how much more difficult (and expensive) does it get to move back towards a better design/implementation as time moves on?" The ideal would be a "zero interest" loan where the amount of work needed to repay the debt would be identical regardless of when it gets done, but a much more common situation could be something like making a sub-optimal change to the main data schema for your system in order to hurriedly introduce a new feature. As time goes on and more data is created, and/or the new schema becomes relied on by more components, moving to a better representation becomes a riskier and more time-consuming prospect. This is especially so if the system in question is one that has no scope for downtime, or if the change involves the interface being provided to external entities.

4. What is your ability to pay the debt back?

If you happen to know that you have a long period with reduced workload coming up, or an increase in staffing, you're likely to be in a much better position to pay off any technical debt incurred than if you're constantly running at capacity with no end in sight. As more and more requirements for new work land, those TODOs and tech debt backlog items will tend to be pushed down the priority order, leading to the once-temporary changes solidifying as accepted parts of the codebase and architecture.

5. What are the consequences for late or non-payment?

Hopefully the analogy is holding so far! This point is related to, but subtly different from the "interest rate" factor. If we assume that we've borrowed a manageable amount with a reasonable repayment plan, what happens if something upends that plan and you can't sort it out on schedule?

Failing to repay borrowed money on time can, depending on the lender, have consequences ranging from damaged relationships at best through to legal action, or even, sadly, risks to personal safety. For the specific type of technical debt incurred, think about what an inability to address it on schedule could mean - it may just be an annoyance, or at worst, critically damaging to the quality and maintainability of your system. You should also bear in mind that codebases that are difficult to work with can in time have negative effects on the morale and even the retention of the staff needed to maintain and further develop them.

Conclusion

It seems blindingly obvious to say, but is often forgotten - development time costs actual money. This is where the two concepts of debt overlap most strongly; almost without exception, taking out technical debt is literally borrowing money from the present (by taking a shorter and initially cheaper development path for a given feature) and then creating a need to repay that later on (with a costlier reworking of the now-existing functionality into a more maintainable form). It is all too easy for today's "just do it" task to become tomorrow's eye-wateringly expensive constraint on maintainability and further product development, especially if there are competing commercial priorities. This is where organisational culture plays a crucial role; the more everyone sees the overall picture rather than their own specific interests and targets, the more all the important factors can be balanced in decision-making.