Technical debt is one of the heavily used terms by developers, product managers, and all the tech people. But what does it really mean? And why? And is it really so bad for your project, product – or worse – the whole company?
The term technical debt was coined by Ward Cunningham, a renowned American programmer, who developed the first wiki, back in 1994. What’s more important for us, he’s also one of the authors of the Agile Manifesto.
Cunningham compared some problems with code to monetary debt. Going into technical debt means borrowing against the future. What you borrow is work you don’t have to do now. For example, because you’ve decided to take a shortcut. This is your principal. But there is also interest – it’s a cost of additional rework caused by choosing that shortcut. And as with a cash loan, if you don’t pay it back on time, the interest will accumulate. The problem is that the interest gets accrued exponentially. And there is no market regulator who will limit its rate.
Tech debt is like a serious disease. The one that is hard to diagnose – you may not even know that you are in debt until it’s… well let’s hope it’s not too late. However, tech debt can kill you – if not in short term, then probably over a longer period. It is also difficult to cure. Luckily, not impossible. But we will get to the strategies on dealing with technical debt later.
Why does it occur?
Interestingly, technical debt may be intentional or unintentional. If it’s the former, you probably know what you are dealing with and know that you do all of it at your own risk. The reasons can be various. You may be developing an MVP for your product, want to deliver it quickly, test on the market and if you succeed – secure funding and proceed with development. You know the stakes. And as long as you calculate it and promptly repay, it is all right.
Make it right. Be like a Lannister and always repay your debts.
Unintentional debt, on the other hand, is much worse, since you won’t always see it coming. And we will focus on that. There are several reasons for technical debt to be incurred.
To begin with, there is business stakeholder pressure. And senior management that might not necessarily understand that their ideas need to be coded. And that there is a subtle difference between PowerPoint slides, design mockups, and the actual code.
Then there are incompetent developers and architects who make decisions about implementations. The ones who can’t say no, use the wrong approach, or can’t plan their work ahead which ends up in a mess and last-minute hotfixes and hacks. Their decisions might lead to a debt – even if it’s delayed in months. You may think that poorly planned testing of your software won’t lead to anything near the Chernobyl disaster, but then think again. And think about where your software will be implemented, who will use it, and what are the potential outcomes of its failure.
If you are a non-technical founder, it is always good to bounce your ideas off experts and peers you trust.
The key to managing technical debt is awareness. There are some tools that will help you see how much your project is indebted.
Teams can look at the code complexity. It is a quantitative measure of the number of linear-independent paths through a program’s source code. If the code is complex and poorly documented, onboarding new people will for sure be a challenge.
Another good indicator of growing debt is a big turnover of developers or vendors working on code. Imagine a book written by multiple authors. Everyone has a different standard and style. And they usually disagree with each other.
The great source of feedback and the indicator that helps you set your priorities are the users. You know almost instantly what should be fixed next as you receive multiple complaints. Developers are often away from market reality.
Last, but not least, there is Velocity Chart, used in the scrum framework (the one used here, at bPol). It shows the value delivered in each sprint and therefore helps predict the amount of work the team can get done in future sprints. It also tells you how much effort the developers are putting into actually developing the product, and how much into dealing with the debt. For example – let’s say we know there are 10 new features to build in the backlog. But there are also 10 bugs waiting to be fixed. The speed of development will obviously decrease.
Ok, but how to avoid it?
While the debt that has been already taken out has to be paid, you can be smarter next time and avoid falling into it again. How? There are various strategies you can implement. We’ve listed the top 14 of them. Feel free to use them to your benefit.
Wondering whether you are faced with technical debt? Let's jump on a call and discuss!
