Bad karma in programming. What is technical debt and how to eliminate it

technical debt. Most programmers who are actively working in their specialty have to deal with this term. For many, the mention of it can even cause headaches, as well as the discomfort in other parts of the body that occurs whenever you deal with technical debt in the course of working on a project. Therefore, today we will talk about technical debt (TD): what it is, how it appears, what types of technical debt are, and how to manage it effectively.

What is technical debt?

However, first let's deal with the terminology. Technical debt is a metaphor for software engineering that refers to the accumulated problems in the software code or architecture associated with the neglect of quality in software development and causing additional labor costs in the future. This definition of technical debt givesWikipedia. To put it simply, technical debt is the result of making simplistic and short-term development decisions that later lead to ever-increasing (unless, of course, the debt is “repaid”) costs of funds and time for further refinement, rewriting of code or maintaining the product in its existing form. . In the world of ordinary programmers, technical debt is one of the varieties of negative karma, a demotivator and a source of sadness that comes as a retribution for bad code, the use of crutches and “temporary” (but not really) solutions that help solve short-term problems and speed up development “on credit,” that is, at the expense of a growing tangle of problems in the future. In the IT industry, technical debt is a fairly serious problem. According to one recent study, companies around the world spend more than $85 billion a year just to work on fixing bad code. And in total, about $300 billion a year is spent on projects related to supporting outdated systems and “bad” software. These are significant numbers. The researchers calculated that if the efforts of all developers who work with technical debt and its consequences are refocused on the “right” development, this will add about 3 trillion dollars to world GDP over the current decade.

Reasons for the appearance

It should be understood that technical debt is not always a bad thing, just as getting into financial debt can be positive if, for example, you take out a loan to develop a business (or start a startup) .). In the case of TD, this is acceptable for fast-growing companies that need to release new products or services quickly and often in order to evaluate their success and study market needs, or quickly capture new niches, for example. But just like with financial debt, you need to be careful and manage technical debt, otherwise you can get into serious trouble. The more technical debt accumulated in the development of a software product, the more it can affect the company, slowing down the release of new releases, lowering the morale of ordinary coders who bear the “maintenance” of such debt, and increasing costs, which ultimately can even destroy the company. . Causes of technical debt, other than the noble desire to finish the product as soon as possible or to please users with a new release, often serves as poor product management, unrealistic deadlines or resource constraints, and of course, code laziness, coupled with low qualifications and a lack of understanding of key development principles, also often contributes to the growth of debt. It often happens that the developers themselves are well aware of the presence and constant growth of technical debt, but do not have enough power to change this, or cannot communicate to management about the presence of such a problem and the importance of solving it.

Classification

As mentioned above, there are different types of technical debt, and since the definition itself is only a metaphor, there are different ways to classify different types of technical debt. In particular, Dag Liodden, co-founder and CTO of Tapad, who is considered one of the world's experts on technical debt, during his speech at the annual CTO Summit, proposed to divide technical debt into three main types .

1. Intentional technical debt.

   It appears in cases where developers consciously choose not the best solution, because it is easier and faster to implement, which, in turn, will help to quickly release a new product to the market.

   “Sometimes we deliberately take on technical debt to reduce development time. If you decide to go this route, take into account not only the time that you can save during development, but also the time that will have to be spent later to “pay off” such a debt. Also, make sure that the stakeholders [the top management of the company] are aware that such a decision will inevitably slow down the launch of other functions in the future,” said Doug Lyodden.

   Approach to dealing with this type of technical debt

   The expert advises to carefully document such cases in order to return to them and fix them until this technical debt is lost, becoming an integral part of the project structure.

2. Technical debt, either accidental or due to outdated project architecture.

   Also, technical debt often arises over time, due to errors and shortcomings at the stage of creating a project architecture. As systems evolve and software product requirements change, errors in project design begin to become more obvious, and adding new features takes more and more time and effort. The quality of the initial project architecture plays an important role here - it should be both simple and functional, then it will be easier to adapt to changes.

   Approach to dealing with this type of technical debt

   To keep this type of technical debt from accumulating and not exceeding critical levels, Doug Lyodden recommends refactoring regularly—about once every two years, during periods when the system is in a steady state. Team leads and product managers need to set aside time to “pay off” this kind of technical debt that comes with architecture and frequently changing project requirements.

3. Technical debt that develops over time.

   An expert calls this technical debt “long-term.” It accumulates over time as a component or system gradually becomes more complex due to many changes being added all the time. Often this is exacerbated if different people work on the system at different stages, who do not fully understand the original architecture.

   Approach to dealing with this type of technical debt

   This is the only one of the three types of technical debt that you should try to avoid on a permanent basis, through regular refactoring, the expert says. Ideally, the development team should take the time to thoroughly understand the architecture of the system they are working on, even if other people originally created it. Understanding the system will allow you to gradually improve and fix bad code without bringing the project to the stage of “rotting.”

Technical Debt Management Solutions

There are many options for effective management of technical debt, but all experts agree that this is a must, since TD is an integral part of almost any development, and those companies that ignore it invariably run into problems at later stages. Here are some effective technical debt management solutions and approaches for the development team.

1. Allocate a fixed proportion of work time to work on technical debt.

   The peculiarity of technical debt is that there is never time to work on its elimination (because there are always higher priority tasks) if you do not do it purposefully. Therefore, a good solution would be to allocate a certain fixed percentage of working time for these purposes - about 20-25%.

   You can do this in different ways.

2. Work on technical debt 1 day a week

   If you allocate one day a week to work on the elimination of TDs by the whole team, this will just be about 20% of the total working time. For some teams, this approach works just fine and, it is said, even improves morale, because on this particular day of the week the whole team is solving problems that plague them the rest of the development time.

3. Dedicate every fourth task to work on TD

   Such a system is suitable for those teams that tend to divide the work on the project into tasks that are approximately uniform in time and effort for their completion. If one out of every four tasks is devoted to “paying out” the TD, this will take up about a quarter of the total development time. And introducing this approach as a rule will make sure that coders do not postpone technical debt “for later”.

4. Transferring role

   Another approach to the problem of eliminating technical debt would be to assign different team members to this task in turn, in order to evenly distribute this sometimes far from the most pleasant work among the team members. The number of developers assigned to “rake” the TD can be different - for a team of 4-5 people, one will be enough, while larger teams can appoint two or three. But the essence remains the same - about 20-25% of all resources and man-hours should go to work on TD.

5. Boy Scout Rule.

   The rule of the Boy Scouts is to always leave the tourist camp (tent camp) in a better condition than it was before they arrived, that is, to remove even the garbage that was not left by them. This principle, as overseas coders have found out, is also great for managing technical debt. According to this rule, all team members must deal with the correction of the TD every time they encounter it in one form or another. Of course, this rule must be applied reasonably so that the time it takes to fix the TD does not exceed a “reasonable” 25-30% of the total time resources.

6. Prioritizing Expensive Technical Debt

   Also, experts for the most part recommend not to forget that technical debt can vary in importance, among other things. Not every type of TD requires immediate resolution, so it's important to work on classifying different types of technical debt and prioritizing dealing with them accordingly. Simply put, first of all, it is necessary to close those debts that have a direct impact on the speed of product development, being part of its basic architecture. Such debts are the most dangerous because they lead to new debts that can snowball.

Conclusion

Finally, I would like to emphasize once again that one cannot do without technical debts in software development, because they are an integral part of development as such. However, despite its technical nature, TD is still a problem caused by the human factor in development. And although you can’t do without it completely, the amount of technical debt can be minimized if you write “clean” code and approach the development process as responsibly and professionally as possible. What we all want!