Technical Debt is a Good Thing

Except for the lucky few who happen to be rich, most people borrow money when they start a business — and they hope that the investment will pay off. That’s an example of how debt can be a good thing.

Technical debt is no different. Countless articles have been published on reducing technical debt — just do a quick Google search — and they all presume that technical debt is some terrible monster that needs to be avoided.

But in my work, I welcome technical debt. Obviously, it’s generally bad to be in debt — but debt can sometimes be the least bad option. The proof is simply that if the technical debt were very dangerous, then every company would have zero technical debt at all times.

In this post, I wanted to present this argument by first introducing the topic and then sharing how technical debt is very similar to taking a business loan. Then, I’ll show what criteria need to be examined when deciding whether to “go into debt.”

What is Technical Debt?

In software development, there is always a constant need to balance speed and quality. Some quality will always have to be sacrificed to release features within a reasonable timeframe, so any of these shortcuts will often be tasked as future projects. Those unattended tasks become what is called technical debt.

There are several reasons why technical debt happens. Product owners may focus more on the need to implement and release new features and less on fixing past problems or create a generic enough infrastructure to support future developments. In some severe cases, product owners completely underestimate the outcomes of dealing with poor infrastructure, bugs and poorly designed software.

Ultimately, technical debt can sometimes lead to software users having bad experiences and thereby increasing user churn rates. Together, a lack of developer awareness and task ownership can lead to more technical debt.

When to Go Into Technical Debt

Knowing when to release a feature and go into technical debt is one part art and one part science.

When someone takes out a business loan, one of the most important things to consider is the interest rate. Obviously, it’s a bad idea to use a loan shark who offers an interest rate in the high double digits or more.

The same is true with technical debt — you need to measure the amount of “interest” that you will pay based on the below criteria and any other relevant details. Technical debt is usually a good thing to have — as long as the amount that you will pay is moderate and reasonable.

Here is how we evaluate the “interest” on technical debt:

— Is this a fundamental part of the core product? if so, taking debt might have a very high cost. As an example, we at Logz.io might take a technical debt when developing our internal management console, or an esoteric feature but we strive to have minimal technical debt in log processing or core analytics capabilities.

— Future implications? What effect would the technical debt have on future development projects? How will it affect related features and tasks? If this is a peripheral feature that is not likely to be used in the coming months, maybe a technical debt is fine and you can use the extra time to move the core product further.

— Cost of fixing? Very often, doing the “right” solution might require you to go through a difficult upgrade, breaking backward compatibility or investing a lot of development resources in refactoring code. That means that the debt interest, in that case, is very high.

— Effects on customers? How much will the technical debt affect customers experience and customer success? If this debt means that once in a month a customer might come across a bug, what would the impact of that be? How severe is that bug?

So… Don’t Fear Technical Debt

Technical debt is something that sometimes needs to be addressed — but not all the time. It all comes down to what economists call “opportunity cost,” which is simply the idea that doing X comes at the cost of not doing Y.

If your R&D team takes one day to fix bugs and “payback” technical debt, then that day is not being spent on developing new features. Conversely, the time that is spent on developing new features is not being spent on fixing bugs and improving your existing software.

Take a step back and look at the bigger picture in terms of a company’s senior management. Every dollar that is spent on R&D is a dollar not spent on marketing, administration, and other business functions. And vice versa. Decisions based on priorities always need to be made in all areas, and technical debt often is — and usually should be! — a lower priority.

Here’s a financial analogy. Say a company has $1 million of actual debt (not technical debt) and has $1.5 million in revenue in a month. Should the company pay back all of that debt immediately? Of course not. The remaining $500,000 would probably not be enough to cover payroll and other expenses.

The smart thing would be to pay off the debt over time. As long as revenue grows more quickly than debt, the debt is not a bad thing — it’s an investment.

I welcome reasonable levels of technical debt because it means that we are growing as a company by releasing new features and products that will help the log analysis community. If our R&D department focuses too much time on fixing relatively minor issues, then we will risk stagnation.

Nothing is ever perfect — especially not software. While I certainly understand that developers take pride in their work and want to see bug-free products, the bigger picture within R&D and throughout a company as a whole needs to be kept in mind.

There are a time and a place to reduce technical debt, but it’s nowhere near as important as most developers think. In the future, we will continue this discussion and examine the best ways to reduce technical debt — but only when it’s necessary to do so.