Comment quantifier l’inflation de la dette technique ?

Article original : How to quantify technical debt inflation | Belay the C++ (belaycpp.com)
Traductrice : Chloé Lourseyre

Si vous travaillez pour une soci√©t√© de d√©veloppement logiciel, vous vous √™tes sans doute retrouv√© dans le cas o√Ļ vous aviez une dette technique √† r√©soudre, mais o√Ļ vous n’aviez pas l’approbation de votre hi√©rarchie pour le faire dans l’imm√©diat. ¬ę¬†On verra √ßa plus tard¬†¬Ľ, comme ils disent. Mais en bon¬∑ne d√©veloppeur¬∑se, vous savez deux choses : la dette technique est de plus en plus dure √† r√©soudre au fil du temps, et l’impact d’une dette technique stagnante ajoute un surco√Ľt √† chaque ajout de code qui est fait entre-temps.

Quand vous essayez d’argumenter que ¬ę¬†la dette technique est co√Ľteuse¬†¬Ľ, vous vous retrouvez souvent face √† la question ¬ę¬†co√Ľteuse de combien ?¬†¬Ľ. Mais vous n’avez pas de r√©ponse √† cela, car (√† l’heure o√Ļ cet article est r√©dig√©) il n’y a pas de moyen connu pour pr√©dire l’avenir.

C’est ce que j’appelle la probl√®me d’Inflation de la Dette Technique, ou TDI (pour Technical Debt Inflation).

Avertissement : Je ne peux pas vraiment r√©soudre le sempiternel probl√®me de la TDI dans un article de deux mille mots. Ce que je donne ici est un fruit de r√©flexion, l’ouverture d’un d√©bat, une ligne d’approche pour vous pousser √† mener votre propre r√©flexion sur le sujet. J’esp√®re que vous pourrez l’appr√©cier.

Qu’est-ce que la dette technique ?

On peut d√©finir la dette technique comme √©tant une partie du code qui est mal con√ßue et qui a besoin d’√™tre r√©√©crite pour √™tre efficace. Elle n’a pas d’impact pour l’utilisateur, mais rend le code plus dur √† maintenir et cela complexifie le d√©veloppement de nouvelles fonctionnalit√©s (on se limitera √† cette d√©finition pour cet article).

Souvent, elle appara√ģt quand on choisit une approche √† court terme plut√īt qu’une solution sur le long terme. Cela co√Ľte plus de temps d’√©crire une solution au long terme sur le moment, mais une version √† court terme se repaye toujours dans le futur.

Qu’est-ce que l’inflation de la dette technique ?

Une dette technique est co√Ľteuse de deux mani√®res.

Premi√®rement, elle est co√Ľteuse √† r√©soudre. Corriger une dette technique prend du temps, et puisqu’elle est invisible du point de vue de l’exp√©rience utilisateur et de la hi√©rarchie, c’est souvent consid√©r√© inutile par ceux-ci.

Secondement, il est co√Ľteux de travailler ¬ę¬†proche¬†¬Ľ d’une dette technique. Elles ont tr√®s souvent des impacts autour d’elles, dans la mani√®re de d√©velopper de nouvelles fonctionnalit√©s ou de les maintenir. Par exemple, une dette technique peut √™tre une interface contre-intuitive, qui n√©cessite plus de temps pour s’y habituer qu’une interface ergonomique. Autre exemple, si un module est mal r√©dig√©, toute mise √† jour en son sein co√Ľtera sensiblement plus de temps que s’il √©tait bien con√ßu.

L’inflation de la dette technique est le fait que plus on attend longtemps pour la r√©soudre, plus ces co√Ľts augmentent.

En effet, plus le temps passe et plus la quantit√© de code affect√©e sera grande (puisqu’il y aura de plus en plus de code d√©pendant de cette dette) et plus il sera difficile de la maintenir.

Quel est l’int√©r√™t de quantifier la dette technique et son inflation ?

Mesurer l’amplitude de l’impact d’une dette technique est compliqu√©. Il est encore plus dur de justifier une telle √©valuation √† celles et ceux qui approuveront -ou pas- le travail que √ßa implique.

