Why technical debt is good

Original author: Ziv Segal
  • Transfer
Excluding those fortunate enough to be rich, most people borrow money when they start their first business. And they hope that these investments will pay off. This is an example of how debt can be a good thing.

The same goes for technical debt. Countless articles on the Internet tell how to get rid of it or at least reduce it. All of these articles show technical duty by some kind of monster that needs to be avoided. And if it didn’t work out, then fight hard.

I welcome the technical duty in my work. Obviously, in the general case, it’s not very good when you owe someone. But sometimes debt can be the smallest of evils available. To prove this is very simple - if the technical debt were so scary, then large companies would never have had it (translator's note: so-so argument, to be honest).

In this post I want to show how much technical debt is like a regular loan taken to develop a business. And what you need to consider when deciding whether to take such a loan or not.

What is technical debt?

When developing programs, you constantly have to balance between the speed of development and the quality of what is obtained. In order for the release to happen on time, one often has to sacrifice the quality of development using crutches and hacks. The correction of this is usually transferred to future releases - which, in fact, is called "technical debt."

Technical debt arises for many reasons. Development customers can focus more on timing and functionality than on fixing old problems and creating a solid foundation for further development. In degenerate cases, customers generally ignore these things, demanding only “features on time” from the team.

Ultimately, technical debt leads to problems for users who gradually stop using the product. And ignoring technical debt by both developers and managers only contributes to its accumulation.

When to borrow technical debt

Understanding when it is necessary to make a release at the expense of technical debt is both art and science.

When taking a loan, one of the most important things is the interest rate. Obviously, taking a loan from a shark-lender with a high interest rate is not the best idea.

The same goes for technical debt. You need to understand what kind of “percentage” you will pay on it, based on the rules set out below and common sense. In most cases, technical debt is a very good thing, as long as the interest paid each month is within reason.

To calculate the "interest rate" of technical debt, I suggest the following techniques:

- Is the code part of the basic functionality of your product?If so, technical debt can be very expensive. For example, our Logz.io team easily takes on technical debt when developing internal management consoles or esoteric functionality for single clients. But we make every effort not to have a technical duty in our core functionality: log processing and analytics.

- Difficulties in the future? How will technical debt affect future development? What impact will it have on related functionality and tasks? If the developed functions are peripheral and are not planned for active use in the coming months, then technical debt can be useful and free up time for developers to work on the main product.

- The price of the subsequent elimination of “crutches”?Very often, fixing patches can require complex upgrades between versions, loss of backward compatibility, or significant effort in code refactoring. This means that in such cases the “interest rate” will be very high.

- Impact on customers? What effect will used crutches and patches have on your users? If they lead to the appearance of bugs once a month - how much will they be unpleasant bugs and what will your users do if they occur?

Do not be afraid of technical debt

Technical debt is something we have to deal with from time to time. And it all comes down to the question that economists formulate as the “price of opportunity”, that is, in order to make “X” you must first make “Y”.

If your team spends a day fixing patches and crutches, this day will not be spent on developing new functionality. In the same way, a day of work on new features will not be spent on fixing old bugs.

Look at the development picture from the top of the company’s leadership. Every dollar spent on development can no longer be spent on marketing, administrative expenses, and other things business needs. The same thing works in the opposite direction. Decisions are made on the basis of priorities, and technical debt in most cases has a low priority.

I will give an analogy from the world of finance. Suppose a company has a regular, non-technical debt of one million rubles. And revenue of one and a half million per month. Does the company need to pay off all the debt immediately? Of course not. After all, the remaining half a million is not enough to pay salaries, rents and other necessary things.

The correct solution would be a gradual payment of the debt. As long as profit grows faster than debt payments, it is not something bad. He is an investment.

I welcome technical debt because it shows that we are growing as a company: we will release new features and products that help our customers work with logs. If the development team spends too much time fixing minor crutches, then this is not a benefit, but a risk of stagnation.

Nothing is perfect - especially in software development. I understand that developers are proud of their work and want to see bug-free software, but I try to look at the whole picture and take into account the needs of not only the development, but also the company (translator's note: in most cases, programmers want to go home and have a beer, but maybe silicon the valley is a bit wrong).

The time is coming when we are reducing technical debt. But this is not as important as most programmers think about it. In the future I will continue this discussion and talk about the best practices for reducing technical debt - but not earlier than necessary.

From a translator: I also recommend reading one of the articlesour technical evangelist dedicated to technical duty. Everything is described in his words in slightly darker colors, apparently, the person was not lucky for startups with good

Also popular now: