Publié le 22 juin 2020, mis à jour le 23 janvier 2024.
On ne peut pas gagner. On peut seulement contrôler la vitesse à laquelle on perd. Comme la plupart des personnes qui y ont joué, j’adore Tetris. Je me rappelle encore y avoir joué pour la première fois sur la Game Boy Nintendo d’un ami. Non seulement Tetris est l’un des meilleurs jeux de tous les temps, mais c’est aussi une excellente analogie avec la dette technique.
Je connais très bien les impacts de la dette technique – je dois les gérer au quotidien. Je vous partagerai également dans cet article, une histoire personnelle qui raconte comment mon équipe et moi avons réussi à réduire notre dette technique sur du code de facturation, en résolvant un bug à 1 million de dollars (par an).
Tetris et la dette technique
Les tâches sont plus simples au début, quand la complexité est faible
Au sein des entreprises tech, les Product et Project Managers travaillent avec les développeurs pour prioriser le code qui doit être écrit et délivré aux clients. Éliminer une ligne de Tetris équivaut à délivrer une fonctionnalité. Délivrer une fonctionnalité complexe requiert davantage de lignes.
Une fonctionnalité complexe est facile et très satisfaisante
à délivrer lorsqu’il y a peu de dette technique
Souvent, les besoins business (nouvelles fonctionnalités, nouveaux produits) conduisent à des compromis à l’intérieur du code (hack, raccourcis) pour pouvoir délivrer à temps. Ou dans d’autres cas, les changements dans la stratégie du produit sont incompatibles avec le design antérieur, et requièrent donc un effort supplémentaire soit pour migrer les utilisateurs, soit pour maintenir à la fois l’ancienne et la nouvelle logique.
Des petites quantités de dette technique sont normales et gérables
Ces types de scénarios créent la dette technique dans le code du produit. La zone vide recouverte par d’autres lignes sur Tetris représente la dette technique.
Tout code a une dette technique. C’est normal. On peut continuer à jouer à Tetris avec quelques brèches parmi les carrés bien alignés.
On croule sous la dette technique
Trop de dettes technique empêchent les fonctionnalités et les résolutions de bug d’être délivrés dans des délais raisonnables. Ce n’est pas un problème qu’on peut résoudre en employant plus de développeurs, ou de manière plus radicale en remplaçant les développeurs déjà en poste. Si on appelle ce phénomène “dette technique”, c’est parce qu’à un moment, il faut la payer.
Payer sa dette technique permet d’être compétitif. De rester dans le coup.
Game over
Comme lorsqu’on gère une entreprise, Tetris devient de plus en plus difficile au fur et à mesure de la partie. Les pièces bougent plus vite, il est plus compliqué de suivre le rythme.
Comme lorsqu’on gère une entreprise, on ne peut jamais gagner à Tetris. Il n’y a pas de ligne d’arrivée. On peut seulement contrôler la vitesse à laquelle on perd.
Comme lorsqu’on gère une entreprise, permettre la création de trop de brèche vous fera perdre.
Le bug qui valait 1 million
Il n’y a pas longtemps, on a confié à mon équipe le soin de mettre à jour le circuit logique de la facturation dans notre code pour qu’il soit compatible avec un nouveau système de tarification, un nouveau moyen de paiement et un nouveau workflow de facturation. Certains détails étaient encore en discussion au sein de l’équipe produit, on a donc utilisé ce temps libre pour se plonger dans le code existant.
Cela nous a permis de mieux comprendre notre code afin de pouvoir donner des estimations précises de notre capacité à délivrer ces modifications.
L’objectif fondamental du code que l’on a étudié était de vérifier chaque compte client, de calculer le montant de leur facture et de l’envoyer à l’API de facturation. Il avait clairement été écrit avec soin et avec de bonnes intentions - il n’était pas si compliqué par contre il était très rigide.
C’était une fonction monolithique. Il n’y avait pas de tests. Très peu de logs. Presque aucune documentation. Il y avait une randomisation inexpliquée. Le code avait été écrit il y a plus de 5 ans par l’un des co-fondateurs. Le seul changement qu’il y avait eu depuis avait été fait par un développeur qui n’était plus dans l’entreprise.
Était-ce vraiment un problème ? Les factures étaient envoyées. L’entreprise produisait du chiffre d’affaires. Rien n’indiquait qu’il y avait un problème quelconque.
Tout cela aurait pu nous dissuader de refactoriser le code, mais nous savions que des gros changements allaient venir, que cette fonction ne serait pas à l’échelle pour nos besoins. Nous pourrions avancer plus vite si cette partie était simplifiée.
Nous avons donc refactorisé cette fonction en un seul sprint et ajouté quelques logs, les plus importants. C’est à ce moment que nous avons découvert ce que nous avions en réalité réparé. Une personne de l’équipe comptabilité s’est arrêtée à notre bureau pour nous demander pourquoi le nombre de factures client avait soudainement augmenté.
L’ancien code avait expiré en silence et les consommations de certains clients n’avaient pas été comptabilisées dans les factures. La randomisation inexpliquée ? Elle cachait en fait tous les patterns qui auraient pu nous alerter sur les clients qui n’étaient pas facturés.
Lorsque nous avons fait une estimation, nous avons réalisé que les factures manquantes représentaient en fait 1 million de dollars par an.
Diminuer la dette technique ne paie pas toujours
Même si cette histoire est tout à fait vraie, s’attaquer à la dette technique n’amène pas toujours un résultat aussi spectaculaire. Nous avons eu de la chance.
Trouver le bon équilibre de dette technique
J’aimerais pouvoir vous donner un conseil avisé pour vous dire quand vous pencher sur la dette technique. Malheureusement, la réponse est la suivante : c’est un exercice compliqué, et ce sera toujours une histoire d’équilibre. On peut avoir le code le plus propre et le plus testé au monde, mais sans avoir de clients. Inversement, une entreprise peut très bien avoir un code très compliqué qui ravit les clients et génère du chiffre d'affaires à foison.
Dans tous les cas, les product owners et les développeurs doivent comprendre ce que la dette technique représente. Ils devraient également savoir qu’on ne pourra pas l’éviter pour toujours. Après tout, comme pour Tetris, on ne peut jamais gagner au jeu du développement logiciel.
Merci à Eric Higgins pour nous avoir permis de traduire son article. Vous pouvez retrouver la version originale "Technical Debt is like tetris".
Et de la part d’Eric, merci à Thomas Lubitz d’avoir inspiré cet article et d’avoir permis d’utiliser l’analogie qu’il a utilisée pendant un talk éclairant où il jouait à Tetris à direct.