Rembourser ses dettes, c’est s’enrichir, et dans le contexte technologique actuel, cela signifie investir dans la gestion de la dette technique pour prospérer sur le long terme.
Dans la majorité de nos projets aujourd’hui, la demande qui est faite aux équipes de développement est de produire des fonctionnalités. Qu’on travaille en suivant des méthodes Agiles ou de l’ingénierie système, les projets grossissent, grossissent et vient le moment du changement de label à 1000€.
La dette technique en continu
La solution choisie dans mon équipe actuelle est d’allouer 1 jour toutes les 2 semaines, le vendredi, dont l’objectif est de réduire la dette technique en résolvant des tickets de bugs mineurs, ou des tickets d’optimisation de code. On a donc un nom tout trouvé : le Frixday ! Ce temps est aussi alloué pour monter les versions des librairies, et est finalement parfait pour faire monter en compétence l’équipe sur des parties du produit potentiellement moins connues. Cela permet donc de nous occuper de la dette technique, tout au long du cycle de vie du produit, sans la laisser s'accumuler de façon incontrôlable.
Parfois les bugs décident d’arriver un autre jour que ce fameux vendredi. Pour ça, nous avons le rôle quotidien, tournant, de sentinelle, qui est aussi dédié aux mises en production et à répondre aux questions de nos utilisateurs. Une personne qui, les jours bénis sans aucun problème en production, a pour but de résoudre les bugs mineurs. Cette vigilance constante permet d'éviter que la dette technique ne se creuse encore davantage, tout en soulageant l’équipe de développement des interruptions extérieures.
La dette technique moyen terme
Arrivé ici, vous vous dites sûrement : « un jour, toutes les deux semaines, suffirait à avoir zéro dette ?! Quelle est cette sorcellerie ?! Moi, mon produit a été fait par des gens avant moi, moins compétents (évidemment) ; il faudrait plus de temps pour tout refaire ! ».
Pour des changements plus en profondeur, comme des migrations ou des refontes par exemple, nous avons dédié les deux dernières semaines de chaque trimestre. C’est l’occasion de mélanger les différentes équipes impactées par les changements. En bonus, lorsqu’il faudra coopérer sur des futures fonctionnalités, les équipes se connaitront déjà !
La dette technique long terme
Évidemment, certains changements nécessiteront plus de temps encore. Malheureusement, votre CTO a vu un superbe talk à la Tech Week et veut que tout le produit soit repensé ? Pas de miracle pour ça, il faudra allouer du temps aux équipes qui réduira le temps dédié aux fonctionnalités. Pour mon équipe, le choix est d’allouer 30% du temps d’un trimestre pour ces sujets techniques.
C'est un investissement à long terme qui permet de casser le cercle vicieux de l'accumulation de dette technique de manière significative tout en préparant le terrain pour l'avenir. On évite donc la partie de fin de vie du produit où chaque changement est couteux.
La dette technique du futur
Lorsque j’ai commencé à travailler, le produit monolithique avait un backend en java 6 avec un superbe (c’est faux) frontend en JSP. Aujourd’hui, mon produit est en micro-services C#, avec un frontend en Angular. Comment savoir en quoi sera fait mon produit du futur ? La veille technologique et l’expérimentation sont là pour ça !
Personnellement, lorsque sonne la fin de journée, mon PC est comme moi, claqué, et je n’ai qu’une envie, c’est de voir de la verdure. Bonne nouvelle, une après-midi par mois est dédiée à l’expérimentation de n’importe quelle technologie ou sujet tech ! Cette après-midi suivie d’un point de partage permet d’échanger sur des pratiques et des technologies pas forcément utilisées à l’instant T. Et c’est potentiellement ainsi que le futur, tel que Blazor ou GraphQl, s’invite dans nos produits ! L'innovation continue est essentielle pour éviter l'obsolescence.
S’enrichir c’est aussi, parfois, s’endetter
Mettre en place une sentinelle par jour, un vendredi sur deux en frixday, deux semaines par trimestre en tech sprint, et une après-midi par mois d’expérimentation a forcément un coût. Mais pour bâtir plus haut, il faut accepter d’investir à la base.
Grâce à tous ces efforts, en deux ans, nous sommes passés d’une centaine d’erreurs par demi-heure sur plusieurs centaines de millier de requêtes à seulement une dizaine d’erreur par heure. Nous avons pu améliorer le processus de mise en production, qui était sur un rythme manuel d’une fois toutes les deux semaines, à du déploiement continu, automatisé et quotidien. Le tout avec très peu de rollbacks !
Les investissements dans la gestion de la dette technique sont un moyen de s'assurer que votre produit reste compétitif et évite les problèmes majeurs à l'avenir. C'est un enrichissement à long terme qui en vaut la peine.
Retour aux articles