Technical debt management

Technical debt in development is perceived differently by developers and businesses. For the first, this is an important part of the work that needs to be allocated time. For the latter, as a rule, it is an irrational waste of man-hours. It is rare that technical debt management is done in an organized and regular manner. 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 debt increases development costs - each next feature becomes more and more difficult

Technical debt increases development costs – each next feature becomes more and more difficult

Technical debt

Technical debt (technical debt, tech debt) is a piece of project backlog that does not affect 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 technical debt arise? I highlight the main sources:

  • Deliberate simplification of the service being developed, leading to a discrepancy with the planned architecture. This simplification may be caused by tight deadlines, incompetent developers, and external constraints.

  • Design errors. The architecture does not adequately reflect the required business processes, or other requirements are not taken into account: load, fault tolerance, etc.

  • Changing service requirements leading 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 systems for collecting metrics, etc. appear. Architects and technical leads conduct research and propose new solutions that improve the development process. Requirements for the implementation of new solutions lead to the emergence of technical debt.

  • Operation of static code analyzers (IDE, CI/CD), linters (CI/CD). They form a set of comments on safety, effectiveness, style, etc.

  • Defects discovered during code review. For example, an architect or technical lead analyzes existing projects and makes proposals for improving the architecture. Generated comments/recommendations form technical debt.

Technical debt management

How to manage technical debt? The main rule here is to try your best to avoid its appearance. If this is unavoidable, be sure to have a separate user story for the technical debt of the project, and immediately at the moment of making a decision or implementation that entails the appearance of technical debt, formalize this in the form of tasks within the story. Be sure to estimate completion dates and required time to resolve. In the future, it will be easier for you to have a dialogue regarding prioritization and allocation of resources for closing technical debt.

How to avoid technical debt? To prevent chaos from growing, it is better to have regulations and follow them. Here are a few tips for managing technical debt that I follow myself:

  • Use static code analysis systems, linters, and other automatic checking mechanisms available to you. This will prevent the codebase from deteriorating over time.

  • Make it a rule to have your code reviewed by several colleagues before accepting a merge request.

  • Regularly review the architecture of projects with the help of an architect or technical lead.

  • Plan to update dependencies in your code: newer libraries, etc. Create tasks and estimate deadlines. Do this work systematically.

  • Keep your documentation up to date. To do this, simultaneously with the development task, create a task to update the documentation. Additionally, regularly review the relevance of documentation (for example, once a quarter).

Continuous Inspection

It is worth mentioning separately the 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 concern. The entire development team is responsible for maintaining the code base in good condition.

  • Relevance of information. Information about the state of the code base should be updated regularly for quality assessment.

  • Quality data should be in both absolute and differential values. That is, we must be able to evaluate the change from version to version, from week to week, etc.

  • Quality checks should be automated. The more automation, the better. This reduces the human factor of omissions during code reviews.

  • Quality standards must be the same for all projects. Standards can be very different, differ both from company to company and from team to team. But they must exist, be regulated and communicated to everyone involved. You can update them taking into account the wishes of all team members, but decisions about changes are best made collectively. As they say, one head is good, but two (or more) are better.

  • All new comments must have a responsible person. Each identified comment should be assigned to a specific developer. Without someone responsible, don’t expect results.

Conclusion

Dealing with technical debt is a systematic long game. It is designed to prevent development teams from losing productivity over time. It is important for businesses to understand that the cost of support as the system develops will increase over time. And the larger the technical debt, the more difficult and expensive it will be to develop new functionality and fix errors in the current one. Dealing with technical debt must be planned, have regulations and a common 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 also find audio versions of articles, ask questions you are interested in and seek advice.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *