Technical debt is a scary term. It is also one of most misunderstood terms. Here is my pragmatic take on it.

You may have:

  1. Badly written code, but it might not impact you at all (in terms of maintenance cost, bugs or growth).
  2. Or you may have portions of code that might be slowing you down because of code quality, an increasing number of new assumptions and/or wrong and invalid old assumptions.

I would not classify 1 as technical debt, it’s just bad code. Engineers in the team might find it irritating, however there’s no real interest to be paid on it.

However, 2 is techinal debt.

Engineers often get all the blame for the tech debt, however, in reality, it is a function of clarity, code quality, and validity of assumptions made.

Analogy wise, technical debt is no different from credit card debt, while some is even at times beneficial, but eventually it needs to be paid off.

To keep tech debt in check, you need to check the direction your company is taking & recalibrate your assumptions (present in your code) keeping current and at least a couple of future years requirements in mind. If you are a very early stage company and still figuring out the direction, then this period could be a couple of quarters too. Once you have done that, you need to see if you need to pay the debt right away or you are willing to pay the debt at a later stage.

This is where experience is helpful, because fixing code that is just bad, or paying debt prematurely might stop you from working on something more important. On the other hand, not allocating time to pay tech-debt (with compounding interest), will slow down your company’s growth considerably. You need to understand these trade-offs and make an explicit decision.

In summary, have a regular cadence for

  1. Spending time to understand, in your context, what is bad code and what is tech debt
  2. Understanding the impact of a particular tech debt has today and in the future. Understand the effort and return of paying the tech debt a) today b) a quarter later c) a year later.
  3. Recalibrating your assumptions (baked inside your code). They are the source of most of the tech debt.

This is part 2 of my post on Growth Debt. I have also previously written about a few similar topics here:

  1. Growing Startups and Tech Debt
  2. Speed
  3. How to engineer an MVP
  4. Speed and Quality