Why technical debt is good

Excluding those lucky enough to be rich, most people borrow money when they start their first business. And they hope that this investment will pay off. This is an example of how debt can be a good thing.

The same applies to technical duty. Countless articles on the Internet tell how to get rid of it or at least reduce it. All these articles show technical debt by some kind of monster that must be avoided. And if it did not work out - then fight with all my might.

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

In this post, I want to show how technical debt is similar to ordinary credit taken on business development. And what should be considered when making a decision: to take such a loan or not.
')

What is technical debt?

When developing programs, it is constantly necessary to balance between the speed of development and the quality of what is produced. To release happened on time, often have to sacrifice the quality of development, using the "crutches" and "khaki." 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 timelines and functionality, rather than fixing old problems and creating a solid foundation for further development. In degenerate cases, customers generally ignore these things, demanding from the team only “features on time”.

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

When to take a technical debt

Understanding when it is necessary to make a release at the expense of technical duty 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 high-interest shark with a high percentage is not the best idea.

The same applies to technical duty. You need to understand what kind of "interest" you will pay on it, based on the following rules and common sense. In most cases, technical debt is a very good thing, as long as the interest paid each month is within reasonable limits.

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

- Is the code part of the core functionality of your product? If yes, then technical debt can have a very high price. For example, our team Logz.io without any problems takes technical debt when developing internal management consoles or esoteric functionality for individual clients. But we make every effort not to have technical debt in our main functionality: log processing and analytics.

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

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

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

Do not be afraid of technical debt

Technical debt is something we have to face 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 an “X” you must first make a “Y”.

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

Look at the picture of the development from a height of company management Every dollar that is spent on development will no longer be spent on marketing, administrative expenses and other things necessary for the business. The same works in the opposite direction. Decisions are made on the basis of priorities, and technical debt in most cases has low priority.

I will give an analogy from the world of finance. Suppose the 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 immediately pay the entire debt? Of course not. After all, the remaining half million is not enough to pay salaries, rent and other necessary things.

The correct solution would be a gradual payment of the debt. As long as profits grow faster than debt payments, it is not bad. He is investing.

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

Nothing is perfect - especially in program development. I understand perfectly well 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. the valley is a bit wrong).

The time comes when we reduce 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 ways to reduce technical debt - but not before it is needed.

From the translator: I also recommend reading one of the articles of our technical evangelist on technical duty. He described everything in a slightly darker tones, apparently, was not lucky for a person on startups with good
financing.