Dette technique, nique nique

Le terme dette technique revient pas mal en ce moment. On en parle dans les blogs et je l'entends même dans mon équipe.

Il n'est pas récent : il vient d'un article de Ward Cunningham de 1992 pour une conférence OOPSLA.

A l'époque, pas d'agile ! Mais du développement incrémental et orienté objet.

Cunningham utilise l'analogie avec la dette financière pour mettre en évidence que, comme les intérêts s'accumulent progressivement lorsqu'on contracte une dette, le coût de développement augmente si le logiciel a des imperfections techniques.

Every minute spent on not-quite-right code counts as interest on that debt

Cunningham ne développe pas plus cette notion. Elle est souvent mal comprise. J'ai entendu ou lu des appréciations erronées sur la dette technique.

La première est quand on confond la dette technique avec les bugs. Un logiciel qui a des bugs n'a pas forcément de dette technique, de même qu'un logiciel sans bug peut avoir une dette technique.
Les bugs sont visibles des utilisateurs, alors que la dette technique ne l'est pas. Comme son nom l'indique, elle est technique. J'ai parlé d'imperfection et cela peut avoir de multiples formes : architecture bancale, code mal écrit, standard de codage pas suivi. Mais on peut avoir de la dette technique qui ne porte pas sur du code applicatif : par exemple pas de documentation développeurs ou pas de test automatisé (j'y reviendrai).

La seconde erreur est de considérer qu'avoir de la dette technique, c'est le mal absolu. En fait, on peut très bien vivre avec[1].
Vivre avec, cela peut être carrément un choix, dans certains contextes. J'étais en avril auprès d'une organisation qui produit des logiciels avec une orientation recherche : son but est de développer rapidement des produits innovants, pas de les industrialiser. Dans ce cas, elle n'a pas besoin d'éponger une éventuelle dette technique, c'est la société qui reprendra le logiciel pour l'industrialiser qui aura à s'en charger. D'ailleurs ce bon Ward dit : A little debt speeds development

Une autre bonne raison de vivre, au moins provisoirement, avec une dette technique est la livraison d'une version apportant de la valeur. Pas besoin d'être un expert en analyse financière pour comprendre qu'un Product Owner prend une bonne décision en préférant livrer au bon moment (le time-to-market) plutôt que retarder une livraison pour (essayer de) rembourser la dette si, même en comptant les intérêts, la valeur apportée par la mise à disposition de cette nouvelle version est plus importante.

La dernière erreur est de croire qu'on peut rembourser sa dette technique en un éclair. Quand une dette technique est constatée, vouloir éradiquer toute la dette immédiatement et d'un coup n'est pas réaliste. C'est comme si vous sommiez une famille sur-endettée de rembourser du jour au lendemain et de ne plus recommencer !
Cela demande à la fois d'apprendre de nouvelles pratiques techniques, de les mettre en œuvre et en plus il faut épurer le passif. C'est pas facile et ça prend du temps. Pourtant il faut l'entreprendre, car sinon gare aux intérêts.

Mais comment ça se voit une dette technique ? Ca se mesure ?

Notes

[1] En réalité tout le monde vit avec, de façon plus ou moins consciente

Commentaires

1. Le lundi 18 mai 2009, 23:48 par Oaz

Une idée pour mesurer la dette technique : estimer l'écart de coût d'une histoire utilisateur entre l'instant présent et le début du projet.
La différence, c'est la dette technique.
L'agilité vient avec la promesse que le coût des changements est constant au fil du temps et c'est la dette technique qui empêche de réaliser cette promesse en augmentant ce coût.

A part ça tu as oublié la chanson du jour : http://www.deezer.com/track/dominiq...
(bon ok ce n'est pas très rock'n'roll)

2. Le mardi 19 mai 2009, 09:56 par Thierry

Hello
et le principe de qualité est justement prophylactique. Autre point : les leçons apprises, ie comment éviter de recréer les mêmes dettes.

3. Le mercredi 20 mai 2009, 20:29 par JM.D

Un autre effet pervers de la dette technique est son coût "humain".
En effet, par simple mécanisme d'usure par "friction" à du code qui "résiste" aux changements, la dé-mobilisation des équipiers peut se faire sentir très vite (c'est du vécu).
Personne n'aime travailler dans de mauvaises conditions ou en produisant du code que l'on sait pertinemment "sentir mauvais". Kent Beck (il fait de l'agile) le formule ainsi : "la qualité a un effet sur les gens".
Peut-être qu'un tableau niko-niko permettrait de mesurer cette dé-mobilisation et de permettre d'identifier la dette technique ?
En tout cas, il faut du courage pour s'opposer aux désirs d'un Product Owner ! Ce n'est malheureusement pas une valeur pour Scrum ...