Debt. Urgh, it’s everywhere, and it’s not just lingering in our bank accounts, it’s in our code too. Unlike it’s monetary counterpart, tech debt doesn’t have to be soul-destroying. Let’s talk about technical debt; what it is, how we can track it, and ultimately, how we can pay it off.
What is Technical Debt?
Tech debt is a side-effect of taking short-cuts during development. It’s what we get when we choose to deliver as fast as possible without investing time in the cleanliness and overall design of a codebase. With technical debt, the debt isn’t directly financial, it’s temporal. You owe time. I say that the debt isn’t directly financial because you don’t owe a creditor, but you do need to invest time again in the future to keep the codebase alive, and that ultimately does have a financial impact, so I think it’s fair to equate tech-debt with an indirect financial cost in the future.
Tech debt’s definition is perhaps best summarised by the developer Ward Cunningham, who first coined the term:
With borrowed money you can do something sooner than you might otherwise, but then until you pay back that money you’ll be paying interest.
I thought borrowing money was a good idea, I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.Ward Cunningham
It’s kind of like spending more money upfront on a higher quality product, than quickly grabbing the cheapest product we can find. We aim to reduce the overall investment by investing more heavily in higher quality at the beginning. We do this by spending more time at the beginning of our project thinking about the longer term by answering questions like:
- What architectural pattern should we adopt?
- How will this code evolve over time?
- Where and how can we apply SOLID principles?
- What support points will be required?
It’s easy to argue that this would be adding time for ‘time’s sake,’ but the goal here isn’t to prolong a project, it’s in fact to decrease the overall time spent not only on the development of a project, but it’s maintenance also.
Consequences of Ignoring Tech Debt
It’s unwise to pay too much, but it’s worse to pay too little. WhenJohn Ruskin
you pay too much, you lose a little money – that’s all. When you pay
too little, you sometimes lose everything, because the thing you
bought was incapable of doing the thing it was bought to do
In other words, buy cheap, buy twice.
It may be a cliché, but if it is, it’s a cliché for a reason. Think about it. You’re chasing a new market, but you’re not spending the time to get the level of investment you need to get the resources you’d like, so you sequester the first people available (at perhaps the cheapest price) and then you get them to throw together your hot new app as quickly as possible.
‘Let’s just get it out there ASAP‘ is your start-up’s development philosophy.
Now, this is an extreme example, but the result is the same. Yes, you may get your app out there, and yes it may be received really well, but what happens now that you need to scale? How do you scale out a system that:
- Has no consistent architecture
- Hasn’t been reviewed for potential bottlenecks
- Isn’t documented
- May no longer have the same developers available
Of course, scaling an app like this isn’t impossible, it’s just going to take a whole lot longer than if the above items were available. That longer time to scale is the price you’re going to have to pay. It’s the debt that was created during development, that you now need to pay off
Does that mean that if you take the extra time to put a great design in place, with fantastic documentation and performance considerations, you’ll have no technical debt? In short, no.
Technical debt is inevitable at some point. However, the amount of debt accrued can be mitigated by good design and development practices. Avoiding technical debt is a whole other blog post, but what I want to focus on is how you manage your tech debt.
Before you can do anything about the debt though, you’ve got to be able to easily identify it.
Identifying Tech Debt
Actions you can take today
- Create work Item in your issue tracking software, dedicated to tech debt – If you don’t have issue tracking software like GitHub Issues, Azure DevOps, Jira etc, then you have other problems. But just as you create a ‘Bug’ item when you find a bug, allow your developers to create a ‘Technical Debt’ item when they find incurred debt, or better yet, when you decide you may need to incur some debt. The work item should include detail about the debt incurred, why it’s being incurred and a suggestion as to how it can be paid off.
- Technical leaders, make it safe for developers to raise the alarm – Some developers may feel a little self-conscious or nervous about blowing the whistle on tech debt. Maybe if they’ve had to incur it, they’re worried they might be singled out or if they’ve seen it someone else’s code, they me be concerned about offending people. Make it clear that identifying defects of any kind is not a personal issue. Take the emotion out of it and encourage them to be vigilant.
- Dashboards – Just as you should for any high-severity bugs, make metrics related to technical debt a key feature within your reporting dashboards, keeping the debt visible.
- Sprint Planning Sessions – When you’re reviewing User Stories and other newly created work items, make sure you always ask the question ‘is any technical debt being incurred here?’
Managing Tech Debt
Actions you can take today
- Agree a ‘payment date’ for each debt item – Add some pressure to pay off the debt with a provisional ‘payment date.’ You’re more likely to deliver if you have the pressure of a deadline.
- Educate stakeholders – You may get some resistance from stakeholders when you tell them you need to spend time ‘paying off technical debt,’ especially if they don’t understand the concept. Help them understand what technical debt is to reduce their level of resistance.
- Improve overall knowledge of architectural and design patterns – There’s a lot of debate around which architectural or design patterns should be used for specific use-cases. I would argue that as long as your team has an agreed pattern of some sort, you’re minimising the risk or incurring technical debt through consistency
- Celebrate paying off the debt – Paying off technical debt should feature as a point of celebration during sprint retrospectives. It help to maintains an anti-tech debt culture and just generally makes people feel positive.
Tech debt is a widely discussed software development concept, and there are people out there who’ve gone into way more detail than me on the subject, so check them out if you want a deeper dive.