Technical debt on the project or get out of the black hole

  • Tutorial
Each developer is familiar with a situation where the implementation of a new feature in the system takes a lot of time, but the release is close, and the team leader or project manager for the fifth time in a day asks the annoying question: “Well, when will it be ready?”. And then there is a difficult choice - to do everything right and not meet the release dates or implement a functional that is minimally working, but not ideal from the point of view of a technical solution. Obviously, in most cases the second option will be chosen, since release and providing the result to customers here and now is more important than clean code and system architecture. But several months pass, and now the old not ideal technical solution interferes with the implementation of other functionality. And further such decisions will accumulate in a huge lump. Dealing with this problem, it is very important to draw the right conclusions and choose the right solution. The fate of the entire project will depend on this decision. In this article we will try to understand the nature of technical debt and advise on ways to eliminate it.

The nature of technical debt


The very concept of technical debt first introduced Ward Cunningham ( Ward Cunningham ), technology developer wiki and one of the founders of Extreme Programming . In 1992, in his article, he formulated this concept in the form of a metaphor for financial debt: just like with a financial loan, developers can get additional funds here and now through the use of fast and not optimal technical solutions, but will inevitably pay for them with further development, regardless of how this debt will be paid - gradual interest payments or one payment.

image

But if the problem of technical debt was described 25 years ago and occurs on almost any project, why is there still no project management methodology that would avoid the emergence of technical debt? The answer lies in the very concept of the project. One of the key differences between the project and other activities is the uniqueness of the final product. Where uniqueness is there, unpredictability is there, and it is it that gives rise to changes in the design and introduces difficulties in the initial design of the system.

Of course, you can try to build the architecture, providing for possible changes, but here the team will encounter such a concept as “ Miller’s wallet”: A rule in which no more than nine“ coins ”can be“ put ”into a short-term memory of a person. And if the number of elements exceeds this value, then the brain tries to group the information so that their number is from five to nine.
You can try to divide the components into smaller ones in order to fit into this “wallet”, but this will not reduce the complexity, and the number of abstractions with this approach will grow at a catastrophic rate. And as you know, any problem can be solved by introducing an additional level of abstraction, except for the problem of too many levels of abstraction.

Other teams prefer to abandon the initial design altogether, trying as much as possible to use universal tools during development. On the one hand, it is easier than trying to predict changes and in the first stages the system will turn out to be flexible enough to change. But over time, the complexity of the system, according to the second rule of Lehman , will inevitably grow, it will become less flexible, and changes may occur that go against the current architecture. In this case, developers will also spend more time solving architectural problems.

One way or another, the inevitability of changes in the project provokes the emergence of technical debt.

How to determine that the project has a technical debt problem


The most important indicator that a project has a problem with technical debt is, of course, the code itself. First of all, it is worth mentioning the features of writing code. The fact is that writing and reading code are two completely different processes. When a developer writes code, he focuses only on the context of the task. But changing a single section of code affects the overall picture of what is happening. In turn, before changing the written code, you need to have an idea not only about a specific site, but also about the whole picture. But when reading, the boundaries of the contexts within which the code was written are erased on a general view. This difference between reading and writing code generates additional complexity that directly affects its quality.

image

What you should pay attention to:

  • Pieces of code that are often subject to change. Most likely, these sites require serious revision.
  • A large number of FIXME and TODO notes and a small number of comments in the code should alert. Modern IDEs have built-in support for working with such tags, so this is one of the fastest and most reliable ways to recognize weaknesses in the system.
  • Lack of tests. Without them, developers are not sure that their changes will not disrupt the system. The team refers to the code that is not covered by tests as a house of cards, trying to avoid unnecessary, and sometimes necessary, changes.
  • Lack of documentation. The situation is similar to the previous paragraph. The lack of regulated information forces the developer to think through the picture of what is happening, and there is a chance that he will have a wrong idea about the system. The situation is aggravated by the fact that in the vast majority of cases, developers of different levels of training and competence work on the project. And the difference in understanding the code further complicates the process of reading and writing code.
  • Outdated technologies and development tools. Any library or module is updated, and it’s becoming more and more difficult to maintain older versions over time.
  • Lack of development standards. Each developer does what and how he wants.

Technological Debt Elimination Techniques


  • As with the treatment of any disease, the very first step to recovery is recognizing yourself as a patient. Indeed, first of all, each project participant, from the customer to the developer, must recognize the problem of increasing technical debt. Not so long ago, I became a team leader on one large project that we inherited, and work on technical debt was never carried out on it. Delving into a huge number of tasks, I constantly stumbled upon tasks to eliminate technical debt, which were created by different people at different times, but were never realized. This suggests that attempts to cope alone with a technical duty are comparable to a battle with windmills. It is very important that the project participants are aware of this problem, because its solutions require an exclusively systematic approach.

    image

  • Use flexible development methodology ( the Agile ). The main essence of the methods is to break the development into small, isolated iterations from one to four weeks long. Thus, the “Miller's wallet” restriction is bypassed, because now in each iteration you only need to work with a limited flow of information, which makes it easier to manage complexity, and therefore technical debt.
  • Enter a general and understandable procedure for working with technical debt. Create a backlog in which there will be tasks for its payment. And when adding new functionality or planning the next iteration, take the time to complete these tasks. You can try to allocate time only to complete these tasks, but then the development of new functionality will freeze, and most likely you will encounter misunderstanding on the part of the business. In our project, we decided to devote 20% -30% of the time from the next iteration to paying off technical debt.
  • Create metrics that will be convenient to monitor the implementation of technical debt. Such metrics are individual for each project. For example, for our project, we identified such metrics as percentage of coverage with tests and documentation, code compliance with accepted Style Guides, and the complexity of deploying the system in the local environment of the developer. Some of the metrics are collected automatically, some only subjectively by each developer. It is important that these metrics are accessible to everyone, each participant sees the progress and agrees with it.

Conclusion


The technical debt problem is very relevant at the moment, and each project requires an individual approach to the problem of its elimination.

Do not be afraid of payments, because if you adopt the right strategy, then technical debt will become the force that will force your project to develop. It is work with technical debt that shows the level of maturity of both the project itself and the team that is working on it.

Also popular now: