Vous savez quelle est ma blague préférée sur les consultants ?

Un homme entre dans un magasin d’animaux et voit un singe dans une cage avec un écriteau ‘Singe C – $2 000’. Le propriétaire du magasin s’approche et le client lui dit : « Il est cher votre singe. Qu’est-ce qu’il a de spécial ? ». Et le propriétaire lui explique « C’est un singe qui programme en C. Très bon programmeur, il est rapide, il produit un code de qualité et sans bugs. A ce prix-là, c’est une affaire ».

Le client regarde la cage à côté avec un panneau ‘Singe C++ – $3 000’. « Dites-donc, celui-ci est encore plus cher. Qu’est ce qu’il sait faire ? ». « Même chose que le précédent, mais en C++, un langage orienté objet, plus complexe, mais qu’il maîtrise très bien également, très bon programmeur. Et il connaît un peu de Java aussi ».

Le client voit alors une troisième cage et un panneau ‘Singe – $5 000’. « Ah, celui-ci est aussi cher que les deux autres réunis. Il doit vraiment être très bon. Qu’est-ce qu’il sait faire ? ».

« Et bien, je ne sais pas vraiment » répond le propriétaire. « Mais il dit qu’il est consultant ». (1)

Pourquoi est-ce que je vous raconte cette blague ? Parce que je vois de plus en plus de consultants s’emparer du concept de dette technique avec le souhait, certes louable, de l’actualiser, de le compléter ou de l’améliorer mais aboutissent finalement à le transformer en une théorie générale, peu concrète et d’application incertaine pour ne pas dire impossible.

J’avais déjà écrit il y a quelques mois un post ‘Tecnical debt vs. Marketing guys’ dans lequel je dénonçais les ‘marketeux’ qui, avec beaucoup d’inventivité, étendaient la notion de dette technique à toutes sortes de variantes financières plus effrayantes les unes que les autres. Comme par exemple, le parallèle avec les actifs financiers toxiques : certaines applications seraient toxiques et n’attendraient que le pire moment pour exploser toutes seules avec l’intention de causer le plus de dégâts possibles.

Et je vois de plus en plus de consultants Qualité faire de même, comme dans cette vidéo ‘Technical Debt A Finer Edge‘ dont je vous résume les principaux points :

• La définition de la dette technique introduite par Ward Cunningham en 1992 est archaïque car trop centrée sur le code et les programmeurs.
• Elle doit être actualisée afin de prendre en compte tous les défauts, manques, erreurs, négligences, malpractices survenant dans le processus de production logicielle et le cycle de vie de projet, lors de toutes ses phases (conception, tests, etc.).
• Elle doit prendre en compte également les erreurs de management et les processus incorrects ou insuffisants : estimation des charges, du planning, gestion du risque, etc.).

Cette vidéo reprend un article de Capers Jones ‘The Errors and Hazards of Technical Debt’ dans lequel il définit la dette technique comme les coûts de correction des erreurs commises durant le développement d’une application.

« The essential idea of technical debt is that mistakes and errors made during development that escape into the real world when the software is released will accumulate downstream costs to rectify. »

Les inconvénients résident dans l’absence de prise en compte des défauts de qualité dans la définition de la dette technique : « In order to evolve from a novelty into an effective metric, technical debt needs to encompass all quality costs and not just post-release code changes ».

L’article conclut que la dette technique est seulement une partie des coûts de qualité et que cette dernière mesure (Cost Of Quality ou COQ) est plus appropriée lorsque l’on veut étudier la dimension économique de la qualité.

Dette intentionnelle et dette involontaire

Je suis bien d’accord avec Capers pour dire que la dette technique n’est qu’un élément des coûts de non-qualité mais je ne suis pas d’accord pour qu’on étende la notion de dette technique de manière à inclure tous ces coûts, comme souhaité dans la vidéo précédente.

La notion de dette technique est comprise et interprétée de manière très différente et Ward lui-même s’est expliqué dans cet article ‘Ward Explains Debt Metaphor’ qui vise à éclaircir la confusion habituelle selon laquelle celle-ci est causée par du code de mauvaise qualité.

L’analogie utilisée par Ward est qu’en empruntant, vous pouvez réaliser votre projet plus rapidement, mais qu’à un moment donné, il vous faudra rembourser votre dette. Réaliser une première version prototype est l’équivalent d’un investissement qui permet de livrer quelque chose rapidement aux utilisateurs et donc d’aller plus vite que si vous attendez d’avoir des spécifications fonctionnelles complètes et la phase de développement terminée.

Mais un refactoring sera nécessaire afin de passer du prototype à une version finalisée, et donc ainsi rembourser votre investissement.

Le concept d’origine vise à promouvoir une méthodologie de développement ‘Extreme programming’ basée sur des cycles itératifs, afin de compléter notre connaissance des spécifications fonctionnelles, adapter le design de l’application et engranger de l’expérience (l’équipe de Ward avait décidé de programmer en Smalltalk, un langage objet nouveau pour eux).