Si on arrive √† concevoir un mod√®le qui met des nombres sur la dette technique, il sera plus facile de justifier de la n√©cessit√© r√©soudre celle-ci au plus t√īt.

On pourrait avancer des arguments comme ¬ę¬†Oui, √ßa nous co√Ľterait trois jours de corriger cette dette maintenant, mais si on ne le fait pas, dans deux ans elle aura, en tout et pour tout, co√Ľt√© en moyenne deux heures par semaines par d√©veloppeuse et d√©veloppeur, pour un total de cinquante jours √† la fin de la deuxi√®me ann√©e…¬†¬Ľ. Cela pourrait aider √† mettre en perspective la vision de la hi√©rarchie.

Mais je dois bien admettre que la chose la plus importante ne sont pas les nombres eux-mêmes, mais les arguments qui se basent dessus.

Comment quantifier la dette technique ?

La dette technique est co√Ľteuse √† r√©soudre. La premi√®re √©tape est d’√©valuer combien de temps une dette prendrait √† r√©soudre aujourd’hui. Sans √ßa, on ne pourra pas √©valuer l’inflation de ce co√Ľt.

Par chance, c’est souvent assez facile √† √©valuer. En se basant sur sa propre exp√©rience du code, on est souvent en mesure de donner une estimation du temps n√©cessaire √† la r√©solution d’une dette.

En général, je conseillerais de multiplier toute évaluation raisonnable par deux ou trois, afin de prendre en compte les impondérables.

Si vous travaillez en √©quipe, il est sage de baser son estimation sur la personne la plus ¬ę¬†lente¬†¬Ľ de l’√©quipe, car vous ne serez peut-√™tre pas la personne qui r√©soudra effectivement la dette, et si vous travaillez plus rapidement que vos collaborateurs, l’√©valuation risque d’√™tre fauss√©e.

Une fois cela fait, on peut maintenant √©valuer l’inflation de la dette technique.

Comment quantifier l’inflation ?

La chose la plus importante √† retenir √† propos de l’inflation est qu’elle n’est pas lin√©aire.

En fait, vu qu’il y a deux axes sur lesquels la dette technique augmente (le surco√Ľt de correction et le surco√Ľt d’utilisation), et qu’ils subissent tous deux l’inflation, alors cette inflation est, a minima, quadratique1. Elle n’est pas proportionnelle au temps, mais au temps au carr√©.

S’il n’y qu’une chose √† retenir de cet article, c’est cela : la TDI est quadratique.

Maintenant, comment évaluer (numériquement) cette inflation ?

Un indicateur simple et utilisable est la taille du code. La taille du code tend à augmenter avec le temps, et si on arrive à avoir un modèle qui extrapole la taille du code dans le futur à partir de son évolution dans le passé, alors on pourra estimer la taille du code dans le futur.

Je vous donne un exemple de m√©thode d’√©valuation de la taille du code dans un des addenda.

√Ä partir de l√†, il suffit d’appliquer un facteur quadratique sur cette √©volution pour obtenir une √©valuation de l’inflation de la dette. C’est ce que j’appelle le mod√®le de Croissance Quadratique (ou Quadratic Expansion dans la langue de Sutter).

Formalisation du modèle de Croissance Quadratique

Soit C0 la taille du code à t0.
Soit C1 la taille du code à t1.
Soit D0 le temps estimé pour résoudre la dette technique à t0.
Soit D1 le temps estimé pour résoudre la dette technique à t1.
Soit I01 le temps perdu √† cause de l’impact de la dette technique entre t0 et t1.
Soit őĒ01 le total de temps cumul√© qu’a co√Ľt√© la dette technique entre t0 et t1.

C0, C1 et D0 sont des valeurs connues.
D1 et I01 sont des valeurs interm√©diaires.
őĒ01 et l’objectif du mod√®le.

D1 = D0 √ó C1 √∑ C0

I01 = őõ √ó C1 √∑ C0, o√Ļ őõ est une constante qu’on appellera ‚Äúfacteur lambda‚ÄĚ2.

