La dette technique, ou l’autre nom du diable en informatique 😈
Pour expliquer ce que c’est, et comment ça se produit, voici un scénario typique.
Alice (la cliente) présente à Bob (le développeur) son besoin.
Bob réalise son développement en un temps record, fier de lui. Il se relit avant de l’envoyer à Alice : « C’est pas hyper propre, m’enfin, c’est pas hyper compliqué non plus… Allez, hop, je livre ! »
Alice est impressionnée par sa rapidité, et ça fonctionne très bien ! Du coup ça lui donne des idées d’évolutions qu’elle partage à Bob. « T’inquiètes paupiette, lui répond-il, c’est juste 2-3 if à ajouter, t’as ça dans la semaine ! »
Mais Bob y passe plus de temps que prévu. Il s’est fait piéger par des subtilités qu’il y avait dans son code, pourtant « pas hyper compliqué ». Pour tenir son engagement, il travaille tard et passe rapidement sur les phases de tests et de relecture. « Je sais coder quand même ! se dit-il. Pas besoin de tests. »
Juste à temps, Bob livre la nouvelle version à Alice. Elle est contente du résultat mais elle a quand même des réserves : « J’ai rencontré quelques comportements inattendus. Il faudra les corriger rapidement. ».
Sur le coup, il se dit que ce sont les risques du métier. « Quand on est développeur, on n’échappe pas aux bugs. ». Il commence donc à effectuer les corrections. Mais en les testant, cette fois-ci, il détecte de nouveaux bugs.
Bob commence à passer tout son temps à corriger des bugs, ce qui finit par l’énerver : « Non mais c’est quoi ce code de m**** ! Qui a fait ça com… Ah, c’est vrai que je suis seul sur le projet. ».
Il part chercher un café en ruminant. Puis la mauvaise foi éclate : « C’est à cause d’Alice tout ça. La première version était très bien ! Mais non, il fallait tout changer parce qu’elle s’est réveillée avec une nouvelle idée à intégrer. Et bien sûr, il faut tout ça pour hier. » finit-il en soupirant profondément.
Le lendemain, il reçoit justement un appel d’Alice : « Allô Bob. On a passé la deadline, tout va bien ? Quand est-ce que tu pourras me livrer ? ». En pleine panique, il essaie de garder son calme pour rester courtois et improvise : « Euh… oui, j’ai eu quelques imprévus. Tu as tout ça demain sans faute ! »
Alice accepte la nouvelle sans faire d’histoire, un jour de retard ce n’est pas grand-chose. « Il vaut mieux que le produit soit fiable. »
En revanche, il ne faudra pas d’autres retards. Elle s’attend à ce qu’il ait le même rythme et la même qualité de livraison qu’en début de prestation. Et c’est assez normal après tout, elle a quand même fait appel à un pro !
Après une nuit encore trop courte, Bob livre ses évolutions à Alice. Elle trouve plusieurs problèmes, certains assez importants : « Inutile de préciser que la prochaine version devra corriger tout ça, Bob. ». Ce dernier acquiesce froidement.
Puis elle ajoute : « J’ai eu des retours des utilisateurs, il y a cette fonctionnalité dont on avait déjà parlé et qu’il faudrait intégrer absolument. ». Bob essaie de la convaincre d’attendre une future version pour implémenter cet ajout. Il sait qu’il ne pourra pas faire toutes les corrections ET ajouter une nouvelle fonctionnalité.
« Et si on ajoute un développeur au projet ? » se risque Alice. Justement, Bob a récemment reçu un message d’un de ses contacts professionnels qui cherche une mission. « C’est une solution envisageable, lui répond-il. Cependant, ça va prendre du temps de l’intégrer au projet. D’ici là, la prochaine échéance de livraison sera déjà trop proche. »
Bob lit la déception d’Alice sur son visage, même derrière son masque. « Bon… La prochaine version sera dédiée à de la stabilisation alors, se résout-elle. Mais appelle quand même ton contact, pour les prochaines fois. Il va falloir rattraper ce retard. »
Bob repart donc avec la liste des bugs, et l’envie de rattraper ses erreurs (ses fautes ?). Il se sent vraiment mal d’avoir autant déçu sa cliente, pourtant il s’est donné à fond.
Bien décidé à se reprendre, Bob réalise une analyse rétrospective de son travail. Il prend alors le temps de relire son code dans sa globalité.
Le constat est sans appel : c’est immonde. Si on lui avait fourni une telle base de code, il aurait refusé tout net. « Comment j’ai pu en arriver là ? » s’interroge-t-il, perplexe.
Il parcourt l’historique de ses modifications et une chose le perturbe : individuellement, aucune modification n’a l’air horrible. Pourtant le résultat final est bien celui qu’il a vu. Il appelle alors son contact comme prévu. Peut-être qu’un regard externe pourra l’aider à comprendre la situation.
Son contact c’est Charlie, un ancien collègue plus expérimenté que lui. Après un rapide tour de situation, il explique à Bob : « C’est classique, tu n’as juste pas pris le temps de nettoyer ton code au fur et à mesure des livraisons. »
La dette technique ça n’arrive pas d’un seul coup. Aucun développeur ne se réveille le matin en se disant « Allez, aujourd’hui, je fais du code crade ! »
Et c’est bien là le danger de la dette technique : elle ne se voit qu’avec du recul, ou lorsqu’il est trop tard. Elle s’immisce un peu partout, subtilement.
Bob demande alors à Charlie : « C’est grave docteur ? Je peux réparer ça, et continuer à livrer ma cliente ? ».
« Tu dois devenir comme Superman : un boy scout » lui répond-il. Bob le regarde alors avec un mélange d’interrogation et de perplexité.
« Les boy scouts ont une règle : toujours laisser leur camp dans un état plus propre que celui dans lequel ils l’ont trouvé, reprend Charlie. Tu dois faire pareil avec ton code : profiter de chaque modification pour l’améliorer. »
Cette approche génère plusieurs avantages, dont notamment :
- Seul le code activement modifié est impacté, et évite donc de passer du temps sur du code qui n’a plus besoin de changer ;
- Coût relativement peu cher, car les améliorations se doivent d’être les plus minimes possibles ;
- Effet exponentiel (voir schéma ci-après) ;
- Peu de risque sur l’ampleur des modifications apportées, surtout comparé à une stratégie de réécriture massive ;
- Permet de maintenir sa vélocité de livraison.
Bref, c’est tout bénéf’ !
En introduction, je comparais la dette technique au diable. En effet, comme on dit : « le diable est dans les détails ». Parce que c’est justement dans des détails qu’elle se forme, jour après jour. Vous savez, ces évolutions sur lesquelles les développeurs disent leur fameux : « ouais, c’est bon, c’était juste un if à ajouter ». Et c’est donc sur ces « petites évolutions » qu’il faut rester vigilant, sous peine de se faire rattraper.
Une réponse