What is it?
Tech debt is deferred work for later. As an analogy to ordinary life, we can give an example of dinner. You prepared food and ate, but did not wash the dishes. While everything is fine, you are satisfied and full, but someday you will have to wash the dishes.
With the code already written, this work may imply some improvements or optimizations. But what is important to note is that these improvements will either have no or very little impact on the final product. All of them are aimed at developers as end users. If it were not so, then it would be a standard task.
What does it look like?
In fact, he has many guises and they can depend both on the specifics of the project and on the conditions in which the project exists. Below are just a few of them:
- The architecture does not meet the requirements of the application or is a complete absence. The worst example you can imagine is that the entire application is written in one file and it is hundreds of lines long.
- Strong code cohesion within the application. At the level of projects, components, classes, modules, etc. A change in one part causes unexpected consequences in seemingly unrelated things.
- There is nothing more permanent than something temporary - Ad-hoc / One-time solutions. “Here and here I will add a new condition only specifically for this case, and later I will remove it.”
Where it comes from?
Tech debt can often be seen as a list of compromises on the part of the tech team for the sake of the product team. It is also called a compromise of quality and speed. Although this is called technical debt, the responsibility for it is equally distributed among all people on the project. Such compromises under the hood can be caused by
- unreasonable requirements,
- poor communication or miscommunication,
- unrealistic deadlines,
- low qualification of team members
This already leads us to low code quality, a long time in development, instability of the application, and low maintainability level.
How to fight?
First and most difficult, do not look for the guilty, you need to pay your debts. Next, you need to assess the scale of the tragedy. There are advanced cases when it is easier to name a system as a legacy and treat it like a legacy. But often, it is still fixable, and then we use the principle - of divide and conquer. All debts must be registered and prioritized and always ready to get into the processing queue.
It should not be forgotten that lobbying for the idea of paying off the debt lies entirely on the side of those teams. The product team, and the business as a whole, are not competent in these matters and evaluate and prioritize them on their own.
And most importantly, prevention. Debts must be controlled and managed. Constantly set aside time to work on them, this should be systematic.
Conclusion
For many products, especially start-ups, timing is often a factor. How to quickly enter the market, occupy a new niche or create this niche, manage to attract as many customers as possible, and if on the other side of your product there is an uncompromising tech lead that does not allow you to send a new killer feature to the production until it shines, it can often be fatal for the entire product. The converse statement is absolutely just as valid. When the product team fails to pay such debts, there is a non-zero risk of losing both the level of quality and reliability with the ability to support this system.
Therefore, working with technical debt is a movement from two extremes, and in this movement, the main thing is to find a balance, a golden mean. A balance when the debt will arise but will not accumulate to a critical state. Think of technical debt as analogous to financial debt. It's not just the way they are named. If you have a debt — there is always an interest that should be paid.