Technical Debt

par Derek Huether

La dette technique et la dette de design sont des métaphores synonymes se référant aux conséquences finales d’une pauvre architecture logicielle et d’un développement logiciel à la va vite. La dette de code se réfère à la dette technique dans un code de programmation de logiciel.

Ward Cunningham a fait la comparaison entre la complexité technique et la dette dans un rapport de retour d’expérience 1992 :

La livraison du premier code ressemble au fait de s’endetter. Une petite dette accélère le développement tant est qu’elle soit remboursée promptement par une réécriture … Le danger se présente lorsque la dette n’est pas remboursée. Chaque minute passée sur du code pas tout à fait exact s’ajoute alors aux intérêts de cette dette. Des organisations entières d’ingénierie informatique peuvent parvenir à un blocage total sous le poids des dettes d’un développement non consolidé qu’il soit orienté objet ou pas.

Les développements réalisés en amont dans le projet peuvent augmenter le coût “du remboursement de la dette” à l’avenir. Une équipe devrait saisir les occasions, sur une base régulière de rembourser (ou régler) cette dette. Réservez un pourcentage de votre cycle de développement ou dédiez un cycle entier pour compléter ce travail. Si vous ne le faites pas, il reviendra vous hanter. Si votre bidouille de solution ne revient pas pour mordre l’équipe de développement, elle hantera probablement le « help desk », l’équipe de support, ou quelqu’un d’autre en aval.

Comme toute dette, vous vous trouvez devant l’obligation de la rembourser tôt ou tard. En tant qu’ancien Manager de Génie logiciel et maintenant que conseiller auprès de mes clients, j’ai vu (et vois) ce que la dette technique peut avoir comme impact sur la vélocité d’une équipe. Elle les prive de temps précieux, après coup. L’équipe de développement achète l’idée que faire les choses de la mauvaise manière, fait gagner du temps dans l’intérim et que cela justifie les risques et le coût total. C’est vraiment un processus de pensée à court terme. La dette technique ressemble à l’obtention d’un prêt d’usurier qui jetterait les dés pour décider de votre taux d’intérêt. Aussi, si vous n’êtes pas absolument obligés de prendre le risque, ne le faites pas.

Soyez honnête avec votre client, votre équipe et vous-même. Évaluez votre travail et tenez vos estimations. Ne laissez pas quelqu’un d’autre vous dire combien de temps il faudra pour livrer un travail de qualité. Si vous y êtes forcés, vous devrez juste délivrer moins de travail. Donc, ne prenez pas de dette en premier lieu.

Plus sur la dette technique sur Wikipedia