Dette technique

Tel est le cauchemar des développeurs d'aujourd'hui. On entend la formule dans toutes les bouches, sur presque tous les projets, et elle est la cause de tous les maux qui pénalisent l'efficacité des développements. A moins que ce ne soit l'excuse préférée des développeurs qui se retrouvent face à leurs inavouables négligences.

Le terme est si utilisé de nos jours qu'il semble recouvrir des réalités très différentes qui désignent toutes un problème de non-qualité logicielle qui pénalise la productivité des équipes. Pourtant, l'usage fréquent du terme est assez récent ; pour avoir travaillé plus de 23 ans dans le développement logiciel, je pense n'avoir entendu le terme pour la première fois qu'au milieu des années 2010. Et je doute que nos problèmes de qualité logicielle datent de cette époque. En réalité, l'origine de la formule est attribuée à Ward Cunningham dans une publication datant du 26 mars 1992.

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

OOPSLA '92

La définition proposée par Cunningham évoque un compromis qui n'est étranger à aucun développeur : celui de devoir livrer dans les temps en acceptant d'implémenter une solution qui ne correspond pas aux standards de qualité que s'est fixée l'équipe. L'analogie de la dette joue à mon sens sur trois points :

• La décision d'accepter le compromis,
• L'engagement pris de rembourser,
• La pénalité subie en cas de non-remboursement.

Pourtant, je ne suis pas certain que tous les problèmes de non-qualité qu'on rencontre sur les projets de développement logiciel cochent ces trois cases.

Accepter le compromis

L'essentiel des problèmes de non-qualité sur les développements logiciel n'entre pas dans la définition de la dette technique sur la base de ce premier critère. De nombreuses équipes introduisent des défauts de structure ou de qualité sans même en avoir conscience. Il n'y a donc pas d'acceptation consciente du problème ; pas de mise en balance entre le problème et le bénéfice qu'on escompte à l'accepter temporairement, pas de compromis. Juste une erreur. Ce n'est que rétrospectivement que l'équipe caractérise de "dette technique" un tel défaut de qualité qui a été introduit involontairement. J'évoquais plus haut cette non-qualité comme une solution ne correspondant pas aux standards de qualité que s'est fixée l'équipe. Bien souvent, ce qui est perçu comme de la dette rétrospectivement fait l'hypothèse que les standards ont toujours été ceux avec lesquels on juge une solution aujourd'hui et que l'équipe était alors consciente de ce niveau d'exigence. A mon sens, n'ayant pas eu à juger de l'acceptabilité d'un compromis, on ne peut pas qualifier une telle situation de dette ; le terme anglais de "legacy", portant cette idée d'un défaut de qualité hérité du passé, est probablement mieux adapté à la situation.

La bonne et la mauvaise dette

La notion de compromis, évoquée ci-dessus, induit un bénéfice immédiat au moment où la dette est contractée. On est donc ici dans une logique d'investissement. L'exemple classique est celui du respect d'une échéance calendaire. La justification de "céder" aux contraintes planning peut alors prendre plusieurs forme : de la simple raison contractuelle (par exemple éviter des pénalités de retard ou atteindre un jalon de paiement) au bénéfice du projet (par exemple avoir un retour utilisateur sur une fonctionnalité avant de se lancer dans un développement complet). Comme dans de nombreuses situations, l'intention est déterminante ; parce qu'on peut aussi accepter la dette pour des raisons moins justifiables, céder à la facilité ou renoncer devant la difficulté.

il y aurait donc une bonne et une mauvaise dette technique. Si on en revient à la métaphore de la dette financière, on pourrait comparer l'emprunt immobilier au crédit à la consommation. Si vous empruntez à votre banquier pour acheter votre propre logement et quitter une situation de locataire, on peut estimer qu'il s'agit d'un investissement. Si vous faîtes un crédit à la consommation pour vous acheter le dernier IPhone alors que votre téléphone fonctionne encore très bien, la logique d'investissement est moins évidente.

S'engager à rembourser

Le second point qui permettrait de qualifier un compromis de dette technique est celui de l'engagement à rembourser. Dans le cas d'un emprunt bancaire, c'est une condition non négociable. Et si vous empruntez à un ami, j'espère que vous le faites aussi avec cette intention. Mais dans le développement logiciel, on a parfois conscience de faire localement un choix non conforme aux standards de qualité sans pour autant prendre l'engagement moral tacite envers l'équipe de revenir sur l'implémentation La raison pour laquelle on pourrait légitimement faire un choix "a priori" non conforme sans intention de revenir dessus découle de la difficulté à positionner le curseur entre non-qualité, juste-qualité et sur-qualité.

