Is Technical Debt Really A Technical Problem?
I often hear the term “tech debt” kicked around but I don’t think it’s well understood.
What is tech debt?
Ward Cunningham created the metaphor to help explain the process of delivering early which leads to the need to go back and “finish” the product. In general, tech debt comes from releasing a product before it is completely done – it’s the gap between what’s done and what needs to be done. That gap should be visible and understood by the dev team and the Product Owner. In fact, the team & PO should agree that there is tech debt before deciding to release; some gaps will be acceptable and some won’t.
What tech debt isn’t
Tech debt isn’t an excuse to write bad code. It may be incomplete because there are parts of the puzzle that are lower priority, e.g. it’s more important to get feedback on the high priority parts first. It may be that parts of the Definition of Done aren’t finished because you’re going to sit with some early-release users to observe them using it so documentation can wait, for example. But poorly written code is just that: bad code, not tech debt.
Accruing interest
One of the reasons that debt is a good metaphor is the concept of interest – the longer you have debt, the more interest you accrue and the longer it takes to pay off. With software development, the longer you leave a product “in debt” the harder it is to build on top of it.
If, for example, there are no automated tests then changes to that piece of code become riskier because you can’t easily check for unintentional consequences (aka bugs). If you now decide to write automated tests for this subsequent change, then it will take longer (cost more) because you’re starting from scratch rather than adding to existing tests.
Good and bad debt
The debt metaphor continues to work when thinking about when to incur it: there are times when it can make sense to incur debt, e.g. buying a house. An important part of intentionally incurring debt is having a plan for paying off the debt.
Deliberating incurring tech debt is often driven by deadlines, or at least the pressing need to “ship now and deal with the consequences later”. This tends to come from (or, at least, through) the PO so the cost should be obvious. The team should ensure the PO knows what is outstanding and therefore an informed decision, weighing up costs and benefits, can be made. The absence of that shared knowledge and conscious decision-making leads to surprises and mistrust; remember that the Definition of Done is an agreement between the team and PO – it’s a common understanding of what “done” means, so it’s important to be clear when a release is falling short of that bar.
Have a plan
An important, and often overlooked, part of responsibly incurring debt is having a plan to resolve it. It’s all too common for tech debt to be forgotten or ignored, but pretending it doesn’t exist won’t make it go away. If it’s important to release something now, before it’s finished, then make sure the tech debt items are identified and added to the backlog … but then also agree when they will be addressed.
Of course plans can change, but start with a target and ideally that’s as soon as possible, while the context is still fresh in everyone’s minds. The plan could also be that some items will not be done; my preference would be to have those items in the backlog and then mark them as “Won’t Do” (or whatever the equivalent is for your situation) so there’s a reminder of that decision. (This isn’t for any “blame” – it’s so I don’t forget and later end up wondering why things aren’t done.)
Review your tech debt
I don’t mean review the backlog items representing your tech debt; I mean think about the cause(s) of your debt. Include tech debt in retrospectives or continuous improvement discussions: what led to incurring the debt and was it avoidable. For example, could the scope have been reduced so that the team could have fully completed something smaller rather than 90% finishing it all?
As part of reviewing what led to the tech debt, it’s also useful to identify any patterns in which items are incomplete, i.e. are the same corners being cut on a regular basis? If so, should we just remove them from the DoD and then add what’s needed for specific features.
Is tech debt a technical problem?
If you’re wondering “Who ‘owns’ tech debt?” then I believe it is the responsibility of both the dev team and PO – there should be a shared need to minimise tech debt, both accruing new debt and paying off existing debt. The are many reasons why, amongst them: the health of the product, the wellbeing of the team, and the speed of future development.
I’ve seen some teams have a formal 80:20 split of time in a sprint, trying to balance “product work” and “technical work” (I’m not a fan of this approach but I’ll save that for another post) so they might wonder whose time does tackling tech debt fall into? Well, if there was no tech debt that would mean the product work was completed as per the DoD, and therefore that was all done in product time. So if there is tech debt, that means some of the product work was not completed, and therefore when tackling the tech debt it should be seen as product work, the same as it would have been in the first instance. Personally, I would prefer to call it product debt because that’s what it is, a deficiency in the product, but the tech debt term is ubiquitous … and I’d rather put effort into reducing it rather than renaming it.
Conclusion
Incurring technical debt is not necessarily a bad thing – there are times when making an informed decision to take on tech debt is the right decision … but there needs to be a plan to pay off that debt. Ignoring tech debt won’t make it disappear and eventually you’ll have to declare bankruptcy, i.e. the software has so much debt associated with it that the only way forward is to wipe it out and start again. Few organisations can afford to do that, so Product Owners need to prioritise tackling tech debt as well feature development.
Resources: