La dette technique, poison et antidote
Pour répondre directement à la question : dans un logiciel, la dette technique c’est ce que le concepteur n’a pas fait proprement et qui apporte de la complexité.
A chaque livraison, à chaque sprint, on peut constater que l’architecture du logiciel devient un “gros tas de boue” (big ball of mud) : du code métier est mélanger avec du code technique; le framework qu’on utilise pour gérer la persistance des données est présent même dans la couche de l’IHM; etc. Cette complexité s’accroit et va avoir de lourdes conséquences sur la vie du logiciel.
Et si ça fonctionne, peu importe, non ?
Tout est question de gestion du patrimoine logiciel. Si l’application est “jetable”, touche un nombre très restreint d’utilisateurs sur un domaine non critique pour les revenues de l’entrepritse, alors on peut choisir de ne pas s’en inquiéter.
Malheureusement, la plupart des applications ne sont pas jetables. Même si elles le sont au départ dans l’esprit de leur concepteur, elles perdurent. Même une application prototype commence par une petite idée, un petit bout de code vite réalisée, essayée, adoptée. Sur ce “petit bout” de code, on construit plus de fonctionnalités. L’application grandit. Elle n’est plus jetable.
Jusqu’au jour où plus personne ne s’y retrouve :
- Les programmeurs ne veulent plus travailler dessus (bad smell).
- Chaque ajout de nouvelle fonctionnalité coute plus de temps à être évaluée (à cause du risque de régression) avant d’être implémenter (autre bad smell).
- Un jour, toute l’équipe est d’accord pour dire qu’il faut tout casser pour tout refaire.
Imaginons la réaction d’un investisseur en immobilier à qui on annonce 5 ans après la construction de son immeuble : il faut le raser et tout refaire. Inimaginable ! Pourtant tous les jours, dans des entreprises à travers le monde, on ne doit pas être loin de cette réalité et c’est ce qu’on annonce à ceux qui ont investi dans une solution informatique.
La cause de tout ça : une dette technique non maîtrisée.
Comment exprime-t-on la dette ?
Les 2 principaux chiffres à suivre sont : la dette technique elle-même, les intérêts annuels. Les 2 sont exprimées en temps : heure, jours, mois, …
La dette technique exprime le temps nécessaire à corriger la complexité du code, à la faire passer à un niveau acceptable.
Les intérêts annuels expriment l’impact en durée de cette dette sur les développements. Cette complexité rend l’implémentation de nouvelles fonctionnalités plus difficiles.
Au finale, il est facile de multiplier le temps par le coût horaire des programmeurs pour traduire cette dette en une unité bien connue de tout manager : l’euro !
Que faire ?
La dette technique est un poison mais l’antidote existe. Même si la situation semble désespérée, il est possible de s’en sortir; même sur des logiciels âgés (legacy software).
Voici les 2 actions à mener:
- créer des tests couvrant les parties de code qui sont problématiques. Ceci a un impact direct sur l’évaluation des intérêts annuels puisqu’un test réduit le risque de faire apparaître une régression.
- réduire la complexité en modifiant le design, l’implémentation. Différentes techniques de refactorisation existent pour atteindre cet objectif. L’existence de tests pour accomplir cette tâche est obligatoire pour obtenir un filet de sécurité et être certain de ne pas avoir introduit de régression en refactorisant.
Bien entendu, il faut commencer par sélectionner les points complexes, réfléchir à une et organiser le travail. Il n’est pas question de faire un travail de re-design au milieu d’un sprint critique !
La volonté managériale, la monté en compétence de l’équipe, et le suivi des mesures dans une approche kaizen permettra de faire baisser la dette technique petit à petit.
Quel profit en attendre ?
Une implémentation de nouvelles fonctionnalités, simplifiée voire possible, là où elle semblait impossible par le passé.
Des programmeurs motivés pour travailler sur cette “vieille” solution que tout le monde fuyait et aurait mis à la poubelle par le passé.
Surtout, des utilisateurs heureux et fidélisés par la mise à disposition plus rapide de nouvelles fonctionnalités utiles à leurs travaux quotidiens.