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

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

What is technical debt?

However, first let's understand the terminology. Technical debt is a software engineering metaphor for problems accumulated in software code or architecture due to neglect of quality in software development and causing additional labor costs in the future. This is the definition of technical debt given by Wikipedia. To put it simply, technical debt is the result of applying simplified and short-term solutions in development, which later lead to ever-increasing (unless, of course, the debt is “repaid”) costs of money and time for subsequent refinement, rewriting the code or maintaining the product in its existing form . In the world of ordinary programmers, technical debt is one of the types of negative karma, a demotivator and a source of sadness that comes as retribution for bad code, the use of crutches and “temporary” (but in fact not very) 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 annually spend more than $85 billion a year just on fixing bad code. In total, about $300 billion a year is spent on projects related to supporting outdated systems and “bad” software. These are significant numbers. Researchers estimate that if the efforts of all developers who work with technical debt and its consequences were refocused on “right” development, it would add about $3 trillion to global GDP over the course of the current decade.

Reasons for 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 launch a startup ). In the case of TD, this is acceptable for rapidly 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, as with financial debt, you need to be careful with technical debt and know how to manage it, otherwise serious problems can arise. The more technical debt accumulated during 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 are responsible for the “maintenance” of such debt, and increasing costs, which ultimately can even destroy the company . The reasons for the occurrence of technical debt, in addition to the noble desire to finish the product as soon as possible or to please users with a new release, are often poor product management, unrealistic deadlines or resource limitations, and of course, coder laziness, coupled with low qualifications and a lack of understanding of key development principles, also often contributes contribute 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 it, or cannot convey information to management about the existence of such a problem and the importance of solving it.

Classification

As mentioned above, technical debt comes in many different forms, and since the definition itself is just a metaphor, the different types of technical debt can be classified in different ways. In particular, Dag Liodden, co-founder and CTO of Tapad, who is considered one of the world's experts on technical debt, during a speech at the annual CTO Summit event, proposed dividing technical debt into three main types.

1. Intentional technical debt.

   It appears in cases where developers deliberately 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, consider not only the time you will save during development, but also the time you will have to spend later to “pay off” such debt. Also, make sure that stakeholders [top management of the company] are aware that such a decision will inevitably slow down the launch of other functions in the future,” said Dag Ljodden.

   An approach to solving this type of technical debt

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

2. Technical debt that is accidental or arises from outdated project architecture.

   Also, technical debt often arises over time, due to errors and shortcomings at the stage of creating the project architecture. As systems evolve and software requirements change, design errors become more apparent, and adding new features requires 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.

   An approach to solving this type of technical debt

   To prevent this type of technical debt from accumulating and not exceeding critical levels, Dag Llodden recommends refactoring regularly - approximately once every two years, during periods when the system is in a stable state. Team leads and product managers must allocate time to “pay off” this type of technical debt that arises due to the architecture and frequently changing requirements for the project.

3. Technical debt that arises over time.

   The expert calls such technical debt “long-rotting.” It accumulates over time as a component or system gradually becomes more complex due to many changes being constantly added. This is often made worse if different people work on the system at different stages and do not fully understand the original architecture.

   An approach to solving this type of technical debt

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

Technical Debt Management Solutions

There are many options for effectively managing technical debt, but all experts agree that this must be done, since technical debt is an integral part of almost any development, and those companies that ignore it invariably face problems at later stages. Here are some effective solutions and approaches to managing technical debt for a development team.

1. Allocate a fixed percentage of your work time to working on technical debt.

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

   This can be done in different ways.

2. Work on technical debt 1 day a week

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

3. Dedicate every fourth task to working on TD

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

4. Transitional role

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

5. Boy Scout rule.

   The rule of the Boy Scouts is to always leave a campsite (tent site) in better condition than it was when they arrived, that is, to clean up even trash that was not left behind by them. This principle, as overseas coders have discovered, is also great for managing technical debt. According to this rule, all team members must correct the TD every time they encounter it in one form or another. Of course, this rule must be applied wisely so that the time it takes to correct the TD does not exceed a “reasonable” 25-30% of the total time resources.

6. Prioritizing “expensive” technical debt

   Experts also generally recommend not to forget that technical debt can vary in importance. Not every type of technical debt requires immediate resolution, so it is important to work on classifying the different types of technical debt and prioritizing work on 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 grow like a snowball.

Conclusion

Finally, I would like to emphasize once again that it is impossible to do without technical debt 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 won’t be able to do without it completely, the amount of technical debt can be reduced as much as possible if you write “clean” code and approach the development process as responsibly and professionally as possible. This is what we wish for everyone!