In my recent post, What is Tech Debt? I try to break down what "Tech Debt" means in modern software development. To me, tech debt is simply any work that seeks to benefit the long-term health of your software product but has been deferred until a later date.
This is important work that is often tough to prioritize. The reason it has been postponed is often that it doesn't have immediate ramifications. A tradeoff has already been considered between whether to do the work immediately or work on something else in the short term and, in my experience, once something has been postponed once, it becomes even easier to keep postponing it until it is never done.
In order to better prioritize tech debt, it's important to understand the reason an engineer wants to do it.
Today, I'll go one step further and say that there are 5 distinct types of tech debt that exist. Each type aims to solve a different set of problems in a software application. These 5 types of tech debt are performance, reliability, security, usability, and engineering excellence. When tech debt is created, it's typically done so in order to address a problem that can fall into one of the above categories. If it doesn't fall into one of these categories, it may not be tech debt at all.
Performance
Performance in the context of software products is a measure of speed. How long does your app take to load initially? How long does it take to switch between different pages or screens in your app? Users like apps that are fast, and they hate apps that are slow. Think about the last time you had to wait too long for your favorite streaming service to start the movie you selected. Do you think performance is important?
Performance problems are rampant in modern software development. Technology has grown to a point where it's incredibly easy to build a lot of software fast, and what falls between the cracks are often small little performance issues that add up over time. After being worked on for long enough, most software products tend to become slow as they get more and more bloated from additional feature work. In this scenario, an engineer might start logging performance tech debt issues in order to compensate and make the app fast again.
Reliability
Reliability is a measure of how dependable your app or software product is. Does it always work as expected? Is it suffering from slow-downs or crashes around certain times? Will it occasionally go down? These are all signs that your software product is suffering from serious reliability issues. This type of tech debt is created to try and improve the user experience by making your website and key infrastructure something that can be depended upon.
Security
Another common reason we see tech debt created is to address security concerns. You might think that since it's a security concern, it would probably be something that should get fixed immediately. While this may be true in some cases, in practice security-related issues are subjected to the same amount of scrutiny in prioritization as other issues. It's common for an engineer to ask themselves "how serious is this problem? Could it cause immediate issues?"
Security issues often can be plotted on a spectrum ranging from the most severe issues to mild issues. An example of a security issue that might be prioritized for a later time could be updating the security policies for some assets you host. This can help prevent images, videos, etc. that you host from being directly included in another website. Is it helpful work? Yes. Does it have immediate impacts on your product or users if you don't address it immediately? Probably not, unless you're dealing with extremely sensitive data.
Usability
Usability is the measure of how well a user can complete their goals using your product. Having a usable product is incredibly important to the success of your product. It can often be the difference between customers choosing your product over your competitor's product.
Usability improvements don't always fall into this "Tech Debt" category. Usability improvements can come in a myriad of shapes and forms. A new feature, for instance, might be a great usability improvement. However, too often do I see folks failing to prioritize even the smallest user experience (UX) improvements. These are a category of issues that too often fail the test of prioritization.
When trying to figure out what to prioritize next, what often occurs is you have one big feature you're really excited about, and about 50 small things in your backlog that are not that exciting. Our brains are really good at weighing the tradeoffs between two things, but we often overlook the time-cost of each option. When looking at one big feature compared to one small UX issue, it's easy to see how you can deliver the most customer value between the two options. However, we need to more often force ourselves to compare against a set of smaller issues that would take the same amount of time to finish as the bigger issue. This might mean that you should instead compare the one big issue to 20 smaller issues. This way of thinking helps tremendously when prioritizing usability concerns.
Engineering Excellence
This form of tech debt takes the shape of issues such as code cleanup, rewrites, and other work that can meaningfully improve the quality of the code your software is built with, but which has indirect benefits to your product, rather than a simple explanation like "doing this work will increase performance."
This type of tech debt is often the hardest to prioritize because the benefits are harder to measure and more abstract. However, prioritizing issues like cleaning up messy code can result in it being easier for other developers to read and understand, which reduces the time required to modify the code as well as the risk for introducing bugs when modifying it.
The outcome of this kind of work can be extremely beneficial to the long-term health of your app, but it's often overlooked because the outcomes are not something we typically know how to measure.
Conclusion
As an engineer, I've seen a lot of tech debt. As a technical leader, I've also had a lot of experience in prioritizing tech debt and seeing the returns from that work. If you're having trouble prioritizing tech debt, try out the 20% rule.
Are there more types of tech debt I've missed? Comment below with your thoughts.
