Depuis quelques années, le vocable "dette technique" est à la mode. Dans le langage commun du développeur, ce terme est synonyme de tout ce qui ne lui plaît pas dans le code, et que le méchant management ne lui laisse pas changer. Les causes d'insatisfactions sont nombreuses, ceci allant du non-respect des "bonnes pratiques" jusqu'au #cépamoderne en passant par la volonté de faire de la compta en virgule flottante. Pourquoi ce nom de dette technique ? On se verra répondre que si on ne le fait pas (sous-entendu, le bien), alors on le paiera plus tard. Soit. Mais selon quelles modalités ? Est-ce grave de payer plus tard si cela est sans frais ? La modernité dans la tech ayant une durée de vie de six mois, est-ce qu'il ne vaudrait pas mieux attendre ? Devant une telle définition de la dette technique, on est effectivement tenté de répondre avec une locution à peu près aussi définie : un tiens vaut mieux que deux tu l'auras.

On peut se demander si cette expression est arrivée à être diffusée uniquement sur sa proposition de "boîte à contrariétés". La réponse est évidemment non, sinon on ne serait pas dans la série des affordances trompeuses. Presque vingt ans après avoir créé cette métaphore, Ward Cunningham l'explique très bien dans cette courte vidéo. Celle-ci n'ayant pas de sous-titres français, et devant l'absurdité de regarder une image mouvante pour ce qui tient en quelques lignes, je vous en propose ici une transcription traduite.

J'ai commencé à m'intéresser à la façon dont les métaphores influencent notre façon de penser après la lecture de "Metaphors We Live By" de George Lakoff et Mark Johnson. Une idée importante est que nous raisonnons par analogie avec les métaphores qui sont entrées dans notre langage.

 

J'ai inventé la métaphore de la dette pour expliquer la refactorisation que nous faisions sur le produit WyCash. C'était un produit développé en Digitalk Smalltalk et il était important pour moi que nous reflétions les connaissances acquises à propos de l'application au cours du temps, en modifiant le programme pour qu'il ait l'air d'avoir été écrit comme si nous avions eu cette connaissance depuis le début, et comme si c'était la façon naturelle de le faire en Smalltalk.

 

L'explication que j'ai donné à mon chef, et on parle de logiciel dans le domaine de la finance, était une analogie financière que j'ai appelée la métaphore de la dette, qui dit que si l'on échoue à aligner notre programme avec ce que l'on a compris de la bonne façon de penser nos objets financiers, alors nous allions continuellement buter sur cette divergence, et que cela nous ralentirait de la même manière que de payer les intérêts d'un emprunt.

 

En empruntant de l'argent vous pouvez faire des choses plus vite que sans, mais jusqu'au remboursement complet, vous payez des intérêts. Je pensais qu'emprunter de l'argent était une bonne idée. Je pensais que se dépêcher de sortir le logiciel pour avoir de l'expérience avec était une bonne idée mais, évidemment, vous devez finalement revenir en arrière et, à mesure que vous apprenez des choses sur ce logiciel, vous allez rembourser cette dette en refactorisant le programme pour refléter cette expérience acquise.

 

Je pense que dans de nombreux cas les gens se dépêchent de sortir le logiciel et n'y réintègrent pas cet apprentissage, et par analogie, ont emprunté de l'argent sans avoir l'intention de le rembourser. Il va sans dire que si vous faites ça avec votre carte de crédit, à la fin toutes vos rentrées d'argent partent dans les intérêts, et votre pouvoir d'achat est nul.

 

Dans le même ordre d'idées, si vous développez un programme pendant longtemps en ne faisant qu'ajouter des fonctionnalités, et que jamais vous ne le réorganisez pour refléter votre compréhension de ces fonctionnalités, alors il arrivera un moment où il n'y aura plus de cohésion dans le programme, les efforts pour travailler dessus prendront de plus en plus de temps. En d'autres termes, les intérêts occuperont toutes vos rentrées et vous ne progresserez plus.

 

Beaucoup de personnes, tout du moins de bloggueurs, ont expliqué la métaphore de la dette en, je pense, la confondant avec l'idée que l'on peut écrire vite-fait du code avec l'intention de faire mieux plus tard, et que ceci était la première cause d'endettement. Je ne suis jamais pour écrire du code vite-fait, je suis pour écrire du code qui reflète votre compréhension présente d'un problème, même si cette compréhension est incomplète.

 

Si vous souhaitez vous endetter en développant un logiciel que vous ne comprenez pas complètement, alors il est sage de faire un logiciel qui reflète au mieux votre compréhension. Quand le temps de la refactorisation arrive, cela permet de voir clairement ce que vous pensiez alors et ainsi de rendre plus facile la transformation en ce que vous pensez désormais.

 

En d'autres termes, cette métaphore de la dette, ou de la capacité à rembourser la dette, pour qu'elle puisse fonctionner pour vous, dépend de votre capacité à écrire du code suffisamment propre pour pouvoir être refactorisé une fois que vous aurez compris le problème.

 

Je pense que c'est une bonne méthodologie qui est au cœur de l'eXtreme Programming. La métaphore de la dette est une des nombreuses explications au fait que l'eXtreme Programming fonctionne.

La dette technique actuelle est donc une version allégée, fade et sans réel intérêt, de la métaphore de la dette de Cunningham, qui est, elle, une justification de l'amélioration continue appliquée au développement logiciel, en partant du principe que si l'on n'a pas la compréhension nécessaire pour finir la conception, on peut quand même développer le logiciel (en s'endettant), à condition de revenir sur cette conception une fois que cette compréhension est acquise (remboursement de la dette). La métaphore de la dette est une question de gestion de la connaissance.

Vous pouvez trouver le reste de la série sous l'article d'introduction.