Prenons l'exemple de la duplication de code. Le principe DRY (Don't Repeat Yourself) est assez largement admis comme une bonne pratique ; on peut trouver quelques exceptions à l'application systématique de cette pratique (cf. Let It RAIN on this DRY land) mais certains s'affichent ouvertement contre l'application du principe ; il lui préfèrent le principe WET (Write Everything Twice). L'idée est de considérer que généraliser à partir de deux blocs de code identiques est prématuré et qu'il est préférable d'attendre une troisième opportunité pour disposer d'un recul suffisant pour cerner ce qui est réellement récurrent. Dans ce cas, un développeur qui duplique sciemment un bloc de code et ne s'engage pas à le mutualiser, ne contracte pas véritablement de dette technique alors même qu'il contrevient à un principe établi.

Suivre la dette

On associe souvent le suivi de la dette technique avec les mots clés TODO et FIXME qui introduisent des commentaires permettant respectivement d'indiquer qu'une partie du code est incomplète ou qu'un bloc de code est dysfonctionnel dans certains cas de figure. Inscrire ces commentaires répond parfaitement aux deux premiers point discutés ici : le compromis conscient et l'intention de rembourser.

On pourrait presque introduire un mot clé supplémentaire qui serait REFACTOR pour adresser une dette de structure sur un comportement conforme et complet. En général, on utilise le mot clé TODO pour ces cas de figure.

Les intérêts de la dette

Le troisième point évoqué en début d'article concerne les pénalités subies en cas de non-remboursement de la dette. Et je pense que c'est ici que l'analogie touche à ses limites.

Certes, intervenir sur un élément de code mal conçu vient grever l'efficacité de l'apport des changements. C'est le sens des intérêts ou des pénalités de la dette technique ; le coût du changement est plus important. La préconisation "Make the easy change to make the change easy" est, d'une certain manière, une façon d'adresser la dette pour se prémunir de ses effets négatifs : autrement dit, si on intervient sur un élément pour lequel on a contracté une dette technique, il est important de rembourser la dette avant de procéder au changement visé.

Mais si on n'a jamais à intervenir sur un élément de code pour lequel on a contracté une dette technique ? Dans ce cas, les intérêts de la dette ne se manifestent pas. Et c'est là une différence importante avec une dette financière contractée auprès d'une banque ; dans tous les cas, vous paierez des intérêts.

Ainsi l'engagement pris de rembourser la dette est conditionné par la nécessité de faire évoluer les éléments concernés. Cette remarque ne doit pas être prise pour autant comme un blanc-seing pour contracter immodérément de la dette technique. L'équilibre du compromis initial et l'intention de rembourser "le moment venu" restent importants ; mais on peut ne jamais rembourser et ne jamais en être pénalisé.

Dettes et Risques

Le concept de dette technique peut ressembler en de nombreux points à celui de risque technique. Un risque est caractérisé par une cause, qu'on peut associer au défaut de qualité d'une dette, par un effet, qu'on peut associer aux intérêts de la dette, par une probabilité d'occurrence, qu'on peut associer à la probabilité de devoir intervenir sur le code endetté, et par un plan de mitigation, qu'on peut associer au remboursement de la dette.

Cette comparaison me semble néanmoins dangereuse parce qu'elle peut inviter le développeur à se comporter comme un joueur de casino : en pariant que la dette qu'il contracte ne devra jamais être remboursée. Mais la différence essentielle entre le risque et la dette tient à l'origine externe de la première et l'origine interne de la seconde. Un risque est en effet lié à un événement externe à l'équipe de développement et sur lequel elle n'a qu'une emprise limitée. Pour la dette, la situation est différente puisque le compromis est envisagé et accepté par l'équipe. Autrement dit, le risque est subi par l'équipe qui ne peut que décider d'accepter, d'éviter ou de mitiger. Alors que l'équipe est responsable de son endettement.

Software Craftsmanship

La dette technique n'est jamais souhaitable mais elle est parfois acceptable. Pour qu'elle reste acceptable :

• Elle doit être contactée de manière consciente, Il est donc essentiel d'éveiller et de renforcer la sensibilité des développeurs aux questions de qualité logicielle.
• Elle ne doit pas faire l'objet de paris sur l'avenir du projet. Une telle posture est vouée à l'échec et n'est pas éthique.

Qu'il s'agisse de sensibilisation à la qualité logicielle ou d'éthique professionnelle, la question de la dette technique est incontestablement un sujet sur lequel le Software Craftsmanship a un message à porter.

Image titre de Chris Potter distribuée sous licence CC BY 2.0