I remember when I first heard the term “technical debt” I just didn’t understand what those words meant. I was overthinking it. When I saw the word “technical” I immediately thought that it’s gonna be too difficult for me to understand because I’m not a developer.
But that was far from the truth. It actually is not as difficult as it sounds and it totally makes sense even when applied to non-technical work.
So in this video, I’ll explain what it is in simple terms and with plenty of examples.
The basic definition of technical debt is:
But this can happen not only in IT. Here’s another definition:
The key point to highlight is that if not fixed it will bite us in the a** in the future, and we don’t know
when exactly.
What is technical debt, actually?
Let’s make that definition a bit more tangible with some examples. And I’ll use a metaphor of cleaning a house for this.
As you live in a house or an apartment, you use it and you accumulate garbage.
You eat – that makes dirty dishes. You sleep – your bed is unmade.
As you walk around, you bring in dust, and crumbs, and other stuff.
You misplace objects. Put your clothes all in the wrong places and so on.
If you go around and clean everything right after you use it, then your house will be squeaky clean all the time. But…
So maybe you decide to do deep cleaning every weekend. That is still fine because you haven’t accumulated as much stuff to clean. So maybe it’ll take you an hour every time to clean the whole house.
But what if you don’t clean up after yourself every day, and you don’t clean every weekend. Not even every month.
And now you have your parents coming over next day.
Now the situation in your house may be so dire if you haven’t cleaned in ages, that it’s going to take you days to clean everything.
Every time you say “I don’t have time to clean right now” you are accumulating some cleaning debt.
If you try to fix it right away, it doesn’t take as much time. But the more garbage you accumulate, the harder it is to use your house.
Now, every time you want to sit to have lunch, you need to move stuff around to free some space on the table. It may be hard to move around the house.
You are spending your time fighting the cleaning debt accumulated in your house.
Think of the garbage and dirt accumulated in your house is a perfect metaphor for technical debt.
What is technical debt in IT?
Ok, so now we have a good understanding of the concept of tech debt. Let’s look at some real-life examples.
1️⃣ The first and the easiest example would be small bugs and defects that we decided to not fix. I’m not talking about major or breaking bugs, just minor things that we should fix, but they are not a priority right now.
But tech debt is not necessarily just bugs and defects that exist in your product. There’s more to it.
2️⃣ Another one is lack of documentation.
For example, support documentation, or user manual, or release notes. Or as simple as comments in the code and technical documentation that can be used internally by developers.
We may not need this documentation right now immediately, but in the long run it will be more difficult to build new features or product customer support without it.
3️⃣ Some more technical examples of tech debt would include things like: complex code, lack of automation or unit tests, duplicated code or modules, hard-coded variables, lack of naming conventions in functions and variables, and so on.
In the moment, it may save the team some time which will allow them to complete something faster.
For example, if they don’t need to write unit tests as they write their code, it will take them lesst time to do so. But later on the lack of unit tests will make it harder to test their work.
It will become a burden the longer the team waits to fix the tech as they’ll need to work around the tech debt when working on new functionality.
So creating tech debt saves you time in the moment, but wastes much more of your time in the long run.
When you don’t pay your debt and create more of it…
Let’s look at another example and for that we will be taking a loan.
Say, you decided to buy a house, but you can’t afford it out of pocket.
So you take a mortgage from a bank for $500,000. We’ll simplify our calculations here. Say your monthly payments are $3,000, where $1,500 is the interest, and the other part is the capital payment for the loan itself.
Some time passes, and you decide to invest in another property. So you take out another loan for $500,000 with the same monthly payments. You still haven’t paid your original debt and now you are taking on more.
Now you pay $3,000 of interest, and $3,000 of capital payments on your two loans every month.
If you keep taking more new loans without paying the old ones, your monthly payments for them all will keep increasing. And at some point you may no longer be able to pay off the debt itself and only be able to pay the interest. Or not be able to pay anything at all.
And of course, you’d have zero money left to use on anything else.
However, the bank will stop giving you money at some point, because they would be able to analyse how likely you are to repay it. And if it’s not looking good, they probably wouldn’t take the risk.
Imagine if there was no bank to stop you from lending more money. This is exactly what’s usually happening with tech debt.
The challenge with technical debt, is that no one really takes the time or knows how to assess the negative effects of tech debt on the teams and the product.
Many teams are being pushed to produce more features instead of fixing the debt, because that’s what the business needs right now, and under pressure they may even be encouraged to produce more tech debt to save time…
At some point the debt will get so bad that the team would only be able to make interest payments a.k.a. fight the technical debt instead of repaying it or using their time on building new features.
How to show tech debt to the business side?
Of course, tech debt is easily understood by the developers as they live with it every single day. But it is difficult to actually show it to the business side.
So if you have a Product Owner who is not technical, they may not understand the implications. It may be the same with stakeholders who are laser focused on business value delivery, and don’t see why the team should “waste” their time on fixing tech debt.
To all of these people, tech debt is invisible. So the solution is simple – you need to make the tech debt visible.
The number one mistake many development teams do is that they just state the tech debt in tech language and hope that it will be prioritized by the business side.
This is not enough.
Same as you would expect the Product Owner to explain the Product Backlog items the team needs to work on in detail, developers need to explain the tech debt. In the language of the people who are listening.
Of course, the tech debt doesn’t bring direct value to our customers or stakeholders. But it can help us reduce risk, wasted effort, wasted money and so bring value to the company itself.
Say your team has an old service solution they use in the product that needs to be updated. If you say just that to your business counterparts, you may hear in response: “But right now the service works, so why bother?”
And here’s where you need to provide more business-oriented details. In this case, here’s what you can say:
If we don’t update the service now, we don’t know when exactly we’ll have to switch. The service will stop being supported by our vendor at some point, but we don’t know when. It can happen during an extremely imporant release window. Which means that we won’t be able to deliver anything at all.
In addition, if we are pushed to update it last minute, we’d have to update everything associated with the service at once which will take us 2 months where we won’t be able to deliver any new functionality or fix any bugs.
If we start the update now, we can do it incrementally without blocking other development.
This will minimize the risk and save us a lot of time in the future.
This is the kind of explanation that is easy to understand even for non technical people. It provides enough details that can help the Product Owner and the stakeholders to prioritize this tech item against functional requirements because the value is now clear.
How to reduce technical debt that already exists in your product?
Many teams struggle with tech debt from the start. Technology evolves really quickly making a lot of the recent solutions no longer appropriate.
So whether the team likes it or not, tech debt will be accumulating from time to time.
Which means that you always need to prioritize fixing it on an ongoing basis.
The DevOps Handbook recommends to dedicate a minimum of 20% of development time to tech debt.
The way you can do it is by planning for it in advance every Sprint. Consider that your team’s maximum capacity is 80% of the total. Keep the other 20% open for technical debt.
That way the team will be able to pay down the debt continuously without the need to constantly fight for the prioritization. The Product Owner can also leave developers to select the most appropriate items to work on if they are not technical and are having trouble prioritizing non-functional work.
You should also use the golden rule of camping to “leave it better than you found it”. Which in IT language would usually refer to refactoring code as you work on it.
How to document technical debt?
What I often see in teams is that developers are aware of the technical debt in the product, but they do not document it in the product backlog or anywhere else.
So it all stays in their heads as they wait for an opportunity to insert tech debt work into their regular Sprints.
But because there is no way to review and prioritize it, it’s pretty much impossible to plan for it.
Which means that the team will rarely actually find time to work on reducing tech debt and will probably be mostly firefighting it when it hits them in the face.
That’s why developers should spend some of their refinement time on documenting the tech debt.
It doesn’t mean that every single thing has to be in the Product Backlog as we don’t want to overcrowd it. But having a place where all of the information is documented for future use is essential.
And then when the team is planning for a longer period of time, they can take that information and put the high-priority items into the Product Backlog to make it visible to stakeholders too.
Your Definition of Done can help reduce tech debt
One more useful strategy you can use to reduce technical debt is your Definition of Done or the DoD for short.
You see, the DoD makes it clear what the minimum quality that you accept in your product. And this may include some items that otherwise could become technical debt.
For example, lack of automated testing may be combatted by adding a certain percentage of automated testing created into your Definition of Done. That way the team would need to do it before they can call something done.
It will probably take more time for every Product Backlog item they are working on to be completed, but it will also reduce potential tech debt.
It’s kind of working on catching your tech debt before it is even created!
In addition, the team will be able immediately to plan for that work before it even starts in Sprint Planning because they would need to account for that work in their estimations.
I think that the Definition of Done is such an important and kind of an easy way of addressing the tech debt, that this is the perfect next stop for you. If you need more help with your Definition of Done, 👉 head over to my video on the Definition of Done versus Acceptance Criteria.
