Management of technical debt
Technical debt in development is perceived differently by developers and businesses. For the former, this is an important part of the work, which needs to be allocated time. For others, as a rule, it is an irrational expenditure of man-hours. Management of technical debt is rarely organized and on a regular basis. And it is here, in my opinion, that the key to resolving the conflict between business and development is buried. This is exactly what I want to talk about today.
Technical obligation
Technical debt (technical debt, tech debt) is a part of the unfinished project work that does not affect the current functionality, but is necessary for the long-term stability of the system and the ease of adding new functionality in the future.
How can a technical obligation arise? I highlight the main sources:
-
Deliberate simplification of the service being developed, which leads to divergence from the planned architecture. Such simplification can be caused by tight deadlines, incompetence of developers and external constraints.
-
Errors in design. The architecture does not reflect the necessary business processes to the required extent, or other requirements are not taken into account: load, resistance to failure, etc.
-
Change in service requirements that lead to the formation of technical debt. Everything that does not evolve eventually dies. This also applies to information systems. New, more convenient versions of libraries, frameworks, new metrics collection systems, etc. appear. Architects and technologists conduct research and propose new solutions that improve the development process. Requirements for the implementation of new solutions lead to the appearance of technical debt.
-
Operation of static code analyzers (IDE, CI/CD), linters (CI/CD). They form a set of considerations for safety, efficiency, style, etc.
-
Flaws were identified during the code review. For example, an architect or engineer analyzes existing designs and makes suggestions for improving the architecture. Formed comments/recommendations form a technical obligation.
Management of technical debt
How to manage technical debt? The main rule here is to try your best to avoid its appearance. If it is unavoidable, be sure to have a separate story for the technical debt of the project, and immediately at the moment of decision-making or implementation, which entails the appearance of technical debt, formalize it in the form of tasks within the story. Be sure to estimate completion dates and time required for a decision. In the future, it will be easier for you to have a dialogue about prioritizing and allocating resources to close the technical debt.
How to avoid the appearance of a technical obligation? To prevent chaos, it is better to have a regulation and follow it. Here are some tips for managing technical debt that I follow myself:
-
Use available static code analysis systems, linters, and other automatic checking mechanisms. This will prevent the codebase from degrading over time.
-
Make it a rule to conduct a mandatory code review by several colleagues before accepting a merge request.
-
Regularly conduct a project architecture review by an architect or technical lead.
-
Plan to update dependencies in your code: newer libraries, etc. Create tasks and estimate deadlines. Do this work systematically.
-
Maintain up-to-date documentation. To do this, simultaneously with the development task, create a documentation update task. In addition, regularly review the relevance of documentation (for example, once a quarter).
Continuous Inspection
Separately, it is worth mentioning a fairly common concept. Continuous code inspection (Continuous Inspection). It is a list of postulates that help manage technical debt. Let’s list them:
-
Code quality is a common task. The entire development team is responsible for maintaining the code base in good condition.
-
Relevance of information. Information about the status of the codebase should be updated regularly for quality assessment.
-
Quality data should be in both absolute and differential values. That is, we should be able to evaluate the change from version to version, from week to week, etc.
-
Quality control should be automated. The more automation, the better. This reduces the human factor of omissions when revising the code.
-
Quality standards should be uniform for all projects. Standards can vary from company to company and team to team. But they must exist, be regulated and communicated to all involved. You can update them taking into account the wishes of all team members, but the decision to change is better made collegially. As they say, one head is good, and two (or more) is better.
-
All new comments must have a responsible person. Each detected comment must be assigned to a specific developer. Do not wait for the result without someone responsible.
Conclusion
Dealing with technical debt is a systemic long game. It is designed to prevent development team productivity from declining over time. For businesses, it is important to understand that the cost of system development support will increase over time. And the greater the amount of technical debt, the more difficult and expensive it will be to develop new functionality and correct errors in the current one. It is necessary to work with technical debt in a planned manner, to have regulations and a general understanding of all involved participants.
I talk about how to design and create systems, the cost of maintenance and development of which does not increase over time, in my telegram channel solonkov.team. There you can find audio versions of articles, ask questions that interest you, and ask for advice.