The First Law of Technology Transfer: Long-range good tends to be sacrificed to short-range good.

The Second Law of Technology Transfer: Short-range feasibility tends to be sacrificed to long-range perfection.

Jerry Weinberg - Quality Software Management

(Dans toute cette discussion, le terme : procédé (heuristic) fait référence à une méthode utilisée dans un contexte donné, sans garantie de résultat, pouvant contredire d'autres procédés, qui permet de réduire le temps de recherche d'une solution, et dont l'acceptation dépend du contexte d'utilisation et non d'un standard absolu.

Le mot heuristique s'utilisant uniquement comme adjectif, ou bien pour désigner l'Heuristique (la discipline qui étudie les procédés de recherche scientifique), nous parlons donc d'un procédé heuristique, au sens de l'expression a heuristic en anglais.

Le terme : état de l'art (state of the art ou sota) fait référence à l'ensemble des procédés qu'une personne ou un groupe utilise à un moment donné afin de produire la meilleure solution possible face à un problème imparfaitement compris, dans une situation incertaine, et ce à l'aide de ressources limitées.

Pour de plus amples informations sur ces termes, cf Billy Koen, Discussion of the method ou encore cette présentation.)

Pourquoi j'en ai fini avec la "Dette Technique"

J'aimerais mieux ne plus utiliser l'expression "dette technique" dans mon travail. Je l'ai longtemps fait, mais dans la majorité des cas où j'utilise ou entends utilisée "La dette technique", cette expression est inadaptée, voire contre-productive.

Elle a de nombreux défauts à mes yeux :

Elle est ambiguë : pour certains praticiens elle désigne le procédé consistant à déroger temporairement à l'état de l'art d'un projet afin d'atteindre un objectif intermédiaire. (On parle parfois de dette technique "tactique"). Pour d'autres (beaucoup plus nombreux) l'expression désigne ce qui est à mettre au passif d'un artefact logiciel jugé non conforme à l'état de l'art minimal autour duquel notre industrie s'accorde en général (on parle de dette technique "endémique"). C'est cette seconde acception qui me paraît un abus de langage, et que j'aimerais mieux ne pas utiliser dans mon travail.

Elle est négative : elle présente la construction de la solution actuelle comme un processus qui a détruit autant voire plus de valeur qu'il n'en a créé, et ses acteurs comme des emprunteurs insouciants (ou acculés) qui n'ont pas suffisamment fait attention au bilan, c'est à dire aux conséquences de leurs actions et décisions. Elle est exclusivement financière : elle sous-entend, en filigrane, l'idée que "la qualité" (une autre expression que je souhaiterais finir d'utiliser) a un coût qui peut être connu, et qu'en dépit de notre incapacité à le réduire, on peut tout de même le manipuler comme une quantité que l'on place en face de la valeur créée par le logiciel (une autre quantité fictive), dans une équation qui déterminerait la "productivité des développeurs".

Au départ simple métaphore, elle a été promue au rang de métrique d'ingénierie, et marketée comme telle. Le fait qu'il existe sur le marché des solutions pour évaluer (en euros) la dette technique dénote la tendance immature de notre industrie à transformer de simples métaphores en instruments pseudo-industriels. La "dette technique", comme la "couverture de test" doit rejoindre le panier des concepts bancals dont l'instrumentation ne produit au mieux qu'une illusion de contrôle.

Elle est culpabilisante : elle pointe du doigt le déficit financier causé par les défauts de qualité d'une solution, ce qui met en avant la Qualité comme une vertu (prudence, honnêteté, santé) et la non-qualité comme un vice (imprudence, malhonnêteté, anémie). Elle invite aux clichés moraux qui définissent le développeur "professionnel" comme celui qui déclare "je refuse de livrer de la m… quelque soit la pression, ou les règles qui m'entourent". Elle fait du développeur-artisan un héros de la propreté tout en négligeant de prendre du recul sur le système qui produit le phénomène dénoncé.

Elle pérennise la séparation archaïque et inadéquate entre la "technologie" et le "métier", le fonctionnel et le non-fonctionnel, en assignant au "fonctionnel" l'invention de la valeur, et au "technique" la responsabilité de l'ensemble des coûts de la solution.

Enfin, elle ne contribue pas à résoudre le problème que l'on cherche à désigner lorsqu'on l'utilise. "Gérer la dette technique" est devenu une activité de plus dans le panel des rôles et activités associés au développement de logiciel; elle consiste principalement à mesurer le phénomène et ses conséquences sans en changer les causes.

