Styles

lundi 2 juin 2008

Dette technique - Technical Debt

C'est bien connu, une chose n'existe pas tant qu'elle n'a pas de nom. L'informatique, discipline pas si jeune que ça, n'échappe pas à la règle même si certains ont tendance à oublier certains noms pour en faire apparaître de nouveaux.

Voici un terme qui a l'avantage de mettre en avant un fléau difficile à cerner de notre discipline : la dette technique. Il s'agit de mettre un nom sur une pratique généralisée dans le métier et qui constitue le principal problème de maintenance des systèmes informatique. Une traduction de l'entrée wikipedia sur le sujet pourrait être résumée ainsi :
La dette technique est un terme inventé par Ward Cunningham pour décrire une situation où l'architecture d'un système logiciel est conçue et développée trop précipitamment. L'analogie avec une dette financière vise à montrer que du code écrit médiocrement requiert le "paiement d'intérêts" par un effort de maintenance, qui serait plus petit ou inexistant si le code fut développé plus soigneusement et avec une planification à plus long terme. Rearchitecturer et réécrire le code pour être plus maintenable est analogue au paiement de cette dette.
L'objectif d'une telle métaphore est bien de communiquer à des personnes qui n'ont pas de bagage technique mais qui sont pourtant en charge de l'allocation des budgets informatique, un problème essentiellement visible du développeur/architecte. La communauté des développeurs/architectes a tout intérêt à faire ressortir ces coûts dans l'objectif d'améliorer la qualité des logiciels et de rendre plus intéressant et utile la profession d'informaticien.

Cet article de scrumalliance.org montre bien la dette technique sur un graphe :


Mais un frein à la diffusion de cette information est le flou autour de ces coûts car la dette technique est à la base de la forte rentabilité des société de service en ingénierie informatique. Une SSII a tout intérêt a construire une application peu chère mais avec une forte dette technique pour qu'elle puisse continuer à faire de la marge sur la maintenance du système.

Je ne veux pas jeter la pierre aux sociétés de service, c'est grâce à elle qu'il y a tellement de travail dans ce domaine. Et puis on ne peut pas reprocher à une entreprise de viser la rentabilité maximum puisque c'est sa nature même.

Une des difficultés pour apprécier correctement la dette technique est la durée sur laquelle la dette va devoir être payée. Bien souvent la dette s'étale sur des années, souvent bien après la première livraison du logiciel. Sur plusieurs années, l'équipe de développement (ainsi que toutes les personnes autour) a du changer, voire même plusieurs fois.

L'article de Steve McConnell sur le sujet est bien instructif. Il essaie de classer les types de dette technique et d'en définir les aspects. Notamment le fait qu'on doit un jour ou l'autre rembourser ses dettes :

Une des plus importantes implications de la dette technique est le fait qu'elle doit être remboursée, i.e., une fois que vous avez contracté une dette, il y aura des intérêts à payer.
Si la dette grossie suffisamment, la société finira par dépenser plus pour le remboursement de sa dette qu'elle n'investira dans la croissance de la valeur de son capital. Un exemple typique est une base de vieux code ("legacy code") sur lequel il y a tant de travail pour maintenir le système en état de marche (i.e, "pour rembourser la dette") qu'il reste très peu de temps pour ajouter de nouvelle fonctionnalités au système. Avec une dette financière, les analystes parlent de "taux d'endettement", qui est égal à la dette totale divisée par l'ensemble du capital. Des taux d'endettement élevés sont vus comme étant risqués, ce qui semble également vrai pour la dette technique.
Ce qui est intéressant dans cet article, c'est l'idée qu'il peut être raisonnable de contracter une dette technique, pour des raisons commerciales notamment, chose que les développeurs ont du mal à comprendre. L'important est d'en avoir pleinement conscience et de rembourser un jour la dette pour qu'elle ne vous rende pas insolvable !

Le mieux, peut-être, pour faire apparaître la dette technique est de saisir un nouveau "bug" de type "dette technique" dans le système de suivi des défauts, portant sur ce qui n'a pas été fait correctement au niveau technique mais qu'il faudrait réaliser plus tard. Et puis, se fixer ensuite une règle du style : toute dette technique de plus de 90 jours doit être remboursée. Ce système de suivi de la dette peut être fait non seulement au niveau du code mais aussi au niveau de chaque activité du projet de développement sur laquelle un raccourci ou un compromis a été réalisé.

Enfin, la dette technique ne se retrouve pas uniquement en informatique mais dans tout domaine technique où un compromis sur un produit en augmente le coût de maintenance à plus ou moins long terme.

Suivez-vous votre dette technique ? Et de quelle manière ? Ou, trouvez-vous cela complètement inutile ?

Aucun commentaire: