What is technical debt?
In simple terms, technical debt can be described as time borrowed when writing software.
In other words, we incur technical debt to save time now that we will be paying back in the future.
There are many reasons why we might incur technical debt, and when you are deciding, it will feel like the right choice, and it often is.
Just remember that incurring technical debt is usually a business decision, not a technical one.
Here a few examples of what I am talking about
- We decide to use an open-source library instead of writing our own code… because we can get to market faster this way.
- When building an MVP, we don’t spend a lot of time making our code scalable…. because we might not get the traction we expect.
- you build a non-ADA compliant application… because your clients are not asking for it, yet.
- You see an improvement, but your boss is pushing hard to meet the deadline, so you open a ticket and hope to get to it later… because, well, deadlines!
Types of technical debt
Technical debt has many shapes, the most common ones to engineers are probably new bugs, code smells, and other code metrics.
The reality, however, is that technical debt is much more complex than that.
Would you consider a lack of documentation as technical debt? (hint: you should).
What about no unit test coverage? is that technical debt? yes, yes it is.
For your purposes, you will need to come up with a good definition of what you consider to be technical debt.
If you are coming up with only a few things on your list, I recommend that you take a look at the presentation titled “Towards an Ontology of Terms on Technical Debt” by the Software Engineering Institute at Carnegie Mellon University.
Their list should work as a good starting point to identify technical debt within your organization.
Should you pay it off?
Now that you know what it is, and you can categorize it, what is the next step?
Well, now you figure out how much of it you pay down. Remember how I mentioned that incurring technical debt is usually a business decision and not a technical one? guess what, paying it down is a business decision as well.
In our case, as engineers dealing with technical debt, we can make a very good business case for spending engineering time paying down technical debt.
Take for example the MVP app we mentioned above. Since we had an aggressive time to market, we pushed hard and got the application out on time.
In the process, lots of things could have been better, but we knowingly incurred technical debt just to get the application out.
Now your user base is growing and your metrics are showing slowdowns in some areas of the application, nothing major yet, but since you are a responsible engineer, you mention it to your product manager, your manager, and your fellow engineers.
You are asked to look at how much work it would be to make the experience better, and you come up with about 6 weeks of work. (did you use our estimation guide, go ahead, take a look, we’ll wait)
While doing the work makes a lot of sense from the technical perspective, after all, we know our application can be better and we know exactly how to get there.
From a business perspective, the story is a different one. Those 6 weeks could mean a lot of positive or negative things such as
- Missed deadlines for other projects
- Going over budget
- Broken promises
or
- Increased application engagement
- Renewing the unhappy client complaining about performance
- Gaining new clients
It all depends on the business, their vision, and the return on investment perceived from paying down the technical debt.
Strive to identify technical debt early, be honest, and open about what it is and why you think it is important to pay it off.
Remember that your business counterparts will not always understand the nuances of the technical details for your proposed solution, so be nice and explain it in simple terms from a business perspective and together with your business partners decide if you will pay it down now or later.
Further reading
Technical debt is a complex topic, if you are interested in knowing more, I recommend following up by reading these great books on the topic
  |   |