őĒ01 = (I01 √ó D1) ‚Äď D0

őĒ01 = őõ √ó D0 √ó (C1 √∑ C0)2 ‚Äď D0

Pour simplifier le calcul, supposons őõ = 1 (on cherche √† √©valuer un ordre de grandeur, pas √† avoir une mesure pr√©cise), ce qui donne

őĒ01 = D0 √ó ( (C1 √∑ C0)2 ‚Äď 1 )

Exemple

Vous avez une dette technique cons√©quente √† r√©soudre. Votre sup√©rieur h√©site √† la retarder de six (pour des raisons de jalon de livraison). Vous lui dites que √ßa co√Ľterait du temps en plus de la reporter, et iel vous demande de quantifier √† quel point.

√Ä l’heure actuelle, la fonctionnalit√© concern√©e est compos√©e de 21,6 milliers de lignes de code. Il y a trois mois, elle √©tait compos√©e de 17,8 milliers de lignes. Le code a donc gonfl√© de 3,8 milliers de lignes dans cet intervalle. Cependant, votre √©quipe (compos√©e de quatre d√©veloppeur¬∑se¬∑s) vient de se voir renforc√©e avec un nouvel arrivant, ce qui fait un total de cinq devs. Donc au cours des six prochains mois, on peut estimer que le code grossira d’environ 9,5 milliers de lignes suppl√©mentaires (38√ó2√ó1,25).

Votre estimez qu’il faudrait une semaine enti√®re (5 jours) pour r√©soudre la dette technique.

C0 = 21.6k

C1 = 31.1k

D0 = 5 jours

őĒ01 = D0 √ó ( (C1 √∑ C0)2 ‚Äď 1 ) ‚Čą 5.4 jours

Conclusion : selon le mod√®le de croissance quadratique, l’attente co√Ľterait environ cinq jours et demi suppl√©mentaires.

Vous annoncez donc √† votre hi√©rarchie que, compte tenu de la productivit√© de l’√©quipe, attendre six fera plus que doubler le temps perdu √† r√©soudre la dette (en incluant sa correction et le temps perdu √† la maintenir).

Les limites de ce modèle

Ce modèle a de grosses limitations.

  • Premi√®rement, le calcul n’est pas transitif. E.g. őĒ02 ‚Ȇ őĒ01 + őĒ12. Cela refl√®te le fait que plus on porte son regard loin (0 ‚Üí 2), plus le co√Ľt de la dette est incertain. Math√©matiquement, il faudrait refl√©ter cela avec un intervalle de confiance.
  • √Čvaluer et extrapoler la taille du code est souvent faisable, mais pas toujours trivial.
  • Surtout, ce mod√®le n’a jamais √©t√© d√©montr√© en pratique.

La question √† un million d’euros

Il y aurait bien, en th√©orie, une mani√®re d’√©valuer math√©matiquement la probl√©matique TDI : en agr√©geant des donn√©es recueillies sur des centaines de projets √† travers les ann√©es. Mais ce n’est pas une t√Ęche simple, sinon impossible. En voici les raisons :

  • Cela voudrait dire ing√©rer dans le code d√©tenu par des soci√©t√©s priv√©es.
  • M√™me en r√©trospective, il est complexe d’√©valuer l’impact qu’a eu une dette technique.
  • L’√©tude prendrait des ann√©es, sinon des d√©cennies √† √™tre compl√©t√©e, car les impacts d’une dette technique se mesurent dans le temps.

Avec ça en tête, agréger des données réelles dans une étude sérieuse semble impossible. Mais peut-on élaborer un protocole de plus petite échelle qui pourrait nous aider à résoudre la problématique de la TDI ? Ça mérite réflexion.

Conclusion

Je le redis, pour √©viter toute ambigu√Įt√© : le mod√®le de Croissance Quadratique est une mani√®re limite, peu pr√©cise et non-scientifique d’√©valuer l’inflation de la dette technique, mais elle permet d’avoir un ordre de grandeur coh√©rent en faveur d’une refonte t√ītive du code.