Comme l’explique cet article sur le blog de Uncle Bob, ‘A mess is not a technical debt’, la dette technique est un compromis volontaire – livrer rapidement une version 1.0 incomplète – afin de faire face à des contraintes de projet. Un code de mauvaise qualité n’est pas une décision rationnelle, et donc ne relève pas de la dette technique, mais plutôt d’une perte nette.

Mais dans tous les cas, il s’agit bien de refactoring effectué par les développeurs. Et donc comment identifier les modifications réalisées pour améliorer l’architecture du code de celles visant à corriger un défaut ? Un programmeur décide de scinder une classe en deux parce que des fonctionnalités complémentaires nécessitent de spécialiser celles-ci ou tout simplement pour en diminuer la complexité et améliorer la lisibilité du code. Dette technique ou pas ?

Martin Fowler explique dans cet article ‘TechnicalDebtQuadrant‘ que la question importe peu. L’intérêt réside dans le fait que la métaphore est un outil de communication puissant qui permet de justifier auprès des stakeholders et du management un refactoring du code, quelque soit la nature de cette dette technique, délibérée ou involontaire. Un bon développeur connaît les bonnes pratiques de programmation mais peut en omettre certaines, soit volontairement dans l’attente d’une prochaine version, soit par manque d’attention. La perfection n’est pas de ce monde.

Différentes natures de dette

Mais dans tous les cas, quelque soit la nature ou l’origine de la dette technique, ce sont les programmeurs qui gèrent celle-ci. Et c’est bien la raison pour laquelle je considère que cette notion ne doit pas s’étendre à d’autres coûts de non-qualité.

Une erreur ou un oubli dans les spécifications fonctionnelles ou dans la phase de conception vont certes nécessiter de modifier le code, mais l’origine de cette modification ne se trouve pas dans la programmation et les choix ou les manquements aux bonnes pratiques des développeurs.

Un plan de test incomplet ou insuffisant peut résulter d’une volonté du management de livrer le plus rapidement possible un prototype qui permette aux utilisateurs de préciser leurs besoins sans se soucier des bugs, ou au contraire d’un manque de temps, de connaissance ou d’expérience de l’équipe de QA, ou encore d’une documentation incorrecte ou d’un outillage inadéquat.

La métaphore de la dette peut s’appliquer à ces différents exemples, mais dans ce cas, parlons de dette fonctionnelle ou de dette QA, plutôt que de vouloir intégrer à la dette technique tous les coûts de non-qualité.

Autre raison pour laquelle je pense que la dette technique doit s’appliquer au code et aux programmeurs :

• Les bugs qui trouvent leur origine dans le code sont les plus nombreux : environ un sur trois.
• Les défauts de code sont les plus faciles à déceler et à corriger : environ 85% et ce chiffre peut monter jusqu’à 95% en utilisant un outil d’analyse de code.

Les bugs issus de défauts de spécification et de design sont moins nombreux mais plus difficiles à identifier et à supprimer.

La non-qualité des applications trouve son origine dans des défauts de nature très différente pour des risques et des impacts très différents. Les regrouper tous dans le même panier de la dette technique crée de la confusion et rend cette notion impraticable.

Dette technique et programmeurs

Dernière raison enfin : les défauts de code sont les seuls que l’on peut identifier de manière automatisable, à l’aide d’un outil d’analyse de code. Vous ne pourrez jamais automatiser la détection d’une spécification absente, d’une conception erronée ou d’un manque de tests. Ce sont forcément des tâches manuelles.

Par contre, vous pouvez analyser 5 000 classes Java et 100 000 lignes de code en quelques minutes et identifier rapidement et facilement toutes les violations aux bonnes pratiques. Vous pouvez même construire automatiquement des plans de remédiation que le développeur découvrira dans la liste de ses tâches.

Si l’on veut intégrer les autres défauts dans la dette technique, alors il faudra effectuer une estimation manuelle du risque fonctionnel ou de test pour chacune de ces 5 000 classes. Impossible.

Les programmeurs l’ont d’ailleurs bien compris qui utilisent la notion de dette technique sur un plan opérationnel, comme le montre cet article ‘Effective Code Review with Sonar’ sur le blog de Sonar. Un processus de Continuous Inspection permet de mesurer le niveau de dette technique et de veiller à ce que celle-ci ne s’accroisse pas.

Je suis donc d’accord avec Capers pour dire que la dette technique ne doit pas être confondue avec les coûts de non-qualité (COQ) sinon le concept devient impraticable.

Et pendant que nous autres consultants discutons de la définition exacte du concept, les développeurs utilisent la dette technique quotidiennement comme une métrique opérationnelle qui permet de surveiller le niveau de non-qualité dans le code, sans se soucier d’une définition exacte.

Vouloir actualiser ou étendre le concept de dette technique peut être intellectuellement intéressant mais s’avère inutile sans application concrète et opérationnelle, ou sinon, comme dans la blague sur les consultants, on ne sait pas trop à quoi cela sert ou ce qu’on peut en faire.

 

(1) Variante : « Et bien, je ne sais pas vraiment » répond le propriétaire. « Mais les deux autres l’appellent ‘Boss ‘». Eviter cette variante avec votre chef ou il va croire que vous insinuez qu’on ne sait pas ce qu’il fait.

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.