When planning or story grooming starts, developers are always making these little side comments about Technical Debt, or simply Tech Debt -- the ongoing future cost of doing a quick hack rather than building something properly. This is usually done with a kind of lament and then forgotten about again and again until it is time to abandon the development and start again.
Rather than becoming some wistful lament, I think Tech Debt is our friend. With awareness of it and a little thought, we get a powerful tool and view to help planning and simplifying product development. Read on to find out more about what we can do and grab a quick template to make it easier.
What is Tech Debt and why do I care?
Tech Debt is the ongoing future cost of building something expediently -- to do it quicker. Rather than solving a product development issue properly, we build something that is an imperfect, partial, or brittle solution. There’s an initial cost for not solving the problem properly (say, product flexibility or reliability), then ‘interest’ accrues as future development gets more difficult while working around this quick hack.
Interest accumulates over time. It compounds. So, either we fix the principal problems sometime or the interest bill gets so high we are bankrupt. This is frustrating for developers and managers alike and is the cause of much damage to morale in longer-lived projects. Eventually it becomes too much and the decision is made to start development on something new and throw the old one away. Or possibly the product is just scrapped. This is either expensive or very expensive.
What to do?
So what can I do about tech debt? Not accruing it is a good place to start. You’d need to be have perfect foresight to manage that completely, but good and careful design and experience helps a lot. People who have seen the full lifecycle of a product will get this pretty naturally.
You’ll still accrue some anyway. Just like we might take a loan sometimes, to expand a company or buy a house. The debt doesn’t have to be a problem if it is understood and managed. Managed how?
Managing Tech Debt
Make it visible -- either keep a team-wide or personal tech debt register (say, a spreadsheet) that notes down debt accrued or later discovered. This needs to be organised by component so you can quickly reference what needs reworking. Bring this along to planning and design meetings so you have the information to hand. Here's a Google Sheets template you can copy and use.
If you are going to work on some component, then it may be the time to tackle some debt. So, knowing there is some, it can be built into your estimates and work plans. You can talk about it like this: “Given we are going to have to refactor the serial interface, we ought to sort out the shortcuts in the command parser from last month”. Management has to be willing, but that’s usually easy to sort out if you’ve got a list of debt to point at.
Once you know you have a system for recording the debt and some management support to keep it in control, you can agree to pay off some debt each sprint by taking on a little extra development. This can be long term sustainable as long as the debt doesn’t accrue too high.
Relax. You know what the debt is and how to service and reduce it. Profit.
And that really covers it. Using visibility of the tech. debt (a team or personal register), and some support in resolving it, we’ve got this Tech Debt problem under control.