Je dois vous faire un aveu : je me suis toujours méfié de la notion de dette technique. Cela m’a toujours paru un concept marketing.

C’est comme si vous décidiez d’acheter une voiture, que le vendeur vous remette fièrement les clés et ajoute avec un petit sourire : « vous devez déjà 10 000 $ ». Et il ne parle pas du crédit auto, non, il veut simplement dire que la voiture que vous venez d’acheter comporte certains défauts qui vont devenir de plus en plus apparents au fil du temps, fatigueront le moteur, la carrosserie, voire même probablement le conducteur.

Quelle serait votre réaction si un vendeur vous disait cela ? Accepteriez-vous d’acheter cette voiture ?

D’accord, je sais que l’achat d’une voiture, d’une maison, de tout bien coûteux car complexe et long à produire s’accompagne de frais d’entretien, de révision, bref de maintenance. En ce sens, j’aime bien le pouvoir explicatif de l’analogie et d’ailleurs, le développement logiciel a souvent été comparé á la construction d’une habitation.

Mais tout le monde connaît l’histoire : lorsque Ward Cunningham invente ce concept en 1992, il passe relativement inaperçu, tout au moins hors de la communauté des développeurs, jusqu’à ces dernières années où, boum, la dette technique se transforme en une véritable explosion médiatique et vraiment, cela fait peur. Selon Gartner, elle atteignait 500 milliards de $ en 2010 et devrait doubler d’ici à 2015. Avec une telle inflation, elle sera supérieure à la dette souveraine de la Russie en 2020. Quelle angoisse.

La dette technique est un rêve de marketeux parce que :

• C’est technique, donc c’est vraisemblable, et pose en expert celui qui en parle.
• Cela appelle l’attention : vous devez de l’argent – beaucoup – et vous ne le saviez pas.
• Cela se prête à toutes sortes d’exercices et de prolongement très créatifs : plafond de la dette, calcul des intérêts, estimation de point mort, réduction du risque systémique, etc. Très inventive : la notion de code ou d’application toxique. Je me demande s’ils fournissent le masque à gaz aux développeurs.

Comme l’explique Ward Cunningham (Ward Explains Debt Metaphor), il a utilisé la métaphore de la dette technique pour justifier auprès de son patron le refactoring réalisé sur le produit financier qu’ils développaient. En empruntant au début, il est possible d’aller plus vite, mais on doit ensuite payer les intérêts. Comme développer son entreprise : si vous pouvez emprunter, vous pourrez embaucher plus de monde, investir dans plus de points de vente, disposer d’un budget publicitaire, etc. Vous grandirez plus rapidement mais vous ne pouvez pas emprunter continuellement car sinon les intérêts et le remboursement de votre dette finiront par devenir votre principal poste de dépense et vous empêcher toute croissance.

Ward explique également que ses propos ont été repris de manière confuse, pour ne pas dire erronée. Il insiste sur le fait qu’un code doit être écrit correctement dés le départ afin de permettre ensuite le refactoring. Emprunter ne signifie pas écrire du code de piètre qualité afin de sortir l’application en temps et en heure malgré les retards du projet ou les erreurs de planning, sinon développer rapidement des versions fréquentes (Extreme Programming) et inscrire le refactoring du code dans le cycle de vie du projet.

Ward Cunnigham est un développeur qui, comme il l’explique lui-même, a utilisé le concept de dette technique en tant que métaphore. Il existe 2 types de métaphores :

• Celles au pouvoir descriptif, qui permettent de comprendre un concept par l’illustration, la comparaison avec un autre concept.
• Celles au pouvoir prédictif, qui permettent de prédire un certain comportement et de découvrir de nouvelles lois.

Par exemple, on vous demande d’expliquer ce qu’est un atome. Vous pouvez effectuer une analogie avec une planète qui tourne autour de son soleil, tel des électrons autour de leur noyau. Ce serait une analogie du premier type.

Si maintenant vous décidez de construire une modélisation d’un système solaire, en un ensemble d’objets (planète, soleil), d’attributs (masse) et de relations (attraction), et si vous utilisez celle-ci pour en déduire une nouvelle modélisation entre les électrons et leur noyau qui permette de prédire leur comportement, alors il s’agira d’une analogie du second type.

