People online talk about “tech debt” as a universal evil that heroic engineers must fight against Product to prevent, but just like real debt, the story is more complicated.
Technical Debt is the idea of reducing work now to finish a project sooner, in a way that will create more total work later. This can occur in many different flavors — cutting quality corners, not writing any tests, or solving only a subset of the problem you know you’ll eventually need to solve. Creating tech debt comes with a few different dimensions that need to be compared:
cost(shortcut) + cost(later fix) - benefit(shortcut) > cost(doing it right)?
Benefit and Payback are the easiest to think about, but actually it’s the Interest Rate that is the greatest risk of tech debt.
Fig 1. Einstein’s thoughts on Tech Debt
There’s a massive difference between having $500k of credit card debt and having a $500k mortgage, because of how much interest you’ll need to pay. Credit cards can have interest rates as high as 20%, and the worst pieces of tech debt will be just as bad.
Let’s say you built a brittle product with no tests to get it out the door, and plan to rewrite it a year later when the team has bandwidth. Your cost isn’t JUST initial_work + fixup Instead, it’s:
initial_work + bugs_and_friction_from_tech_debt + fixup
In the year until you fix the original tech debt, every new bug caused by the brittle solution and all the extra manual testing that engineers will do because there are no automated tests is part of the true cost of that tech debt. Pretty soon you’ll find that each sprint a big chunk of your engineering velocity is just going into “interest payments” caused by that initial tech debt, and over the year your total work may end up being 2-10x more than doing it right the first time. This is “Credit Card Tech Debt”.
Fig 2. Trying to pay back high-interest tech debt
Now, not all tech debt has to be like that, just like not all debt is credit card debt. Let’s say your product eventually needs to support millions of users, but to start you build a solution that will only support thousands. You build your solution in ½ the time the full solution would take, but you’ll need to fully rewrite it a few years later when your business scales. This IS still tech debt — your total work will be 1.5x higher than if you built the full solution from the beginning. But as long as the “interest rate” on this is low, it won’t balloon out of control. This is “Mortgage Tech Debt”.
Fig 3. Finding low interest tech debt
Now you might be wondering why you should ever choose to create tech debt, when even the good example still created 1.5x more work than “doing it right the first time”. The answer is that work is more valuable today than will be tomorrow.
It’s important to make time in engineering sprints to pay back tech debt before it spirals out of control. When deciding how much to pay back which parts to pay back, focus on the Interest Rate. Mortgage Tech Debt might be ugly and get complaints from the team, but dig in to really understand if it’s adding cost each sprint.
With careful design, choosing the right kinds of tech debt to take on can help your engineering team gain a meaningful headstart without creating an ongoing cost. Tech debt needs to be carefully watched and paid down, to keep engineering velocity high. If you want to join a team that takes tech debt seriously and cares about its engineers, Cobalt Robotics is hiring!