Par conséquent je souhaite m'en tenir à cette acception du terme "dette technique" :

[Contracter une Dette Technique] : procédé (heuristic) dans lequel on contrevient temporairement à l'état de l'art du projet afin de réaliser un objectif intermédiaire prioritaire.

Et je souhaite débarrasser mon vocabulaire du terme "dette technique" :

La Dette Technique : état général d'une solution jugée non conforme à l'état de l'art minimal communément admis dans l'industrie du logiciel.

Déclarer "cette solution est endettée techniquement", sans considération de l'état de l'art initial choisi par le groupe dans le contexte de son projet, c'est d'abord commettre l'erreur de prendre son propre état de l'art pour l'état de l'art initial de la solution considérée.

Il faut en finir avec la "La Dette Technique" (en général) comme il faut en finir avec "La Qualité" (en général). Il est possible pour une solution donnée dans un contexte donné, d'énumérer ses qualités. Ce sont les caractéristiques du changement que l'on cherche à produire lorsque l’on adopte un état de l'art particulier et adapté au contexte. Mais lorsque je dis "La Qualité", je me réfère implicitement à un état de l'art minimal standard dont j'insinue qu'il est valable dans tous les contextes, c'est à dire à un standard absolu.

Il n'y a pas de standard absolu. Il n'y a pas d'état de l'art général que l'on puisse désigner par ces termes : La Qualité. Au restaurant du Plaza Athénée à Paris, on peut faire un repas d'excellente qualité (pour environ €380 sans la boisson). Et chez McDonald, (où on peut déjeuner pour moins de 8 euros), il y a une direction de la qualité.

Voici un projet de développement logiciel de qualité :

• la solution, développée en seulement 200 jours, a été testée et jugée suffisamment adaptée au problème posé ;
• le code et la documentation sont conformes aux règles de l'art approuvées par l'organisation à qui appartient ce logiciel ;
• les pratiques de prévention des défauts sont suffisantes pour assurer plusieurs livraisons par mois sans régressions ;
• l'architecture est documentée, et adaptée à l'écosystème dans lequel ce logiciel va vivre.

Et voici un autre projet de développement de qualité :

• la solution, développée en seulement 2 heures, est adaptée au problème posé ;
• le code est écrit dans un langage de script accessible et documenté ;
• le script servira pour une seule opération ;
• au cours de l'exécution du script, il sera possible de le stopper et de reprendre l'opération afin d'ajuster certains paramètres ;

Nous avons là deux projets de qualité, A et B. Adaptez les critères de qualité du projet A au projet B et vice versa, et vous obtenez deux projets absurdes pour lesquels aucun client n'accepterait de payer.

Une alternative

Je vous entends d'ici m'interpeller, sur un ton calme et posé : Parfait. Fini, la "Dette Technique". Qu'est-ce que tu proposes ?

Je propose, dans les situations où l'on voudrait parler de dette technique, de remplacer cette expression par l'expression : conflit de procédés. (conflicting heuristics).

Je propose de remplacer la phrase :

Notre solution comporte de la dette technique.

Par la phrase :

Notre solution s'appuie sur des procédés en conflit.

Pour la version courte. Et pour une explication plus longue :

Apparemment les procédés que nous avions tacitement ou explicitement agréés jusqu'ici, et qui formaient l'état de l'art adapté à la solution que nous projetions de réaliser, ne sont plus respectés, ou ont été modifiés, et se trouvent, sous une forme ou une autre, en conflit.

L'agrément (même fragile, temporaire, ou incomplet) qui caractérisait l'état de l'art pour notre solution doit donc être renouvelé, ou bien les objectifs de notre solution doivent être re-discutés.

La toute première chose à faire en vue d'améliorer la situation, n'est donc pas de "gérer la dette technique", ni de "désendetter" la solution, mais d'identifier précisément les différents procédés qui sont, dans notre état de l'art, en conflit, de poser clairement les termes de ces conflits, et de les résoudre.

Une telle explication, puisqu'elle propose de changer la façon de regarder jusqu’ici un phénomène très courant, produira nécessairement des objections.

Objection #1 : Dans notre projet, il n'y a pas vraiment eu "d'agrément sur l'état de l'art". Les procédés dont tu affirmes qu'ils le constituent n'ont jamais été mentionnés explicitement, encore moins examinés, et certainement pas validés en équipe.

Exactement. C'est exactement pour cette raison que nous nous retrouvons à constater qu' "il y a de la dette technique dans cette solution".

Objection #2 : Conflit ou pas, c'est quand même bien de la dette technique, puisque c'est de la responsabilité du technique, (et non du fonctionnel métier, des utilisateurs, du management, des coaches, des architectes, etc.).

