Une alternative au concept de dette logicielle
Hier, j’ai dû présenter à notre board pourquoi un de nos périmètres -bien legacy lui- devait être GRANDEMENT amélioré et refondu (ralentissant par la même notre roadmap produit). Avec mes collègues, on a rapidement évoqué le concept de dette (fonctionnelle et technique), mais j’ai plutôt expérimenté hier une nouvelle métaphore qui a eu l’air d’être beaucoup plus audible pour des gens qui ne font pas directement du logiciel : le concept de réseau routier qui se dégrade.
Pourquoi je n’aime pas le concept de dette pour le logiciel
La plupart des gens dans notre métier parlent de dettes. C’est un concept très clair pour montrer qu’on s’achète du temps ou qu’on a maintenant des choses à rattraper. Par contre, je l’ai toujours trouvé peu performant pour mettre en action des gens et mobiliser des moyens pour agir. Et ça fait longtemps que je cherchais une alternative…
A part les Lannisters…
C’est un ami et anciens collègues qui m’’avait soufflé il y a quelques années de celà (s/o Cyrille Dupuydauby) :
“à part les Lannisters (dans Game of Thrones), personne ne paie ses dettes aujourd’hui Thomas” 🤷♂️.
Ça m’avait marqué à l’époque, et je trouve ça très juste.
En effet, tout le monde est habitué à ne pas régler ses dettes. On les titrise comme à l’époque des sub-primes (comprendre : découper une grosse dette en plusieurs petits bouts qu’on mélange ensuite avec d’autres trucs pour que ça passe crème), on les décale en empruntant encore plus à côté, on les refourgue très souvent aux générations futures (à nos enfants ou aux enfants de nos enfants).
L’impasse de “la prime aux champions”
Dans pleins d’autres entreprises, j’ai tellement vu de fois l’anti-pattern suivant de la “prime aux champions” (faudrait lui trouver un meilleur nom d’ailleurs) :
- Des personnes débutent un nouveau sujet (projet greenfield) en prenant tous les raccourcis possibles pendant quelques mois (allant très vite, mais accumulant aussi pour le coup une dette colossale pour la suite)
- Le management est très content de cette performance et donnent une promotion à ces “champions” en leur demandant de partir vers de nouvelles aventures sur un autre nouveau sujet clé pour les remercier et continuer d’avoir de l’impact dans l’organisation
- Une autre équipe ou des remplaçants arrivent quelques mois (ou années) après pour faire le support du code livré par les premiers “champions”. Ils découvrent assez rapidement qu’il est désormais extrêmement difficile de faire évoluer cette code-base et d’apporter de la valeur efficacement aux utilisateurs (étant donné cette montagne de dette). Ils galèrent.
- Le management ne comprends pas cette situation, et s’imagine même très souvent que les nouveaux devs sont beaucoup moins bons que les premiers (alors que j’ai souvent constaté l’inverse; j’en parle depuis des années en conf : il en faut des skills tech et produit pour faire évoluer du legacy). J’ai déjà entendu dans une ancienne vie pas mal de managers dire : “comment ça se fait que vous n’arrivez pas à vous en sortir ? Au moins avec bidule (un des champions) ça allait beaucoup plus vite quand on voulait ajouter des nouvelles fonctionnalités à l’époque…” 😳🤦♂️ .
- Rinse, Repeat (sur les autres périmètres touchés par les “champions”) 😭
Les équipes qui ont héritées du legacy n’ont très souvent que le concept de dette logicielle à faire valoir pour expliquer la situation aux sponsors ou donneurs d’ordres. Ceci est rarement efficace pour expliquer et convaincre.
Dans mon cas hier, le soupçon d’incompétence de l’équipe n’était pas du tout présent (notre organisation est heureusement beaucoup plus mature que ça).
Mais reprenons mon concept de routes qui se dégradent, puisque c’est l’objet de cet article.
La métaphore du réseau routier
Pour évoquer la situation compliquée dans laquelle nous nous trouvons sur ce vieux périmètre, voici ce que je leur ai dit :
« Le code sur cette partie-là de notre plate-forme, c’est comme… un département où toutes les routes seraient soit détournées (route bloquée, il faut faire le grand tour par l’autre bout du département), soit trop petites, soit trouées, soit truffées de ralentisseurs (et donc qui nous ralentissent pour faire des déplacements qui devraient être bcp plus évidents et rapides normalement).
Les gens qui parcourent ces routes sont soit les utilisateurs et les clients (au runtime), soit les techs (devs, support, sre) qui doivent s’occuper de l’entretien de ces routes, de leur consolidation ou de l’ajout de tunnels, d’autoroutes ou d’aires d’entretien. Et pour pouvoir faire cet entretien iels doivent aussi les parcourir ces routes.
Et comme en plus il y a des clous, des détritus dangereux et des bris de verre un petit peu partout sur les routes qui nécessitent que les devs changent les roues régulièrement (i.e. bug fix), ça ralentit et ça frustre tout le monde.
Vu de l’extérieur vous pourriez être susceptibles de leur dire : ”vous êtes pas encore arrivés ?!? qu’est ce que vous foutez bon sang !” Alors même que les conducteurs (i.e. les devs et sre) ont le dos en compote et n’ont pas dormis car ils ont crevés 3 fois en 2 jours et du changer les pneus autant de fois (au lieu de rouler normalement). Dans certains cas, il a même fallu faire un détour en cours de route pour aller se procurer de nouvelles roues de secours dans un garage du département d’à côté. Mais c’était utile, car on a crevé une nouvelle fois en début de soirée (i.e. pb de prod).
En fonction des situations et des sujets, les devs sur ce périmètre sont aussi bien les conducteurs, que les garagistes, que celles et ceux qui construisent les routes de ce département. On a affaire à des gens très complets, pragmatiques et adaptables (ce qui est rare). »
Au delà de la métaphore
Alors oui ensuite, nous avons dû rentrer un peu plus dans le détail pour pouvoir répondre à leurs questions spécifiques sur notre périmètre (pour matérialiser et donner des exemples), mais j’ai continué tout le long à faire le lien avec cette métaphore de la route).
L’occasion d’expliquer pourquoi certains sujets sont des bloqueurs (i.e. pas de route), pourquoi d’autres problématiques techs sont des ralentisseurs (des petites routes départementales truffées de nid-de-poules et de crevasse), voire des gros goulots d’étranglement comme certaines bases de données ou composants utilisés par tout le monde (un peu comme le tunnel de Fourvière à Lyon où toute la France se croise quelques jours par an pour aller à la montagne ou à la mer), ou des routes dangereuses, truffées de clous (risques de bugs ou problèmes de prod qu’il faudra résoudre quand on touchera à certaines parties).
En conclusion
Les Échos en séance ainsi que ceux récoltés en privé par la suite ont confirmés que cette présentation de nos enjeux à des gens non-techniques a été entendue. On a même eu des retours sympa en PM nous disant que c’était la « première fois que le board se voyait présenter le sujet de l’investissement sur ce périmètre de façon claire et articulée par la tech (et que cela donnait confiance pour la suite des opérations) »
Un autre retour de quelqu’un non tech en message privé : « Top vulgarisation Thomas, merci ! Pour les moldus comme moi c’est génial »
Si cette métaphore a été utile pour nous, peut-être le sera-t-elle aussi pour vous, dans vos équipes et entreprises ?
Note : pour éviter tout malentendu ici, les équipes de dev chez nous n’ont pas besoin de la validation du board pour pouvoir travailler correctement et s’autoriser à faire du refactoring (encore heureux ! 😂). Dans le cas présent il s’agit d’un périmètre sur lequel nous demandions de pouvoir faire des chantiers très importants, et donc — d’impacter la roadmap produit. Raison pour laquelle on a eu besoin d’une validation des CPO, CEO et CTO.
PS: un grand merci à Guillaume COLLIC, Christophe BONVALLET et Simon CHAVENEAU pour leur aide et leurs feedbacks qui m’ont amené à trouver cette métaphore très utile. En particulier Christophe avec son concept de pneu neige 😉