J’esp√®re que ce sera le pr√©lude d’√©tude plus s√©rieuse sur le probl√®me de la TDI.

Souvenez-vous qu’√©valuer le temps ¬ę¬†perdu¬†¬Ľ d’une dette technique existante est loin d’√™tre trivial et qu’un protocole d’√©valuation est impossible √† petite √©chelle.

Mais j’esp√®re que √ßa vous aidera √† avoir une id√©e plus nette du co√Ľt concret des dettes techniques.

Merci de votre attention et à la prochaine !

Article original : How to quantify technical debt inflation | Belay the C++ (belaycpp.com)
Traductrice : Chloé Lourseyre

Addenda

Comment évaluer la taille du code? Un exemple

Avec Git et un shell Linux, vous pouvez facilement √©valuer la taille du votre code.

git ls-files Liste tous les fichiers.

grep -E '\.(cpp|h|hpp)$' est un filtre sur les fichiers de source et d’en-t√™te.

wc -l compte le nombre de lignes.

Voici la commande complète :

git ls-files | grep -E '\.(c|cpp|h|hpp)$' | xargs -d '\n' wc -l

(NB : xargs permet d’alimenter la sortie dans la commande  wc. L’option -d '\n' est pr√©sente pour √©chapper les espaces dans les noms de fichier)

Alternativement, vous pouvez utiliser¬†wc -m¬†√† la place de wc -l¬†pour compter les caract√®res au lieu des lignes. C’est un peu plus lent et moins intuitif, mais √† mon avis une meilleure m√©trique que le nombre de lignes.

Pour que le résultat soit plus lisible, vous pouvez faire

grep -E '^ *[0-9]+ total$' pour r√©cup√©rer uniquement la ligne de total.

sed -r 's/^ *([0-9]+) total$/\1/' enl√®ve les informations superflues.

La commande complète est désormais :

git ls-files | grep -E '\.(c|cpp|h|hpp)$' | xargs -d '\n' wc -l | grep -E '^ *[0-9]+ total$' | sed -r 's/^ *([0-9]+) total$/\1/'

Si vous avez plusieurs sous-modules, vous pouvez :

Ajouter --recurse-submodules pour que l’op√©ration soit r√©cursive.

awk '{s+=$1} END {print s}' somme les valeurs de totaux.

Ligne de commande finale :

git ls-files --recurse-submodules | grep -E '\.(c|cpp|h|hpp)$' | xargs -d '\n' wc -l | grep -E '^ *[0-9]+ total$' | sed -r 's/^ *([0-9]+) total$/\1/' | awk '{s+=$1} END {print s}'

Notes

  1. C’est bas√© sur cette id√©e : puisqu’il y a deux co√Ľts qui augmentent et que ces deux co√Ľts sont entrem√™l√©s, leur combinaison est multiplicative plut√īt qu’additive. Cela fait que, d’apr√®s moi, l’inflation est quadrative.
  2. őõ repr√©sente √† quel point le reste du code d√©pend de la dette technique. Plus l’impact est important, plus őõ sera grande, et donc plus I01 sera grand √† son tour. Pour des raisons de simplification, őõ est ici consid√©r√©e constante.
  3. Est-il seulement possible de concevoir un protocole qui permettrait d’√©valuer la justesse de n’importe quel mod√®le de TDI ? Puisqu’on ne peut r√©aliser qu’une des deux actions (r√©soudre la dette dans l’instant ou la r√©soudre plus tard) il n’y a aucun moyen d’√©valuer avec certitude le temps qu’aurait pris l’alternative. De plus, le temps n√©cessaire pour r√©soudre une dette d√©pend des comp√©tences de la personne qui la raison et, il faut bien l’avouer, de la chance. En plus de cela, le mod√®le est con√ßu pour inclure un risque, ce qui signifie que l’inflation estim√©e sera grande pour y inclure ce risque. Il n’y a (√† ma connaissance) aucun moyen de v√©rifier ce genre de repr√©sentation abstraite.

Laisser un commentaire