Tech debt is a word that gets thrown around a lot in modern software development. If you're a software engineer, you might have a pretty good idea already about what tech debt really means. If you're not an engineer, you might just think it's a word that we tend to use when we want to be really convincing that a set of tasks should get done.
Tech Debt Definition
The quick and easy description of tech debt that I'll give you is this: tech debt is any work that would contribute to the long-term health of a software product that has been deferred until later. The key parts of my definition that you should take away are:
- Tech debt is valuable to the long-term health of a product
- Tech debt is work that has been deferred until later. This implies there are tradeoffs being made.
- Tech debt is work that we (engineers) would like to prioritize eventually.
Tradeoffs
An important idea to take in here is that tech debt is often created as the result of a tradeoff being made. As a client, if you asked me to build a feature in 2 weeks instead of 4, I may indulge your request, because I value getting early feedback and iterating on the software until it's satisfactory. As a result of this decision to do the project in 2 weeks instead of 4, I will have to make some sacrifices. I may need to implement the feature in a way that is not build to last. In making this tradeoff, I'm creating tech debt–work that should be done later in order to maintain a good state of health for the product.
Why does software need to be "built to last?"
You might be asking yourself: "if it works for me now, then why wouldn't it keep working in the future? Why does it need to be built to last?" Building software is a difficult task. Building quality, reliable software is even harder. Just because the software works for one person doesn't mean that it will work for everybody, or even that it will keep working tomorrow.
A few problems that tech debt might be created to solve are:
- Performance: The current solution works, but is painfully slow. Improving the performance would improve the customer experience in this case.
- Reliability: This version of the software may not be reliable. It might not work properly when scaled up to handle thousands of users. It may not work properly for users across different time zones. There's a number of software bugs that could be preventing the software from working correctly for all users.
- Security: The current version of the feature works but is insecure. It may expose you to potential data leaks or otherwise heighten your risk for security issues in the future.
- Usability: Not all solutions are the most user-friendly. Tech debt can be created for the sake of getting a feature out faster at the expense of having a poorer user experience. Especially when there are technical reasons behind the tradeoff being made (for example, choosing a worse UI because it would be too expensive to build a better user experience right now).
- Engineering Excellence: Unlike the above concrete problems that tech debt often seeks to address, this category I've dubbed "Engineering Excellence" encompasses fixing poor software design, bad coding practices, and other issues not quantifiable by the other categories that an engineer feels would make a meaningful impact on the health of an app. For example, in order to move quickly, I might try writing some really fast code and not considering whether or not someone else can understand it. I might create tech debt in this case in order to go back and tidy up that code so that others will be able to modify it with a lower risk of introducing issues into the application.
In my post, The 5 Types of Tech Debt, I go into greater detail about each of these types of tech debt and how they typically present themselves in projects.
Why you should prioritize tech debt?
Tech debt is often unavoidable with most projects. If you're not accumulating tech debt, your engineering decisions might lack compromise. At HubSpot, we believe that moving quickly and iterating leads to faster feedback, quicker validation, and better results for the customer. However, moving quickly can't happen without cutting some corners. Tech debt is natural; it's okay to accumulate it. The trick is that you must pay it back before it gets out of control.
It's difficult to gauge what level of tech debt is right for your product. You'll need to lean on your engineering leadership to inform you about what feels comfortable. Tech debt becomes problematic when it's allowed to accumulate to such a large amount that it seems impossible to get it all done. Other tell-tale signs that you have too much tech debt are:
- A high rate of introducing bugs to customers when releasing new features
- Your app is becoming progressively slower
- Features you expect to be quick and easy are taking much more engineering time than anticipated.
- There are a seemingly growing number of constraints on what you can and can't build.
In my experience, projects that are too deep in tech debt are extremely difficult to work in because no feature is as simple as it seems. Even when you think something should be easy to implement, you're surprised to see that it took way longer than expected, and included several bugs.
The 20% Rule
If you're really struggling to figure out what amount of tech debt you should be prioritizing, my recommendation is to start by spending 20% of your project time working on tech debt. This will ensure you are tackling some of the tech debt (at least more than you were doing) while not risking over-indexing.
Start by spending 20% of your time on tech debt and keep tabs on whether or not your total tech debt backlog is increasing or decreasing. If you find that tech debt is still increasing faster than it can be addressed, adjust that percentage in favor of doing more tech debt. Conversely, if your backlog is rapidly shrinking, dial it back to 15% or 10% of your time. The important thing is to start somewhere, monitor your situation, and be willing to make adjustments.
Now that you know what tech debt is, you'll be able to make much more well-informed decisions on whether or not to prioritize certain issues, and you should have a better understanding of an engineer's motivations when pushing for tech debt work to be prioritized.
Have a question? Leave a comment below.
