Dette technique, nique nique

Trois erreurs fréquentes sur la dette technique

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.

À 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.

Dette et bugs

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).

Vivre avec la dette

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.

Rembourser la dette

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 ? Ça se mesure ?

Notes

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

Voir aussi