Technical debt is an analogy to bank loans to represent the fact that the more we generate non-quality during a project, the higher the costs of recovery will be important.
The expression “Technical Debt” is a metaphor created by Ward Cunningham, one of the signers of the Agile manifesto, analogous to bank loans. :
A loan consists of the capital we have borrowed and the associated interest. Our monthly payments are used to repay capital on the one hand and interest on the other. The challenge, of course, is to repay capital as quickly as possible to reduce interest.
By analogy with project development, capital represents added value, and interests represent the different occasions to correct problems or increase maintenance to resolve outages. These interests are what Ward Cunningham calls technical debt
The concept of technical debt
In a context where we always want to go faster and where we have to deliver at the earliest, teams are sometimes tempted to make decisions allowing them to accelerate the process by making good practices, creating a “debt”. These temporary deviations, the teams will have to correct them. But because these sprains are not visible to the client, it is up to the teams to manage and treat them. This is the sum of these sprains that we call the technical debt. 2 definitions of known authors :
- Selon J. Shore : Technical debt is the sum total of imperfections.
- Selon T. Poppendieck : Technical debt is all that makes the code more complex to change.
A development team is late. To go faster, instead of developing specific code and lightweight, the team chose to copy and paste a code from another program that matches, but we know that it will be more difficult to maintain. We thus contract a technical debt that we will “repay” throughout the life of the project in the form of additional work time to resolve the bugs.
Manage the technical debt
Accumulating debt is not, in fact, serious if we take into account the fact that it will have to be remedied sooner or later. In the management of agile projects, technical debt is therefore one of the indicators for managing projects. On the dashboard, we find the following indicators :
- % Backlog livré : 80%
- Consumed load : 150 days/man
- Velocity : 20 Story Point per Sprint
- Technical debt : 34 days/man
Taking this example, the project manager realizes that he still needs to plan 37.5 man-days to finish delivering the Backlog and 34 days to process the technical debt, ie a total of 71.5 man/days..
Types of technical debt
Author Martin Fowler proposes a classification of the different types of technical debt. This grid helps us to define the necessary resources and guides us in the choices we have to make during the project.
The ordinates : Volunteer vs. Involuntary
A first axis is representative of our level of intentionality in our choice of debt. Most of the time, we generate a natural involuntary debt due to the fact that we never work perfectly and we generate defects. Lack of technical knowledge or poor communication within a team are the most common causes.
But on the other hand, sometimes we do express to make a debt-generating choice.
The abscissa: Prudent vs. Risky
The second axis identifies our level of debt control both in terms of the identification of the workload to reduce it and the difficulties in solving it. Clearly, at least we master the choices we have just made, the more we are in a situation at risk.
Reduce the technical debt
Understandably, the challenge is to minimize the technical debt to avoid the payment of “interest”. Some good practices :
Refactoring is about constantly reviewing our work to improve it. It is a question of constantly reviewing the work done to standardize it with what we know best (principle of Yokoten), delete what ultimately is useless … In short, make it as light as possible.
Specific method to software development, this involves developing to two behind a single screen. Often criticized for the cost involved, this practice has many advantages: increased quality of work, reduced recovery and maintenance costs.
It is recommended to use this method for complex developments and pairing Junior / Senior to promote knowledge sharing.
The design review
This practice consists of exchanging, discussing and comparing the different design choices with the entire team. The challenge being to challenge each other to find out if we made the best choices.
M. Fowler (2009) – Technical debt
K. Brown (2010) – Paying back technical debt
S. McConnell (2007) – Technical Debt