Technical Debtees
‘If you have no intention of paying back Technical Debt, it’s not a debt; it’s a decision to cut corners’
Technical Debt. A worry for some, a means to an end for others. The battleground on which the war between short-term and long-term benefit is fought.
It’s a phrase used universally across the tech industry, and a concept that has a place in even the healthiest code bases, but there’s one question I find is consistently missed:
Who Owns the Debt?
What makes a Debt
The core components of a debt are always the same, regardless of the type of debt:
- The Debtor: The person/body that has incurred the debt.
- The Debtee: The person/body that is owed the debt.
- The Debt: The thing which has been deferred that is owed to the Debtee by the Debtor.
For example, in a Mortgage, the Debtor is the person buying the house, the Debtee is the Mortgage Provider (Bank/Building Society/etc.), and the Debt is the deferred repayment of the money loaned to the Debtor to the Debtee.
This might seem like a roundabout way of saying “It’s the money loaned to the Debtor”, but there is a reason for this: that definition only makes sense when something tangible is loaned; it doesn’t make sense in all Debt situations.
Take Technical Debt for instance. What’s actually being loaned here isn’t a tangible thing. When we incur Technical Debt, what that means in practice is: “We are deferring the ‘Proper’ implementation of this thing in order to be able to deliver it in a shorter timeframe”. We’re not loaning anything; we’re agreeing not to do something in order to satisfy other requirements. This provides us with a good definition of Technical Debt:
Now that we have a definition, we can determine the Debtor and the Debtee. The thing being “loaned” is good practice/quality, which is the remit of the Engineers doing the work. Like the Bank owns the money in Financial Debt, the Engineers own how the work is delivered; they are the Debtees. The Debtors are the group asking for other things to be prioritised over good practice.
This, for me, was a significant shift in perspective on who is responsible for repaying Technical Debt. In the past, I have reasoned with frustrated team members, saying we needed to make the business case for the Technical Debt so that it could be justifiably prioritised on the backlog. But the bank doesn’t have to justify to its debtors why they need to pay back their loan! Instead, they arrange up front how the debt is to be repaid.
Repayment Plans
So what does a repayment plan look like for Technical Debt? The subject of the debt is Time - time to deliver the solution that wasn’t possible the first time round - so it is time that needs to be repaid. Instead of having to argue later about why repaying the debt should be prioritised, agree up front when the team will be repaid the time.
This doesn’t have to be immediate; depending on the reason for the Technical Debt, it might be some time before there is scope to repay the time without defeating the point of incurring the debt in the first place. That said, it should still be agreed - the sprint after the delivery date, for instance - and the longer it is before the debt is repaid, the greater the amount of time needed to repay the debt, to account for the difficulty of unpicking old Technical Debt. This is in practice is the “Interest” of Technical Debt.
Bad Debt
‘If you don’t think they’re going to pay you back the time, don’t agree to a Technical Debt.’
Of course, this is all a lot easier to say than it is to practice. There are a number of ways in which the best plans go awry, in particular:
- The Debtor refuses to agree to a repayment plan
- The Debtor agrees to a plan, but then reneges on the agreement
These mean that sometimes, you can end up in a Bad Debt situation - The Debtor cannot provide a guarantee to back their loan, or fails to make the payment(s) at the appropriate time(s). In Financial Debt, this has an impact on your Credit Score, meaning that further loans have much stricter terms, or may not be given at all. The same can be applied to Technical Debt - if the repayment of time to deal with Technical Debt is not being taken seriously, then it is an entirely reasonable action to refuse to loan more Technical Debt until the existing debt is dealt with.
It should be noted that while the Debtor is responsible for planning the repaid time into backlog prioritisation, the Engineering team is still responsible for ensuring that they don’t allow an obvious Bad Debt to occur; if you don’t think they’re going to pay you back the time, don’t agree to a Technical Debt.
There will be times when this isn’t a battle you can win; there will be people who don’t see the importance of dealing with the debt. All you can do in that situation is make it very clear that this isn’t Technical Debt. If you have no intention of paying back Technical Debt, it’s not a debt; it’s a decision to cut corners.
So what does this all mean?
If you engage in Technical Debt:
- You are the Debtee - if the value of the debt isn’t worth the impact of the debt, then don’t agree to it.
- Set your repayment plan up front.
- Track when the debt is due to be repaid, and ensure it is.
- If it isn’t, raise your concessions for the next piece of technical debt:
- Insist on a shorter deadline for dealing with the debt, or
- Insist on regular dedicated time for dealing with Technical Debt
- If all else fails and you aren’t being given the time back, make it clear that the business is making a decision to lower quality and maintainability.
At best, the above should help you plan managing your Technical Debt into your backlog, and ensure it gets done at an agreed time. At worst, it will at least make visible to the organisation that an implicit decision to cut corners and jeopardise quality is being made regularly.
I will reiterate that there is good Technical Debt out there, and a debt given with clear repayment deadlines that are met will help an organisation massively. Just remember: it’s not your job to find the time to repay the debt. Be the Debtee, not the Debtor!