La métaphore de Ward Cunnigham est un outil explicatif très puissant, mais il ne s’agit pas d’une modélisation dont on pourrait tirer de nouvelles lois. Son intérêt principal réside dans l’idée d’inscrire le refactoring de manière continue dans le cycle de vie d’une application. Prétendre qu’il est possible de chiffrer la dette technique, de calculer son coût à la ligne de code, d’évaluer les intérêts de cette dette afin d’estimer à quel point de la courbe celle-ci devient trop lourde, c’est du marketing.

D’ailleurs, ce n’est pas innocent si les chiffres avancés sont généralement effrayants et en croissance d’une année sur l’autre. Pourquoi croyez-vous que votre application de 300 000 lignes de code présente une dette technique d’1 million de $ avant même que qui que ce soit se penche dessus et regarde quel est vraiment son niveau de non-qualité ? Combien seriez- vous prêt á dépenser pour réduire cette dette ? 100 000 $ ? 200 000$ ?

Les développeurs l’ont bien compris. La dette technique représente :

• L’idée que le code doive être régulièrement refactorisé afin de limiter la non-qualité á un niveau acceptable
• Un indicateur intéressant qui introduit une notion d’effort et de coût de correction.

Si vous avez le choix entre corriger un défaut critique pour un coût très bas et corriger un défaut peu important pour un coût élevé, vous n’allez évidemment pas hésiter très longtemps.
A ce titre, la dette technique peut constituer un outil d’aide à la décision, mais en n’oubliant jamais qu’il ne s’agit pas d’un vrai coût financier et en sachant l’interpréter correctement. Quelques exemples.

Vous pouvez utiliser la dette technique comme indicateur au sein d’un SLA pour un fournisseur, mais de manière différente selon la nature des développements :

• Nouveau développement : une dette technique nulle n’aurait pas de sens, toute nouvelle application même très bien écrite comportera forcément un minimum de composants très complexes ou volumineux ou avec beaucoup de liens entre eux. Il faut simplement faire en sorte que leur nombre reste raisonnable. Vous définirez donc avec votre fournisseur un niveau de dette technique qu’il ne doit pas dépasser.
• Maintenance : votre fournisseur n’est pas responsable de la dette technique existante sur une application développée par quelqu’un d’autre que lui. Il doit simplement éviter que celle-ci ne devienne plus importante. Ici, pas question de fixer un seuil de dette technique à ne pas franchir sinon éviter de faire croître celle-ci. Vous pouvez même inciter votre fournisseur á la diminuer á l’aide de bonus.

Alignez votre dette technique sur vos objectifs IT, eux-mêmes alignés sur les objectifs de l’entreprise. Nous l’avons déjà vu dans le post ‘Best of both worlds’, une politique de tolérance zéro pour des violations de performance n’a pas de sens lorsque le plus important consiste á ne pas dépasser les budgets. A l’inverse, si l’argent n’est pas un problème mais que l’application doit fonctionner correctement en temps et en heure, les défauts en matière de performance et de robustesse et le time-to-market deviennent critiques. Construisez vos plans d’action en fonction des objectifs, puis ensuite seulement en fonction de la dette critique, pas l’inverse.

Laissez suffisamment de latitude aux équipes de projet pour décider d’eux-mêmes des actions de refactoring, mais définissez avec eux un objectif en matière de dette technique et incluez-le dans une Quality Gate. Généralement, les développeurs seront efficaces en ce sens qu’ils optimiseront leurs actions de refactoring en corrigeant les défauts les plus graves mais les moins coûteux en charges de travail. Cela suppose néanmoins qu’ils soient outillés pour pouvoir évaluer la dette technique. Sur ce point, voir notre post ‘10 to 20 metrics’.

Ce ne sont là que quelques exemples simples, basés sur nos précédents posts. Il en existe beaucoup d’autres, et peut-être aurons nous l’occasion de les détailler dans le futur.

La dette technique est une mesure intéressante qui permet d’objectiver la relation avec vos fournisseurs et les équipes de projet. C’est un indicateur d’un ordre de grandeur en matière d’effort pour maintenir la non-qualité à un niveau raisonnable.

Par contre, évitez de considérer la dette technique comme un coût financier réel á prendre en compte dans vos décisions de projet et d’investissement. C’est un concept de développeur pour les développeurs, pas pour les marketeux.

Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.