Tech Debt is not always bad

A common complaint from engineering teams and departments is around tech debt. I see and hear a lot of people complain about having tech debt, never getting to address it, and overall a sentiment that it shouldn’t exist. While that’s understandable, that’s also not understanding what tech debt is. It’s also ignoring the impacts of having tech debt, or working in a way that never introduces it. Essentially, there is no perfect answer. And there’s no single solution. But there are better and more insightful ways of looking at tech debt to understand the impacts not just on engineers, teams, but as a business as a whole.

What is tech debt?

Many people often misunderstand the true nature of tech debt. They simply see it as a tool with multiple uses, much like any other tool. Tech debt allows for faster completion of tasks and can also facilitate improvements upon existing solutions. Its versatility allows for both beneficial and detrimental outcomes depending on how it is utilized.

When approached with the intended metaphor of debt, its potential applications become clearer. For instance, when faced with the need to develop a feature, one could opt for a debt-free approach, ensuring the most optimal outcome but requiring a longer development period, perhaps three months. Conversely, by embracing some tech debt, the feature could be completed in half the time, around a month and a half.

Tech Debt as a Metaphor

As an engineer, you want to avoid adding tech debt in principle and just do a solid job now. However, as a business, you have to weigh the costs, and there are many. There’s engineering time, opportunity costs, possible loss or delay in new business, or possible churn, etc. That also means that your teams could lose out on working on something else in those 6 weeks.

It’s no different than any other debt. Does your roof need fixing? It may cost you $12,000 to replace your roof. Most people don’t have that much money laying around. So, you could save up for 3 months, get a second job, and pay it off all at once. Or you could pay down some of it upfront, then take on the debt, and get your roof fixed in 2 weeks.

Either way works, but like any major decision, you have to weight costs. Could you afford that additional money due to interest? Would you have more damages if it rained? Are the roofers you want to employ busy now or later, so would scheduling be a problem?

Looking at it that way, debt isn’t inherently good or bad.

What are the different types?

There are multiple types of tech debt, which is good to acknowledge. You can frame it appropriately knowing the type, because decisions can happen intentionally or not. And people can make decisions being prudent or reckless. Understand what caused it, if it is to be introduced. This is a good paper on the subject.

Different situations include:

• We don’t have time to design this
• We must ship now, we’ll deal with the consequences
• What’s event-based architecture?
• Hindsight is 20-20, now we know what not to do

Look at the differences in those statements. Those statements range from individuals needing to accomplish tasks poorly to simple ignorance. You now have more tools to understand what tech debt is and why it’s not allthe same.

How to approach it

As a team lead, this is your responsibility. Ultimately, the ownership and accountability lies on you. You now have the tools to look at the situation and decide what you are comfortable with. Now you have to decide what is acceptable for you, and your team. But now you know that tech debt is neither good, nor bad. It’s not black or white, just like most things in life. You must use discernment to judge what to accept and when. And that can change depending on the situation as well.