Technical debt is any shortcut that a team chooses to do now that will slow down future development if left undone.1 Some people prefer to tackle technical debt as they work on stories, only eliminating technical debt that will help with their story. Others will take a different approach where they tackle technical debt by scheduling periods of time where the only focus is to tackle technical debt. Dealing with technical debt is a conversation that needs to be had between software engineers and business people. I’ll give my recommendations for how to go about tackling technical debt as well as how software engineers and business people can communicate together to come up with a plan for tackling technical debt.
In this approach, we do not schedule a task for eliminating technical debt. We work on our stories just like normal but we eliminate technical debt whenever it slows down our task. Suppose there is a poorly named variable in the code called ‘aiekdj.’ Let’s even say that we are aware that this variable is in the code somewhere. If our user story we are working on has no affiliation with this variable, then we will complete our user story without having changed the variable name. If the user story we are working on depends on this variable somehow, we will change the variable name to be more descriptive.
This approach should be your default way of eliminating technical debt. With this approach, you immediately benefit every time you eliminate technical debt. The problem with scheduling time periods for technical debt tasks where all you do is eliminate technical debt is that you don’t get any benefit until you go on to do a task that benefits from having that technical debt removed. If you eliminate some technical debt but never end up doing a task that benefits from it, then eliminating the technical debt was not a good use of your time. Thus, scheduling technical debt tasks poses significant risk in that removing the technical debt might never go on to pay for itself. Tackling technical debt as you work on stories still has the chance of not being not worth the investment but the chance of that is much lower.
In this approach, we schedule tasks for eliminating technical debt. The only purpose of these tasks is to eliminate technical debt. No immediate business value is achieved. The goal is that we will eventually go on to do tasks at a later point in time that will benefit from having eliminated this technical debt.
From the previous section, I hinted that tackling technical debt while you work on stories is the better approach. In most technical debt scenarios, you can remove a little bit of tech debt by doing a little bit of work which is how the tackling tech debt as you work on stories approach works best. However, in a few scenarios, the tech debt is set up in such a way that you cannot remove a little bit of tech debt by doing a little bit of work. The only way to even remove any tech debt might be to remove a lot of the tech debt by doing a lot of work. Perhaps you have to uplift your project to a different framework or technology and the framework or technology is set up in such a way where it either all goes through or none of it goes through. Instead of it being possible to just uplift a few files at a time and the project works with only a few files uplifted, maybe the framework or technology requires all files to be uplifted for the project to build. This would be an example where scheduling a technical debt task is the better of the two approaches.
I used to think that doing something that introduces technical debt was always the wrong approach. I was of the opinion that the only thing that matters is that we complete as much work as possible in the long term. I read a book and found out I was wrong.1
When thinking about doing something that will add technical debt, we need to answer the following question:
Should we take some shortcuts that will get our feature to market earlier but will slow down some future releases?
In most scenarios, the answer is no. Sometimes the answer will be yes.
Suppose that your company is working on a feature and a competitor of yours is working on a similar feature. Your stakeholders consider it critical that your feature makes it to market before your competitor’s feature. You could find yourself in a situation where the increase in revenue generated from taking shortcuts to deliver early more than offsets the additional cost that is incurred from introducing tech debt.
Another scenario where introducing tech debt might make sense is when you are behind schedule on a project with a strict deadline where the cost of missing the deadline is enormous. Maybe the deadline is set by the government and if you miss the deadline, all of your clients get fined a large sum by the government. Taking a shortcut that introduces technical debt is not supposed to be the default response to being behind schedule. That is where reducing scope comes into play. Maybe you have reduced scope as much as you could and you are still behind schedule. Your team starts to consider doing overtime but even with overtime you are concerned you might not make the deadline. What do you do? Unfortunately, you just might have to start brainstorming to see if there are some shortcuts you can take.
When it comes to dealing with technical debt, it is good if software engineers and the business people who are deciding which features to work on are in good communication with each other. In Scrum, it’s the product owner who prioritizes which work to do. This person will usually be a business person who is non-technical and will not be familiar with technical debt.
When doing the approach of tackling the technical debt as we go, we are generally just tackling small amounts of technical debt at a time so we generally don’t have to communicate with the business person about something as small as that. We just need to make sure when we are estimating, our estimates are accounting for the additional time that might be spent eliminating technical debt.
When thinking about scheduling task(s) for large scale technical debt removal, we would want to have a conversation with the business people about this since this could push back our next release date or significantly reduce the scope of our next release. I don’t think software engineers alone can decide if doing something that delays their next release but speeds up some of the future releases is worth a try. In order to make that decision, they have to have more information on things like the cost of the feature, the revenue the feature is predicted to generate, the market, and more. Only the business person has some sort of guess about this. It is a difficult situation because the software engineer is the one who understands the impact of the technical debt but the business person understands the market.
This is why the software engineer and business person need to be in good communication. The software engineer needs to be able to express the effect of removing the technical debt in terms of business value. “If we spend 4 straight weeks removing technical debt, it will make all future features able to be completed in 75% of the time.” Now the business person has received enough information from you to decide whether or not to go forward with this technical debt task. Maybe your team doesn’t have any urgent requests right now so the business person says to go ahead and work on getting rid of the technical debt now. Or maybe you have two urgent requests right now so the business person says to get these two urgent requests done first and then work on eliminating technical debt after.
When it comes to considering adding technical debt in order to meet a strict deadline, that is another conversation to be had between software engineers and the business person for similar reasons as above. We would communicate how much time we think we’ll save for our current release by adding technical debt. We would also communicate how much longer future work might take as a result of this technical debt as well as how long it might take to remove the technical debt in the future. The business person would take this information and decide if they are okay with this or if other alternatives like pushing the date back need to be considered.
In most scenarios, we want to try to remove technical debt as we work on stories. We do our story normally and only remove technical debt when it slows down our progress on our story. In some scenarios where we are not able to make small code changes that remove a small amount of tech debt, we need to think about the option of creating a separate task for a large-scale technical debt removal. The software engineer needs to express this task in terms of business value to the business person so that the business person can prioritize this task how they see fit.
Most of the time, we want to work on a feature in such a way that we release it without accumulating any technical debt. However, some extreme circumstances might arise where it is the right decision to take a shortcut that introduces technical debt.1 This is where the software engineer communicates to the business person how much time the shortcut will save for the release and how much longer future features will take to do as a result of this tech debt as well as the how long it might take to remove the technical debt in the future. The business person will take this information and decide whether we should introduce tech debt or consider other alternatives.