Sans le fonctionnel, le métier, les utilisateurs, le management, notre solution ne comporterait pas de "dette technique". Elle serait juste un objet insolite, fortuit, gratuit, que des développeurs ont réalisé parce qu'ils pouvaient le faire. Il y a de la "dette technique" parce qu'il y a un conflit, et un conflit implique plusieurs parties.

Objection #3 : Entrer dans le détail de tous les procédés qui caractérisent notre solution pour les examiner, les amender, les remettre en cohérence, cela prend du temps. Est-ce qu'on ne pourrait pas simplement régler les problèmes ?

Pour régler les problèmes, il faut résoudre les conflits. Si plusieurs procédés qui sont employés pour créer notre solution se contredisent, cette contradiction va persister et l'état de cette solution va s'aggraver. Il faut donc soit réconcilier ces procédés, ou bien changer les objectifs du projet.

Objection #4 : Est-ce que tu as au moins un exemple (ou dix) de situation dans laquelle une solution se trouve "endettée" du fait d'un conflit de procédés ?

Il est facile de mettre en exergue un conflit de procédé dans une situation de projet, que ce conflit soit latent ou explicite. Par exemple, hier j'ai tenté, jusque vers 20h, d'exporter des données en vue d'en faire un diagramme, "vite fait bien fait". C'était pour répondre à la demande d'un client qui a besoin d'y voir plus clair dans l'état de ses données avec notre application. J'ai eu tort de traiter la demande tout seul au lieu d'en parler au stand-up, mais je pensais réellement que le temps de réaliser cet export en python et de fabriquer un graphe avec graphviz serait bien inférieur au temps qu'il nous faudrait pour s'aligner sur cette tâche et l'expliciter, étant donné que je pense être le seul à maîtriser graphviz dans l'équipe.

Au moins quatre de nos procédés sont en contradiction (évidente ou latente) dans cette affaire :

[Extreme Customer Focus] : Proposer au client une expérience unique en termes de réponse à ses besoins en excédant le cas échéant le niveau de service standard.

[Quick & Dirty] : réalisation via une série d'expédients dans l'objectif prioritaire de livrer une solution dans des délais remarquablement courts.

[Revue de Code Systématique] : Tout le code qui va en production doit être relu par d'autres personnes que ses auteurs.

[Tests Unitaires systématiques] : Tout le code qui va en production comporte des tests unitaires permettant de vérifier que le code est conforme à l'intention de ses auteurs.

J'ai réalisé un compromis, en pensant au départ qu'un script de moins de 20 lignes suffirait (le script en fait maintenant 152), et que ce n'était pas du code de production, puisqu'il est écrit en dehors de la base de code du projet. Comme si le code qui permet de produire un artefact livré au client n'était pas du code de production. En résumé, ce petit script constitue un début de ce que nous appellerions de la "dette technique", mais que je préfère désigner par : un artefact produit au moyen de procédés qui étaient en conflit.

Objection #5 : Les procédés que tu mentionnes dans ton exemple ne constituent pas un standard absolu. D'autres équipes que la nôtre, ou d'autres organisations pourraient très bien reconnaître des pratiques et des procédés totalement différents.

Il n'y a pas de standard absolu. Et s'il y en avait un, chacun en ferait une interprétation relative. Cela n'a pas tant d'importance, puisque ce qui compte avant tout, c'est que dans notre état de l'art, les procédés soient en harmonie, et non en contradiction. Même s'il est évidemment utile de connaître des pratiques très répandues (pourquoi s'isoler de tout le savoir-faire qui se développe en permanence et s'amasse à tous les coins de l'internet ou dans les rayons des librairies et des bibliothèques ?) il vaut mieux posséder "son" état de l'art, que d'adopter en surface des "standards" venus de l'extérieur, non adaptés à notre contexte, et auxquels on se conforme "parce que c'est comme ça", et non parce qu'on les a expérimenté avec succès.

Objection #6 : Il est difficile de voir en quoi parler de conflits permet d'améliorer la situation. La communication dans un projet est déjà suffisamment complexe.

De la même manière qu'un conflit de ressources ne se termine pas fatalement en bataille rangée, deux idées en conflit ne créent pas nécessairement un conflit de personnes. Un projet qui se déroulerait sans aucun conflit d'idées ne vaudrait probablement pas la peine d'être réalisé. Mais un projet dans lequel les conflits ne sont ni abordés, ni résolus, ce n'est pas un projet, c'est une agonie.