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.
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:
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.
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:
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.
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:
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.
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.