Description
Léa et Yann ont envie de parler du concept de développeur legacy et on va brainstormer autour de ce concept pour les aider à travailler sur leur talk!
Entre recherche d'informations, recherche d'axes de lecture, venez découvrir le processus d'idéation inhérent à la création d'un talk!
Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.
Transcription
Bonjour à toutes et à tous, et bienvenue dans ce nouvel épisode du podcast Punkin'Dev. Aujourd'hui, je reçois, j'ai l'impression de dire souvent pareil, non pas une, mais deux personnes dans le podcast. Des personnes qui ne sont jamais venues, et rien que ça c'est un grand plaisir. Je vais vous laisser vous présenter, on commence par toi Léa. Bonjour Léa, ça va ?
Bonjour, ça va super, et toi ?
Ça va très bien, est-ce que tu te présenterais pas en deux secondes, rapidement ?
Bien sûr, donc je suis Léa, je suis dev back depuis 4 ou 5 ans. Je travaille pour Shodo Lyon en ce moment et je fais aussi quelques confs, surtout sur des sujets autour des équipes et de comment constituer une bonne équipe change la manière dont on va faire le développement et produit du meilleur dev.
Dac, merci. Donc tu travailles chez Shodo, et chez Shodo tu as un collègue que voilà. Bonjour Yann. Salut. Ça va ?
Ça va et toi ?
Ça va bien. Et bah à ton tour, te présenter. T'as plus le droit de dire que t'es chez Shodo, on l'a déjà dit.
Ah ouais, je suis récemment chez Shodo. Moi ça fait plus de 8 ans que je suis dans le dev, particulièrement en full stack. J'ai rencontré le craft il y a quelques années, et l'année dernière je me suis lancé un peu dans ma première conf, et j'ai bien aimé l'exercice, et c'est pour ça que là, avec Léa, qui est une grande conférencière internationale, je me suis dit qu'on pouvait élaborer un sujet intéressant. Parce qu'on a des expériences qu'on a pu recouper sur des sujets plutôt cools.
Ça, c'est une très bonne nouvelle. Donc du coup, vous allez faire un sujet tous les deux. Qui c'est qui veut me résumer un petit peu le sujet ? Je ne sais pas si vous avez un titre ou un concept là-dedans. Ça ressemble à quoi pour l'instant ?
Pour l'instant, on n'a pas encore de titre. On s'est rendu compte en discutant tous les deux. Je pense qu'on peut dire que Yann et moi, on a travaillé ensemble dans plusieurs... Ce n'est pas la première fois qu'on travaille dans la même entreprise. Et on discute beaucoup de nos pratiques, comment on voit notre métier, etc. Et dans des équipes précédentes, on s'est retrouvés tous les deux à râler sur nos collègues, la manière dont ils font certaines choses. Et c'est Yann qui va raconter son anecdote sur comment on est arrivé sur le... concept qui nous parle à tous les deux de développeur legacy.
Oui, c'est un concept qui a émergé lors d'une discussion de bar évidemment. Après une journée un peu frustrante pour moi. Tout simplement dans une équipe qui avait grandi récemment et dans laquelle on avait des gens qui étaient là depuis assez longtemps, depuis le début du projet et d'autres gens qui arrivaient avec des nouvelles pratiques. on s'est retrouvé en rétro à rediscuter de est-ce que ça vaut vraiment le coup de faire des MR review ? Est-ce que ça vaut vraiment le coup de faire des tests ? Alors que c'était des concepts de qualité qu'on pensait acquis pour une grosse partie de l'équipe. Et le problème c'est que les personnes qui remettaient en question ça c'était les développeurs qui étaient là depuis toujours, qui avaient connu le projet à ses débuts et qui l'avaient transformé en gros plat de spaghettis et c'est pour ça qu'on devait le refactorer pour pour arriver à le maintenir. Suite à cette rétro, on s'était quitté en n'étant pas d'accord, et dans la même journée, on avait un développeur qui avait mergé sur main, forcément déployé en prod, et on s'en était tiré avec 5-6 tickets de bug, parce que le code n'était pas testé, donc le plaisir. Et c'était un des développeurs qui était là depuis le début. Et donc c'est comme ça que j'ai commencé à parler de... de ce concept de développeur legacy, sans trop... Juste pour la blague, parce qu'on parle souvent de code legacy. Et Léa m'en a reparlé à un autre moment, parce qu'elle avait l'expérience de... Une expérience pas tout à fait similaire, mais qu'on pouvait aussi qualifier d'expérience avec des développeurs legacy.
En fait, on a commencé à discuter... En ESN, on... passent beaucoup d'entretiens chez les clients. Et il y a certaines entreprises qui mettent en avant le fait que leurs devs sont là depuis qu'ils n'ont pas beaucoup de turnover, ce qui en soi est une bonne chose pour une culture d'entreprise. Mais en même temps, dans le code, quand on arrive dans une équipe où il n'y a que des devs qui sont là depuis plus de dix ans et qu'il n'y a pas de 109 non plus, on a commencé à dire, ah, mais c'est une bonne chose pour la culture d'entreprise, les gens restent. Mais en même temps, d'un point de vue des pratiques, des fois, c'est un peu un beige flag, on va dire, entre pas vraiment un red flag, mais en même temps, est-ce que c'est une si bonne chose que ça ? Est-ce que vraiment on a envie de rentrer dans cette équipe qui a les mêmes pratiques et les mêmes personnes qui la composent depuis plusieurs années ? Moi, ça m'est arrivé d'être dans des équipes où les devs historiques font beaucoup de choses sur des canaux implicites. Et quand on arrive, c'est dur de comprendre. Il y a des process officiels, mais qui sont... pas vraiment respectées et qui permettent pas de faire ce qu'on veut. Et donc en tant que nouveau dev, pas junior, juste nouveau qui arrive dans cette équipe, on n'a pas forcément la main sur la vraie manière dont les choses se passent. Et donc on s'est dit en discutant que ça se rapprochait un peu de cette idée de dev legacy, c'est-à-dire comme le code, des choses qui sont là depuis longtemps et qui ont un peu leur propre vie en dehors des process officiels.
Alors si j'essaie de recentrer sur la notion de dev legacy, alors je remets la définition, le legacy ça veut dire juste héritage, un code legacy c'est un code dont on hérite. J'ai l'impression que le dev legacy c'est un peu le truc qu'on subit, qui est là, il faut faire avec, comme le code, on peut pas passer outre, ça fait le taf sur certains trucs, mais... Mais ça pose plein d'autres problèmes. Je suis dedans ou vous avez peut-être plus de nuances ?
T'es un peu dedans, mais à la fois, il y a aussi de la nuance. Code Legacy, c'est pas toujours quelque chose de... Comme tu l'as dit, ça veut simplement dire héritage et ça veut pas forcément dire qu'on le subit ou que c'est un problème. C'est juste quelque chose qu'il faut gérer. Il y a des méthodes, il n'y a pas de refacto ou pas. Parfois, il n'y a pas besoin de le résorber, mais ça veut dire que c'est quelque chose qui a une manière de le gérer qui est différente du code moins legacy. Et du coup, les devs legacy, ils ne sont pas forcément... Ce n'est pas forcément une mauvaise chose.
Oui, c'est ce que je disais quelque part. Ils font du taf, le code legacy, même si des fois, il nous fait souffrir. C'est lui qui emprunte, c'est lui qui... permet de gêner souvent du cash ou qui permet de rendre service à des utilisateurs, des utilisatrices. Du coup, effectivement, ce que tu disais, le code legacy, on a a priori des méthodes. pour le gérer. On a des méthodes, des pratiques qui ne marchent pas toutes, mais ce n'est pas une science exacte. Donc vous, votre point, c'est que, si vous parlez de ça, j'imagine que vous avez peut-être commencé à réfléchir sur comment on gère des devs legacy.
Eh bien, c'est l'angle qu'on aimerait prendre avec notre talk, où on aimerait parler de notre expertise en tant que dev, donc plutôt partir de la définition et des techniques. qu'on a l'habitude d'utiliser nous en tant que dev pour gérer du code legacy et voir si on peut l'appliquer à des structures organisationnelles où il y a des dev legacies pour pouvoir un peu résorber ce problème, ces frustrations au quotidien. Donc c'est un peu le point un peu original qu'on voudrait introduire dans ce talk. Mais là c'est le sujet sur lequel on est pas mal en recherche. où on regarde un peu les méthodes de gestion de Legacy Remediation, et on essaye de faire des parallèles, ce qui peut être un peu hasardeux, mais d'un autre côté, ça se recoupe quand même pas mal avec des méthodes de conduite du changement, ce genre de choses, où tu vas faire changer les pratiques des gens au sein des équipes.
En même temps...
Alors, allons-y.
Non, mais en même temps, en regardant des confs d'autres personnes, en lisant des choses, je trouve qu'il y a aussi beaucoup à dire sur qu'est-ce que c'est le code Legacy et à quoi on veut remédier quand on parle de Legacy Remédiation, etc. Parce que c'est ce qu'on disait, c'est à la fois quelque chose qu'on subit, mais à la fois quelque chose qui fait le taf. c'est vrai pour les devs aussi donc il ya aussi une réflexion qu'on aimerait avoir sur Comment avoir du bon legacy, en fait ? Que ce soit humain et technique. C'est-à-dire du legacy qui te sert et qui est, du coup, des équipes qui fonctionnent bien dans la durée.
Dans la définition d'Adrien Joly, le code legacy, c'est un code qui a... La première partie de la définition, c'est un code qui a de la valeur pour l'entreprise. De facto, le développeur legacy, c'est quelqu'un qui a une valeur essentielle à l'entreprise parce qu'il connaît tout l'historique du projet. Il sait des choses que... Pas tout le monde sait. Il sait comment on est arrivé là. Il sait où trouver des bugs, quels bugs sont normaux, dirons-nous. Ce genre de choses, tout l'historique de projet qui peut être un peu touffu, dirons-nous, pour quelqu'un qui arrive dessus de nouveau.
Du coup, là, dans votre réflexion, vous parliez un peu de... chercher des infos, chercher des sources, dans quelle mesure vous appuyez, vous allez essayer de vous appuyer sur de la source académique, entre guillemets, que ce soit des talks, des bouquins, des articles, et dans quelle mesure vous avez aussi peut-être vous des morceaux de retour d'expérience, peut-être de choses que vous avez vues, essayées, je ne sais pas comment vous sourcez votre taf là-dessus.
Ce que j'aime faire habituellement, c'est résoudre les problèmes que j'ai eus moi, donc retour d'expérience sur les problèmes que j'expose. Mais en même temps, il y a beaucoup de sujets qui sont recherchés par des gens dont c'est le métier, et des gens qui ont expérimenté des choses. Et j'aime bien faire un peu un état des lieux de ce qui existe. Et parfois, c'est comme ça que je trouve, je tombe sur des concepts dont je ne savais pas qu'ils existaient, mais qui me permettent de vraiment faire évoluer la manière dont je vois les choses et qui amènent une nouvelle grille de lecture aux choses que je vois dans mon quotidien.
Tu as des exemples un peu concrets de trucs que tu as vus récemment ?
Eh bien, le dernier talk que j'ai fait, c'était sur... qui était sur la sécurité psychologique. Je ne connaissais pas le concept avant. Moi, ce que je voyais, c'est que certaines choses marchaient mieux dans certaines équipes que dans d'autres. Dans certaines équipes, il y avait vraiment beaucoup d'apprentissage global. L'onboarding était facile, ce genre de choses. J'ai commencé par raconter ce qui m'arrivait. Et les gens ont beaucoup relate en se disant Ah oui, moi aussi, c'est comme ça etc. Et en faisant des recherches. Jusqu'à ce que quelqu'un me dise Ah, ce dont tu parles, C'est de la sécurité psychologique. Et du coup, je suis allée lire, j'ai lu des bouquins, j'ai cherché les articles sur Internet. Et effectivement, c'est théorisé, beaucoup recherché depuis 50 ans. Et du coup, ce que j'ai fait et ce que j'aime bien faire, c'est ce concept-là qui est un peu méconnu dans la tech. Peut-être qu'on peut en parler, peut-être qu'on peut l'appliquer à plus d'équipes. Et personnellement, moi, c'est... en faisant Herméneutique, comme je l'ai appris dans le talk de Sarah Dufour, sur le concept de sécurité psychologique, ça m'a aussi donné une grille de lecture de mon quotidien et des leviers pour le changer. Et donc, appliquer à ce qu'on voudrait faire là, c'est un peu similaire, c'est-à-dire que nous, on voit des devs qui se comportent comme du Code Legacy, mais en faisant des recherches sur le Code Legacy, comment on le définit, comment on le traite. Et aussi des recherches, on espère, sur la conduite du changement, comment on fait évoluer les équipes, les frameworks qui existent pour gérer des équipes. Peut-être que ça va nous amener des nouvelles grilles de lecture qui nous permettront de formaliser un peu et de changer notre quotidien sur les dev legacies avec lesquelles on bosse. Ou nous-mêmes quand on est des dev legacies.
Ok, du coup là en fait vous êtes encore en phase d'accumulation de sources, de vous consommer un peu pour créer du... On va créer de la connaissance là-dessus.
D'ailleurs, si tu as des recommandations, on est preneur.
J'en ai assez peu. J'espérais que vous m'en donniez un peu plus sur déjà ce que vous avez eu jusqu'ici. Il y a une partie, je ne sais pas, j'essaie de synthétiser dans ma tête en même temps que ça vient. Il y a une partie un peu conduite du changement qui m'a interpellé. Il y a une partie aussi... Je synthétise, désolé. Je ne sais plus comment vous avez évoqué ça. Quand il y a des process qui sont décrits dans la boîte et qu'en fait, ils ne sont pas respectés et que c'est les devs legacy qui connaissent comment on fait vraiment, plus que l'éventuel doc qui peut traîner à droite à gauche. Ça, c'est des trucs que je trouve intéressants dans le sens où... La première fois où vous m'avez parlé de ce sujet, je me suis dit Ah cool, on va pouvoir tacler les vieux mecs chiants des projets. Et en fait, non seulement c'est d'une moralité douteuse, ma pensée que j'ai eue à ce moment-là, on ne tacle pas des gens comme on tacle du code, le code lui il s'en fout qu'on l'efface, on ne va pas traiter les gens pareil. Mais je trouve ça aussi intéressant de se dire Le code Legacy, c'est lui qui a de la valeur. Donc il y a cet axe un peu de valorisation du legacy, mais en même temps on ne peut pas oublier une partie de remédiation quand il y a un espèce d'immobilisme et de refus d'évoluer vers d'autres choses, que ce soit un refus de personnes qui ne veulent pas ou que ce soit un refus du code parce que le code est ancré depuis tellement longtemps que c'est compliqué de le faire bouger. Est-ce que c'est des axes que vous pensez, que vous envisagez d'exprimer ? dans votre sujet ?
Dans un premier temps, l'idée, c'est de faire des parallèles entre la gestion du code legacy, les techniques et les structures d'équipes de développeurs. Donc forcément, tu as des techniques qui vont être un peu violentes. On ne va pas se le cacher. Mais ça fait partie de l'humour un peu acerbe du talk, je pense. En fait, l'idée, c'est de conclure en donnant des pistes sur comment prévenir ce genre de problème. Parce que tes DevLegacies, c'est ce qu'on dit, ils ont une valeur en tant que connaissance de process, connaissance de métier, etc. Et ça, tu ne veux pas le perdre, tu ne veux pas les faire fuir, parce que c'est valorisable en temps monétairement. Et donc, ton but, c'est aussi de les garder, mais de les faire changer pour pas que ça fruste tes nouveaux devs non plus. Donc, les pistes d'amélioration sont là-dedans.
Après, du coup, comme on a commencé à faire de la biblio, j'ai revu hier le talk de Kavlin Henley que j'avais vu à Newcraft cette année. où il parlait de de dette technique et en fait ça a aussi changé un peu ma perspective là-dessus parce que son take-away c'est un peu que la dette technique c'est pas un problème c'est une conséquence de négligence technique donc on laisse les choses se faire d'elles-mêmes et on n'y revient pas et je trouve que ça s'applique bien à ce qu'on veut faire c'est-à-dire que c'est pas en restant longtemps qu'on devient un dev legacy c'est en remettant pas en cause ses pratiques régulièrement en négligeant son équipe alors elle devient legacy au bout d'un moment alors qu'on peut mais bon après ça c'est normal c'est mutant au début quand on commence un sujet il y a toujours beaucoup de choses qui rentrent d'abord mais moi j'aime bien cette idée que c'est pas une fatalité c'est à dire que si on si on laisse les l'équipe, si on ne prête pas attention à sa propre équipe, alors elle va tourner vers un fonctionnement legacy, c'est-à-dire un truc plus implicite, plus spaghetti, comme si c'était du code. Ce que je disais sur le fait que toutes les communications soient implicites et qu'elles ne suivent pas les process officiels, c'est assez similaire à ça. On passe trop de temps à prendre des raccourcis, à le fameux chemin de... Donc ça me fait penser à quand on marche dans la pelouse et que tout le monde traverse et que ça crée un chemin. Je ne me souviens plus du nom de ce...
Non mais je vois bien l'usage. On a beau faire un joli chemin sinueux qui fait très joli depuis les vues d'en haut, les gens tracent tout droit et du coup ça bouffe la pelouse là où ce n'était pas prévu. Mais les gens prennent le chemin qui est le plus simple a priori, le plus direct.
Donc pour moi, il y a quand même un aspect de si on y prête attention, qu'on remet en cause et qu'on entretient sa dette humaine, en fait, alors on nous dira du legacy qui nous sert au lieu de qu'on subit.
Et surtout que de notre expérience, c'est du legacy que tu subis doublement, parce que grâce à cette magnifique loi de Conway, finalement, quand t'as beaucoup de dev legacy, tu te retrouves facilement avec une big ball of mud de... avec des problèmes pour la maintenir.
Oui, c'est l'aspect technique dont tu parlais. Quand quelqu'un décide de faire tout seul dans son coin et de pousser, c'est des bugs parce que ce n'est pas testé et ce n'est pas dans les pratiques de l'éve. J'aimerais bien arriver à placer le fait que, comme les gens ressemblent à leur chien, le code ressemble à son équipe.
Ah puis là, tu fais ça, tu sors cette phrase, et là j'ai les vieux mèmes qui me passent sur Internet où les gens et leurs chiens se ressemblent souvent, et il y avait des trucs très drôles. Mais quelque part, c'est un des corollaires de la loi de Conway. Ton code finit par ressembler à ton modèle d'organisation et à ton modèle de communication. Si tu as une équipe qui ne communique pas, tu vas avoir des choses qui vont être hyper... hyper hétérogène d'un bout de code à l'autre. Et j'allais dire que c'est globalement inévitable. Effectivement, il faut pouvoir adresser une partie de ta structure de communication pour gérer ta conduite du changement et espérer faire en sorte de modifier un peu la culture qui a fait émerger ce Ausha. Mais en même temps, tu peux la faire par, je ne suis pas expert là-dessus, sur la loi de Conway, mais tu peux la faire par la loi de Conway inversée en agissant sur ton code pour essayer de faire évoluer la culture qui va derrière. Donc ça, c'est deux approches, parce que des fois, faire changer ton organisation quand tu es chez des... Dans des contextes de start-up, c'est facile, ça change tout le temps. De toute façon, il y a une chance sur deux que sous neuf mois, il n'y ait plus personne, que tout soit effondré. Donc ça change plus facilement dans des grosses administrations qui existent depuis 5, 10, 20, 30, 40 ans. Faire bouger des fois vaut mieux repartir par le code, par la technique parfois. À un moment, ce que tu disais Léa, ça m'a rappelé, puisque tu parles de conf que tu as vu récemment. Moi, je suis en train de relire un bouquin. En ce moment, je suis en train de lire la nouvelle édition de Your Code as a Crime Scene de Adam Tornil. J'avais lu la première édition il y a 2-3 ans. Et là, sur la nouvelle, et ça me rappelle des trucs, quand tu parles de dette technique, il a tout un chapitre qui est un peu un plaidoyer sur c'est bien de vouloir s'attaquer à la dette technique et au Legacy. Par contre, il faut s'y attaquer là où c'est pertinent de s'y attaquer. S'il y a un énorme bout de code qui est tout pourri, mais qui marche, et qu'on ne touche pas, eh ben on ne le touche pas. Je ne sais plus où je l'ai entendue celle-ci, c'est qu'on ne nous paye pas pour réparer des trucs qui marchent. Concrètement, je pense qu'il faut centrer toutes les remédiations, tous les outils, toutes les pratiques de gestion du legacy qu'on peut avoir, il faut les mettre là où ça va avoir de la valeur. Et où ça a de la valeur, eh ben ça va avoir de la valeur là où ça nous fait mal en temps normal. Si un fichier qui n'est pas le pire du monde, mais qu'on y retouche toutes les semaines, et qu'à chaque semaine il va de pire en pire, on sait qu'on va avoir un axe de travail là-dessus, qu'on va avoir un réel gain à travailler sur ça. Par contre, là je serais preneur de vos idées sur est-ce que ça c'est applicable en termes d'analyse de comportement humain ? Est-ce qu'on peut voir... Je ne sais pas. Est-ce que c'est transposable sur l'humain ? Est-ce que ça rentre dans votre scope ?
Sur le premier concept, à savoir si tu dois toucher des équipes legacy qui vont finalement fonctionner très bien et te créer de la valeur, je pense qu'il n'y a pas besoin. Si elles arrivent à fonctionner en vase clos et ne pas créer de frustration en dehors. et du coup tu n'as pas besoin de penser à refactorer ce goût d'équipe. Mais c'est sûr que c'est sur les sujets là où il y a de la valeur pour ton business, il faut être le plus attentif et écouter tes devs pour détecter s'il y a des problèmes de développeurs legacy, de gens qui ne font pas circuler les infos, de gens qui ne s'incluent pas dans les pratiques de l'équipe. Parce que tu vas générer de la frustration, du turnover, et la qualité de ton code va le subir aussi.
Après, moi je suis moyen d'accord. Je trouve que ça rentre dans notre scope, mais je ne suis pas d'accord non plus avec le truc on n'est pas payé pour réparer des choses qui marchent c'est vrai mais on n'est pas très bon dans je trouve qu'on n'est pas très bon dans le dev pour mesurer est ce qu'elle marche ou pas les choses et notamment que ce soit dans le code ou dans les équipes si on a un bout dont personne sait comment ça marche ou dans une équipe ce serait l'équivalent ce serait vraiment les faits un peu tour d'ivoire une équipe dont personne sait ce qu'elle fait et comment elle marche mais on sait que ça marche Le problème de ça, c'est que dans l'évaluation du risque, les chances que ça tombe en panne sont faibles, et donc on a tendance à ne pas vouloir y aller, mais les conséquences si ça tombe en panne sont élevées, parce qu'on ne sait pas le réparer. Et c'est quelque chose qu'on prend assez peu en compte dans le dev, les conséquences. Et donc, même si ce n'est pas forcément prioritaire, je trouve que ça vaut le coup des fois de réfectorer quelque chose qui marche, juste parce que... Si ça tombe en panne, on ne saurait pas le faire sinon.
Je vais juste mettre en perspective. Dans le fond, on est d'accord. Mais il y a différentes choses. Ce que tu dis, la partie risque, je peux vous inviter à aller checker un talk récent de Cyril Martraire qui parle de théorie de la résidualité. Alors, je l'ai vu une fois. La première fois, c'est... un peu abrupt comme concept, en même temps c'est un concept sur lequel il y a une thèse qui est en cours, donc c'est pas sec, mais ça reste intéressant, et où justement il propose de soumettre, en exercice de pensée, mais de soumettre nos architectures et notre code à des risques potentiellement, tous les risques possibles et imaginables, et voir qu'est-ce qui peut arriver et qu'est-ce qu'on peut faire soit pour se prémunir de ça au cas où ça arrive, soit pour faire en sorte que ça n'arrive pas, et driver nos architectures par ça. Typiquement, qu'est-ce qui se passe si tout le réseau tombe ? Comment va supporter notre appli ? Est-ce qu'il faut réfléchir à mettre en place un mode hors connexion ou pas ? Par exemple, qu'est-ce qui se passe si j'ai une base de données qui tombe ? Est-ce qu'il y a encore des choses qui peuvent marcher avec des services externes ? Le but, ce n'est pas de dire qu'il faut faire ça ou ça. En général, c'est sur chaque appli quel point est crucial et gérer un petit peu des décisions d'architecture par la gestion du risque. Maintenant, ce que je voulais... Ce que je voulais dire quand je disais qu'on n'est pas payé à réparer des trucs qui marchent, c'est là que le parallèle humain a peut-être sa limite. Concrètement, si un bout de code fonctionne, même si c'est le code le plus dégueulasse du monde, tant qu'on n'a pas à le toucher, il n'y a pas d'intérêt. Il n'y a pas de ROI à venir faire du refacto là-dessus. Là, je me place en tant que manager qui tient le portefeuille. S'il y a mes devs qui disent, on va réparer un bout de code ici, pourquoi ça ne marche pas ? Non, ça marche, laissez-le tranquille. Par contre, c'est bien d'avoir la connaissance de, il y a une grosse big ball of mud là-bas, et le jour où, attention, on va toucher quelque chose là-dessus, stop. Là, on a un gros facteur de risque. Il vaut certainement mieux faire du refacto avant de commencer quoi que ce soit. Ou alors il faut prendre en compte le fait qu'on ne maîtrise pas du tout notre deadline. Et c'est encore un point que défend Adam Tornil dans Your Code as a Crime Scene, puisque lui il propose des pratiques et tout un outillage pour le détecter ça, en amont, et avoir conscience de tes points potentiellement problématiques avant de faire quoi que ce soit. Ce qui permet de driver un petit peu, j'allais dire... certains choix, certains choix de gestion technique et certains choix de communication. Dans le sens où on a plein de points, plein de zones du code qui sont problématiques, on y revient souvent, il faut investir du temps pour faire de l'amélioration continue, pour faire en sorte que ces zones arrêtent de nous coûter autant de pognon. Et aussi identifier, genre ce coin-là, là-bas, on a deux, trois fichiers, 12 000 lignes chacun, qui fonctionnent ensemble, qui sont ultra couplés. Il y a trois ans, on a eu plein de bugs dessus. Maintenant, ça marche. On n'a pas besoin d'y toucher. On n'a pas d'évol qui concerne ça. C'est cool. Par contre, il faut être capable de savoir que ce truc-là existe et de lever une alerte. Bon, on a un truc en lien avec ça. attention, il va falloir faire du refacto ou prévenir toute l'équipe. On se met en best effort sur refactorer ce truc-là et on va prévenir la hiérarchie que non, ce truc-là est hyper risqué. Et peut-être qu'en termes de gestion du risque, le management va dire ça peut-être du coup on ne le fait pas. Si c'est risqué à ce point, si ça nous casse une feature qui est ultra importante, il y a une vraie réflexion à avoir là-dessus. Mais du coup, sans piètre, j'étais en train de me dire que je voulais faire un épisode sur Your Code as a Crime Scene. J'y reviendrai probablement. Mais je vous reparlerai si vous voulez des sources là-dessus. Quand je l'aurai fini, je pourrai vous le prêter le bouquin. Il y a des trucs super intéressants à cet égard-là.
C'est intéressant parce que je sais que c'est un des trucs qui tiennent à cœur à Ian. C'est de proposer un framework ou une méthode pour détecter justement les... les big ball of mud humaines c'est à dire on aimerait bien si on y arrive trouver une forme de questionnaire ou checklist qui vous dit ah attention vous avez une big ball of mud d'humain parce que à l'heure actuelle c'est assez dur à détecter parce que c'est comme du code legacy c'est que ça a des effets pervers de
de des engagements des des personnes Parce que sur ton code Legacy, si c'est dur de l'entretenir, c'est dur de faire des tests dessus, de toute façon il n'y a pas d'autres tests dessus, donc tu ne vas pas commencer à en faire, parce que c'est trop compliqué quand tu vas créer de nouvelles features. Mais de la même façon, si ton organisation fonctionne en mettant en avant tes développeurs Legacy, ou juste ton Legacy humain en général, tu vas adresser le problème une fois ou deux fois, par exemple au moment de la rétro, et s'il n'y a rien qui se passe, tu vas laisser tomber. Et ce sera juste un problème que tu gèreras un peu comme tu peux.
Pour la détection, je te dirais, il y a une troisième partie dans le bouquin que je n'ai pas encore relue, je n'en suis pas encore là, sur justement un petit peu explorer la partie... humaine et sociale du projet via le code parce qu'on peut voir des choses. Je te reparlerai à ce moment-là, tu verras si vous voulez greffer ça dedans. Mais il y a de l'outillage qui existe, notamment sur la gestion du bus factor. En anglais, ils appellent ça le truck factor. Pour les personnes qui ne connaissent pas, c'est combien de personnes de ton équipe peuvent passer sous un bus et que du coup, ton projet tourne encore. Et il n'y a pas une seule réponse sur un projet en général. Il y a des zones qui ont un bus factor qui est très bas. Quant à justement, c'est le principe du dev legacy en général. Quand tu as ton dev qui est là depuis 8-9 ans, il y a des zones où c'est la seule personne qui sait comment ça marche. Et si cette personne-là se barre de manière voulue ou non. Ouais, ça va être compliqué. Il va y avoir un point de gestion à traiter dessus. Et... Et s'il y a des gens qui se disent Ouais, mais ça n'arrive pas. Alors, si ça arrive, des devs qui disparaissent du jour au lendemain pour x ou y raison, ça peut arriver. Et même des fois, alors on dit toujours oui, il y a des préavis s'ils se barrent. J'ai un collègue qui s'est arrivé, vraiment un de leurs collègues, j'ai juste jamais revenu. Il s'est pris une voiture, accident et fin de vie. Ils ont eu à gérer ce problème-là, premier degré. Genre, on a le principal sachant du projet qui est décédé. Donc du jour au lendemain, on a un énorme trou de connaissances, comment on gère, comment on aurait dû gérer en amont. Et sur la conduite du changement et le partage de connaissances, ils ont mis en place plein de trucs. Il faudrait que je retrouve cette personne-là qui nous raconte un peu comment ils ont géré et réagi derrière. Mais c'est un truc qu'on met souvent au second plan, genre non mais ça va pas arriver. Bah si, ça arrive. Et comme tu disais Léa, c'est de la gestion du risque. Qu'est-ce que tu acceptes comme niveau de risque sur certains trucs ?
Et oui, et pour revenir sur l'invisibilité de ce problème, c'est aussi parce que tes développeurs legacy, comme ils sont historiques, c'est eux qui ont la légitimité sur le projet, et c'est par eux que tu vas sonder tes équipes, en tant que manager souvent, parce que tu auras une relation privilégiée avec eux, vu que tu les auras connus depuis super longtemps. Et donc il y a des canaux comme ça, implicites, qui vont se créer, et tu ne vas jamais avoir le problème... chez les nouveaux devs. Pour pouvoir régler ce genre de choses et savoir ce qui se passe, il faut créer des canaux avec tous les membres des équipes pour sonder ce qui se passe.
Est-ce que vous avez une vision de la... justement de ce que tu dis, la posture des devs legacy qui ont des canaux de communication privilégiés de fait de leur ancienneté. Après, c'est peut-être plus lointain, c'est une question qui me venait comme ça sur la gestion de la culture. Quand tu as des nouveaux profils, tu peux avoir toute la richesse des profils humains, mais... Comment ça peut se gérer, s'intégrer à tout ça ? Le fait d'avoir soit des nouveaux profils qui vont prendre beaucoup de place. J'ai déjà eu le cas dans une équipe des jeunes devs qui sortent d'école, qui savent mieux que tout le monde. Le vieux de la vieille, il a deux, trois infos que peut-être t'as pas. Même s'il est vieux et qu'effectivement il est pénible parce qu'il reste campé sur plein de positions, des fois il a peut-être des bonnes raisons. Et à l'inverse, des profils qui vont se faire digérer beaucoup plus vite par le legacy, qui ne vont pas arriver à remettre en cause parce que des fois, c'est une question de profil très personnel. Il y a des gens qui vont chercher à surtout pas faire de vagues. Et je vais essayer de mimiquer le plus possible la culture en place pour m'intégrer, parce que je gère comme ça. Enfin voilà, tous les profils existent. Je ne sais pas si... Au-delà du dev legacy, c'est un peu plus la dette humaine. En fait, j'ai le petit problème avec le dev legacy, c'est que ça a tendance à pointer une personne. Alors que ce n'est pas forcément le cas, c'est plus le système qui est en place. Mais quant à du legacy humain, en sens général, sur l'équipe, ça va se reproduire un peu tout seul. Est-ce que vous avez vu, vous voyez, vous imaginez justement des leviers pour... Et pour limiter l'impact de tout ça ?
Déjà, je suis d'accord avec toi que c'est un système et pas des personnes. Parce que j'ai été dans des startups où il reste le fondateur qui veut faire son truc dans son coin, mais en fait, le système et l'organisation ne lui permettent pas d'avoir l'impact de... disrupter un peu le flow de tout le monde. Et en fait, ce n'est pas un problème. C'est-à-dire qu'il y a toujours cette personne qui a une connaissance extensive du projet et qui a plein d'idées, mais les idées, elles sont absorbées et utilisées d'une manière qui fait grandir tout le monde par l'organisation. Du coup, je suppose qu'on pourrait apprendre d'eux. Mais pas que. Sur les méthodes et... Déjà de manière évidente, l'agilité quand c'est arrivé, moi je n'étais pas dans l'informatique avant l'agilité, mais les frameworks, que ce soit Scrum ou autre, de l'agilité, ça a quand même amené de l'explicite dans l'organisation des équipes et dans le partage de connaissances, qui permettent de remettre en cause un peu comment on fait les choses, de manière plus ritualisée, etc. Même si ça a forcément aussi des effets pervers, etc. Je pense que ça a déjà amené des choses là-dessus. Et je voulais aussi parler dans la lignée de Extreme Programming, où on va dire cette famille de pensées, de faire le code, etc., qui permettent aussi d'expliciter le partage de connaissances, d'expliciter la manière dont les équipes fonctionnent. Et c'est des pistes pour faire rentrer des nouvelles personnes dans l'équipe, diffuser les connaissances Legacy de gens qui sont là depuis longtemps, depuis des gens qui viennent d'arriver.
J'avais une autre remarque sur le... On parle de Legacy. Je rebondis sur des trucs que vous avez dit il y a un petit moment déjà. Sur la notion de Dev Legacy. Un peu en lien avec ce que je disais juste avant. Faire en sorte que les gens ne se fassent pas digérer trop vite par le système. L'agilité adresse ces trucs. Je vais citer ma source du moment, Adam Tornil, il en parle, il justifie ça justement avec l'arrivée des pratiques agiles et des formats d'itération qui sont plus courts qu'avant. Il y a des études assez sérieuses, il faut que je note dans un coin de tête, enfin en vrai sur un bout de papier, que je puisse les ressortir. Il y a des sources sérieuses là-dessus. Il y a une vraie étude qui a été menée sur cette notion de legacy qui est souvent liée avec la dimension, j'allais dire, plutôt maintenance évolutive des applis. À une époque où on n'avait que Waterfall, c'était normal d'avoir des projets qui vivaient 6 mois, 1 an, 1 an et demi avant de partir en prod. Et de fait, on itérait peu ou pas sur de l'existant, on rajoutait de la feature, on rajoutait de la feature, et on commençait à réouvrir l'existant que quand on partait en maintenance et qu'il y avait des évoles à faire. Avec les process agiles, en gros, passer la première itération... Pour ces gens-là et pour Adam Tornil, passer la première itération, qui dure une semaine, deux semaines, trois semaines ou même deux mois, passer ça, on est dans du legacy, parce qu'on va itérer sur du plus court, parce qu'on va relire plus de codes que ce qu'on va en produire. Là où avec Waterfall, on faisait des specs fonctionnels, des specs techniques détaillés, on implémentait, on ajoutait le package, ça partait en recettes, et on passait au sujet suivant, et il y avait généralement très peu de collisions. d'une feature à l'autre puisqu'on a ajouté des trucs. Aujourd'hui, en fait, le legacy, il naît dès l'itération 2, même souvent l'itération 1 puisque tu vas souvent avoir un sprint 0 pour bootstrapper l'archi, les machins. Donc, en gros, dès l'itération 1, quelque part, t'es en legacy, t'es en maintenance et j'ai presque envie de dire n'importe quel dev devient dev legacy quasiment tout de suite, tu deviens ton propre legacy. Ça devient un peu méta, un peu déprimant. J'arrive sur un projet, au bout de 15 jours, ça y est, je suis mon propre legacy, il faut que je gère ma propre résistance au changement, alors que je suis là potentiellement pour amener du changement. Je ne sais pas si c'est des axes, des trucs que vous avez observés, des axes que vous voulez aborder sur le sujet.
Clairement... on n'est pas allé aussi loin sur les concepts de développeurs legacy et même de code legacy comme par itération agile comme tu en parles c'est un axe super intéressant et de la même façon en fait pour pouvoir gérer tes problèmes de legacy humain il faut faire des petites itérations aussi et tester des trucs sur la structure de ton équipe sur quel rôle à quelle personne etc et Comment définir les rôles ? Est-ce que tu mets en place des pratiques de mentoring ? Comment tu fais ce genre de choses ? Pour essayer des choses et trouver ce qui fonctionne avec ton équipe pour résorber aussi ce problème de DevLegacy tout en ayant conscience, comme tu viens de le définir, que dès ta première itération, finalement, tu deviens un DevLegacy parce que tu as un savoir qui est inhérent à ce que tu as fait sur la code base. et qui n'est pas forcément diffusée dans le reste de l'équipe.
Oui, moi, c'est souvent ma conclusion. C'est vraiment un truc que je trouve important, c'est souvent on essaye de résoudre des problèmes, et le problème, c'est nous. C'est souvent la conclusion de la plupart des sujets que j'aborde, qui est qu'on peut toujours commencer par soi-même pour s'améliorer, et ce qui est important, c'est de douter. Je ne sais plus qui a dit ça, mais si tu doutes et que tu remets en cause ta pratique tout le temps, pas la changer, mais juste remettre en cause, challenger les décisions que tu as prises, vérifier, parce qu'une décision, quand tu la prends, des fois, elle est bonne, mais une semaine après, elle n'est plus valable. Et donc, il y a forcément un... À la fois, il faut toujours remettre en cause, à la fois, il faut trouver un équilibre, parce qu'on ne peut pas repartir de zéro à chaque... à chaque itération. Et moi, c'est les sujets qui m'intéressent en général. C'est-à-dire trouver cet équilibre entre ce qu'on acquiert et ce qu'on remet en cause et continuer à évoluer tout le temps. Oui, toujours grandir, toujours apprendre en tant qu'individu et en tant que groupe.
Quelque part, c'est un des principes de l'agilité. À intervalles réguliers, prendre le temps de sortir la tête. J'ai plus le... libelles exactes, mais prendre le temps de sortir la tête du guidon et de remettre en question, de remettre en cause, de se poser, plutôt que d'être dans un rush perpétuel où tu ne remets plus en cause ce que tu fais et comment tu le fais. En sachant que le comment, oui. Et il y a plus en plus de devs qui soutiennent ce que tu disais, c'est que lire du code, écrire du code, c'est la partie facile de notre métier. Gérer des interactions humaines, c'est la partie difficile. Donc oui, on est en plein de... on est en plein dedans.
Et ce que tu disais sur les gens qui seront absorbés par le legacy humain, j'aimerais bien, on verra s'il y a une place dans tout ça parce qu'on est un peu partis dans toutes les directions, mais j'aimerais bien qu'on arrive à placer des choses sur ce qui se fait en mentoring tournant ou en mentoring inversé. C'est un autre de mes dada. Je trouve qu'on n'apprend pas assez des nouvelles personnes des équipes, mais surtout des juniors, des gens qui ont une moins grande expertise technique. On a du mal à intégrer ce qu'ils amènent dans les équipes en général, dans mon expérience en tout cas. Dans notre sujet, il y a aussi un sujet autour de ça, c'est-à-dire... Pour se remettre en question, c'est bien d'apprendre de gens qui ont une vie, que ce soit des sorties d'école, qui ont plein d'idées, qui savent mieux que tout le monde, ils sont un peu pénibles, mais ils savent effectivement plein de choses. Ou des personnes qui ne viennent pas de là, on a des tas de choses à apprendre d'un nouveau membre de l'équipe, au moins dans son questionnement. Parce que ça va être plus facile pour lui ou elle de poser des questions, pourquoi vous avez fait ça de cette manière-là.
La question naïve est toujours un super indicateur. c'est un bon thermomètre je comprends pas pourquoi vous avez fait ça et des fois tu te retrouves à devoir expliquer et des fois tu peux pas parce que tu sais plus et du coup il y a eu un problème de passation de connaissances et des fois, moi ça m'est arrivé de me sentir con en me disant ouais c'était vrai il y a un an et demi quand on a fait ce choix mais ça n'a plus aucun sens maintenant alors que la question était naïve sans chercher à attaquer ça, enfin factuellement ça arrive Et j'aime bien ces parties de questions naïves qu'il faut savoir prendre avec toute la bienveillance possible. Pas faire... Il n'y a pas le temps. Éviter ce travers-là qu'on peut avoir des fois quand on a des fois une hiérarchie qui ne nous laisse pas le temps. C'est pour ça que quand on prend des juniors, c'est bien de laisser le temps aux seniors de s'en occuper. En général c'est la base, si tu fais pas ça il va y avoir une autre problématique, ça c'est un autre axe, une autre problématique de justement de gestion d'équipe prendre des juniors parce que ça coûte pas cher c'est pas une fin en soi tu prends des juniors parce que tu donnes le temps aux seniors de s'en occuper, de les faire monter en compétences, de leur expliquer tout ce qu'il y a à savoir et de transmettre et de gérer aussi le bus factor puisque ça doit venir avec ça sans pour autant les formater Et là, c'est dur.
Mais du coup, l'inverse aussi. Je trouve qu'il faut laisser le temps au senior d'apprendre. Oui,
c'est ce dont je parle dans ma conf, moi, sur la posture d'humilité. De considérer que même si c'est un junior, tu peux apprendre des choses de cette personne et donc vraiment remettre en question ta position pour lui laisser la place de s'exprimer. Parce que c'est en faisant du père avec des juniors que des fois tu apprends des trucs de fou.
Il y a un dernier point qui me faisait question, où en vrai je suis curieux de voir votre talk une fois tout terminé. La première fois que vous en avez parlé, vous me parliez de... un peu de gestion du legacy humain, et des techniques de refacto. Moi, je sais plus ou moins refactorer du code, je vais typer des trucs, je vais encapsuler des comportements, je vais extraire des méthodes, j'ai plein de trucs à faire. J'ai potentiellement... Enfin, j'imagine des trucs, mais j'ai un peu de mal à voir jusqu'où on peut faire des parallèles comme ça sur de l'humain. Vous avez commencé à lister des choses qui s'y prêtent bien, et d'autres pas du tout.
je veux du spoil la métaphore la plus facile c'est la mais c'est plus pour la blague c'est la refonte from scratch où du coup tu tu changes d'équipe pour refaire le produit le parallèle chez les humains c'est tu changes l'équipe tu vires tout le monde tu prends des nouveaux et tu refais et le parallèle il s'étend un peu parce que personnellement c'est pas quelque chose que je trouve qui marche bien de repartir de zéro sur un logiciel et en même temps ça marche pas non plus sur les équipes c'est à dire virer tout le monde et recommencer t'as rien appris du coup de ce que t'as fait la première fois et c'est aussi vrai sur le code voilà Après, pour le reste, on a un peu commencé, mais en même temps, on ne veut pas déshumaniser non plus. C'est-à-dire qu'il y a la blague, c'est marrant, de considérer le Human Legacy comme le Code Legacy. En même temps, on n'est pas non plus là pour... On en a parlé un petit peu, pour montrer du doigt, dire que le Dev Legacy, c'est mal, c'est vous, c'est de votre faute, personnellement, etc. Donc il faut quand même arriver à trouver des parallèles qui... qui à la fois sont pertinents et ne sont pas des parallèles de dictateurs. Donc on y travaille, on aimerait bien que ça fonctionne, mais faudrait voir ce que ça donne quand même.
Et l'idée c'est de l'introduire aussi dans la forme, sur un truc un peu plus type discussion entre Léa et moi, comme on pourrait avoir en buvant une bière, où on pourrait discuter de ces parallèles-là sans vraiment que ça ait un impact dans ce qu'on fait au quotidien. C'est aussi le fait de... Quand on parle de refonte ou de Strangler Fig pour appliquer à des humains, tu peux très bien imaginer ton étranglé des développeurs, mais c'est pas... C'est parce qu'on veut que les gens retenaient de la con. C'est juste pour faire des blagues aussi.
Tu peux redéfinir le Strangler Fig ? Je pense pas que tout le monde qui écoutera ça connaît le pattern.
Le Strangler Fig, c'est un pattern de gestion du legacy sur lequel tu vas... Pour des nouvelles features, mettre... t'isoler complètement de tes interactions avec ton... Oh, isoler, non. Mettre une couche de... d'ACL. Ah, j'ai perdu le... Anticorruption. Anticorruption, je ne sais pas pourquoi je ne l'avais plus. Une couche d'anticorruption à chacune de tes interactions avec le Legacy, pour être complètement isolé de son comportement et avoir aucun effet de bord dû à son fonctionnement. Et au fur et à mesure... tu vas pouvoir faire comme le palmiétrangleur, le figuierétrangleur, grappiller un peu ton legacy, le sortir, ses responsabilités, les mettre dans ton application qui finalement est développée avec des meilleures pratiques et mieux faites, et l'étouffer au fur et à mesure ton legacy pour que jamais il déborde sur ta refonte.
Mais tu vois, c'est... Comme on en a parlé là, je pense que c'est un peu ce qui se passait dans la startup dont je parlais. C'est-à-dire que les fondateurs et les gens qui avaient tout un tas d'idées, ils étaient entourés de, pas de gens qui les étranglent, mais de PO ou de devs qui comprenaient le besoin et agissaient un peu comme une couche anti-corruption, c'est-à-dire... décider, enfin DPO, DPM aussi d'ailleurs, adapter les idées pour en faire quelque chose qui servirait le produit tel qu'il est maintenant. Ce qui permettait à la fois de profiter de toutes ces idées et ne pas complètement refaire un Big Bang à chaque fois qu'il y avait une nouvelle idée géniale. Après, ce n'est pas extrêmement novateur. Il y a plein de gens qui font ça. Il paraît que c'est comme ça que Tesla gère Elon Musk.
Je ne sais pas comment il... Je ne veux pas... Je ne sais pas si j'ai envie de parler de ce mec-là.
On peut le.
Tu pourrais le couter. Mais force est de constater, oui, que je pense qu'il y a plein de choses qui, dans les boîtes d'Elon Musk et d'autres, il y a des équipes qui réussissent malgré leur hiérarchie. Et il y aurait peut-être beaucoup à prendre de ces équipes-là, très premier degré. Donc, il y a peut-être quelque chose à voir là-dedans. Ça fait un moment qu'on cause, du coup. Donc, sur le... Je sais pas par quel bout le prendre. Sur l'avancée de votre sujet, aujourd'hui, alors on a... En fait, on a... J'étais censé vous aider, tout ça, à avancer. En fait, on a juste brainstormé sur tout ce qui peut arriver. On a parlé du sujet, parce que moi, je dérive. Le sujet m'intéresse aussi éminemment, parce que c'est un des... Je pense que c'est un des... des plus gros points qu'on a dans notre métier, c'est de gérer l'existant. Vous, vous vous sentez comment pour, j'allais dire, pour continuer à avancer, à travailler sur ce sujet et pour revenir dans un mois ou deux pour le présenter tout fini, tout beau, tout prêt ?
Moi, je ne suis pas déçue parce que c'est toujours comme ça. J'ai une idée. Ensuite, il y a une phase d'expansion où déjà, il existe des choses. Donc, je vois... Je consomme du savoir. Je vois des vidéos, je lis des trucs. Et il y a un moment où je me dis Oh là là, mais il va me falloir 10 heures pour présenter tout ça parce que, bien sûr que c'est le nouveau framework de lecture du monde entier qui va révolutionner la tech. Après, on arrive à trouver la niche, le point particulier dont on a envie de parler, qu'on trouve intéressant, plus intéressant que le reste. plus facile ou qui va correspondre au format. Et du coup, je pense que de tout ce dont on a parlé, quand on aura fini de voir toutes nos sources et de re-brainstormer encore... Il y aura peut-être, si ça se trouve, rien dans le talk final. J'espère pas, mais...
Je ne pense pas.
Mais du coup, oui, là, on est en phase d'expansion de... Ah, ce sujet, il est lié à ça, qui est lié à ça, qui est lié à ça. Et après, il y aura une phase de concentration.
Oui, clairement.
Moi, j'aimerais beaucoup, pour l'auditoire qui est toujours là, essayer des... des remarques, des souhaits d'activer plus là-dessus. Je trouverais ça intéressant au moment où je vais le publier sur les réseaux, qu'il puisse y avoir des discussions en dessous, je trouverais ça très très cool. Parce que le sujet est justement à hyper basse, comme tu dis. Il y a des sources qui vont de partout, il y a du vécu je pense qu'il y a à prendre en compte. J'aime bien avoir des sources un peu... scientifique, je mets des gros guillemets en visuel, mais un peu... Ouais, avec de la data sourcée. J'aime bien ce type de données qui a en général plus de poids, mais du vécu d'une personne, d'une deuxième, d'une troisième, des fois ça donne des bons axes de lecture et de recherche. Donc moi je trouverais ça intéressant.
Oui, j'allais rebondir sur ce que disait Léa, pour dire qu'on était clairement au début de notre travail et que... Pour l'instant, on a orienté notre talk tel qu'on te l'a présenté, mais on n'est pas sûr qu'il ressemblera à ça à la fin. Et pour le moment, dans le taf qu'on a fait, on essaye d'en sortir un abstract pour pouvoir soumettre, pour pouvoir bénéficier des jours de création de contenu Shodo. Et il faudra venir voir le talk, parce qu'en plus, tu pourras apprécier les illustrations de Eve.
C'est presque une private joke. Du coup, Eve a fait des illustrations pour plusieurs tools qui ont à chaque fois plutôt bien marché. Donc, ça sera avec grand plaisir. S'il y a des gens qui ont envie de discuter avec vous de ça, Léa, t'as au moins un réseau, t'es au moins sur LinkedIn, je crois. Tu es contactable ?
Je suis sur LinkedIn, je m'appelle Léa Coston et on me voit parfois dans les meet-ups lyonnais.
Ok. Yann, je sais pas si t'as... Beaucoup de réseaux, c'est visible.
Alors moi malheureusement je n'ai pas beaucoup de réseaux, donc c'est plus dur de me contacter comme ça. Après vous pouvez dénicher ma première conf et récupérer mon adresse mail perso si vous voulez vraiment me contacter absolument. Mais sinon vous pouvez passer par Léa, je pense qu'elle me fera parvenir les messages. Et sinon oui je traite dans les meetups lyonnais, particulièrement celui des crafters, le meetup Python et LyonJS de temps à autre. Au plaisir de s'y croiser.
Eh bien, merci à tous les deux d'être venus. Ça me fait un épisode qui sort un peu de l'ordinaire. Ça faisait une discussion autant sur le fond que sur la forme, j'aime bien. J'ai vraiment bien envie que vous repassiez quand le sujet sera plus sec. Quitte à vous donner des idées dans la discussion pour faire des suites. parce que je pense que ça peut appeler des suites donc encore une fois merci d'être venu et puis quant à vous, quant à toi cher auditoire, auditeur, auditrice qui nous a écouté jusqu'ici il me reste à te souhaiter une excellente fin de semaine à la prochaine pour un nouvel épisode et d'ici là, geekez bien et codez bien
Description
Léa et Yann ont envie de parler du concept de développeur legacy et on va brainstormer autour de ce concept pour les aider à travailler sur leur talk!
Entre recherche d'informations, recherche d'axes de lecture, venez découvrir le processus d'idéation inhérent à la création d'un talk!
Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.
Transcription
Bonjour à toutes et à tous, et bienvenue dans ce nouvel épisode du podcast Punkin'Dev. Aujourd'hui, je reçois, j'ai l'impression de dire souvent pareil, non pas une, mais deux personnes dans le podcast. Des personnes qui ne sont jamais venues, et rien que ça c'est un grand plaisir. Je vais vous laisser vous présenter, on commence par toi Léa. Bonjour Léa, ça va ?
Bonjour, ça va super, et toi ?
Ça va très bien, est-ce que tu te présenterais pas en deux secondes, rapidement ?
Bien sûr, donc je suis Léa, je suis dev back depuis 4 ou 5 ans. Je travaille pour Shodo Lyon en ce moment et je fais aussi quelques confs, surtout sur des sujets autour des équipes et de comment constituer une bonne équipe change la manière dont on va faire le développement et produit du meilleur dev.
Dac, merci. Donc tu travailles chez Shodo, et chez Shodo tu as un collègue que voilà. Bonjour Yann. Salut. Ça va ?
Ça va et toi ?
Ça va bien. Et bah à ton tour, te présenter. T'as plus le droit de dire que t'es chez Shodo, on l'a déjà dit.
Ah ouais, je suis récemment chez Shodo. Moi ça fait plus de 8 ans que je suis dans le dev, particulièrement en full stack. J'ai rencontré le craft il y a quelques années, et l'année dernière je me suis lancé un peu dans ma première conf, et j'ai bien aimé l'exercice, et c'est pour ça que là, avec Léa, qui est une grande conférencière internationale, je me suis dit qu'on pouvait élaborer un sujet intéressant. Parce qu'on a des expériences qu'on a pu recouper sur des sujets plutôt cools.
Ça, c'est une très bonne nouvelle. Donc du coup, vous allez faire un sujet tous les deux. Qui c'est qui veut me résumer un petit peu le sujet ? Je ne sais pas si vous avez un titre ou un concept là-dedans. Ça ressemble à quoi pour l'instant ?
Pour l'instant, on n'a pas encore de titre. On s'est rendu compte en discutant tous les deux. Je pense qu'on peut dire que Yann et moi, on a travaillé ensemble dans plusieurs... Ce n'est pas la première fois qu'on travaille dans la même entreprise. Et on discute beaucoup de nos pratiques, comment on voit notre métier, etc. Et dans des équipes précédentes, on s'est retrouvés tous les deux à râler sur nos collègues, la manière dont ils font certaines choses. Et c'est Yann qui va raconter son anecdote sur comment on est arrivé sur le... concept qui nous parle à tous les deux de développeur legacy.
Oui, c'est un concept qui a émergé lors d'une discussion de bar évidemment. Après une journée un peu frustrante pour moi. Tout simplement dans une équipe qui avait grandi récemment et dans laquelle on avait des gens qui étaient là depuis assez longtemps, depuis le début du projet et d'autres gens qui arrivaient avec des nouvelles pratiques. on s'est retrouvé en rétro à rediscuter de est-ce que ça vaut vraiment le coup de faire des MR review ? Est-ce que ça vaut vraiment le coup de faire des tests ? Alors que c'était des concepts de qualité qu'on pensait acquis pour une grosse partie de l'équipe. Et le problème c'est que les personnes qui remettaient en question ça c'était les développeurs qui étaient là depuis toujours, qui avaient connu le projet à ses débuts et qui l'avaient transformé en gros plat de spaghettis et c'est pour ça qu'on devait le refactorer pour pour arriver à le maintenir. Suite à cette rétro, on s'était quitté en n'étant pas d'accord, et dans la même journée, on avait un développeur qui avait mergé sur main, forcément déployé en prod, et on s'en était tiré avec 5-6 tickets de bug, parce que le code n'était pas testé, donc le plaisir. Et c'était un des développeurs qui était là depuis le début. Et donc c'est comme ça que j'ai commencé à parler de... de ce concept de développeur legacy, sans trop... Juste pour la blague, parce qu'on parle souvent de code legacy. Et Léa m'en a reparlé à un autre moment, parce qu'elle avait l'expérience de... Une expérience pas tout à fait similaire, mais qu'on pouvait aussi qualifier d'expérience avec des développeurs legacy.
En fait, on a commencé à discuter... En ESN, on... passent beaucoup d'entretiens chez les clients. Et il y a certaines entreprises qui mettent en avant le fait que leurs devs sont là depuis qu'ils n'ont pas beaucoup de turnover, ce qui en soi est une bonne chose pour une culture d'entreprise. Mais en même temps, dans le code, quand on arrive dans une équipe où il n'y a que des devs qui sont là depuis plus de dix ans et qu'il n'y a pas de 109 non plus, on a commencé à dire, ah, mais c'est une bonne chose pour la culture d'entreprise, les gens restent. Mais en même temps, d'un point de vue des pratiques, des fois, c'est un peu un beige flag, on va dire, entre pas vraiment un red flag, mais en même temps, est-ce que c'est une si bonne chose que ça ? Est-ce que vraiment on a envie de rentrer dans cette équipe qui a les mêmes pratiques et les mêmes personnes qui la composent depuis plusieurs années ? Moi, ça m'est arrivé d'être dans des équipes où les devs historiques font beaucoup de choses sur des canaux implicites. Et quand on arrive, c'est dur de comprendre. Il y a des process officiels, mais qui sont... pas vraiment respectées et qui permettent pas de faire ce qu'on veut. Et donc en tant que nouveau dev, pas junior, juste nouveau qui arrive dans cette équipe, on n'a pas forcément la main sur la vraie manière dont les choses se passent. Et donc on s'est dit en discutant que ça se rapprochait un peu de cette idée de dev legacy, c'est-à-dire comme le code, des choses qui sont là depuis longtemps et qui ont un peu leur propre vie en dehors des process officiels.
Alors si j'essaie de recentrer sur la notion de dev legacy, alors je remets la définition, le legacy ça veut dire juste héritage, un code legacy c'est un code dont on hérite. J'ai l'impression que le dev legacy c'est un peu le truc qu'on subit, qui est là, il faut faire avec, comme le code, on peut pas passer outre, ça fait le taf sur certains trucs, mais... Mais ça pose plein d'autres problèmes. Je suis dedans ou vous avez peut-être plus de nuances ?
T'es un peu dedans, mais à la fois, il y a aussi de la nuance. Code Legacy, c'est pas toujours quelque chose de... Comme tu l'as dit, ça veut simplement dire héritage et ça veut pas forcément dire qu'on le subit ou que c'est un problème. C'est juste quelque chose qu'il faut gérer. Il y a des méthodes, il n'y a pas de refacto ou pas. Parfois, il n'y a pas besoin de le résorber, mais ça veut dire que c'est quelque chose qui a une manière de le gérer qui est différente du code moins legacy. Et du coup, les devs legacy, ils ne sont pas forcément... Ce n'est pas forcément une mauvaise chose.
Oui, c'est ce que je disais quelque part. Ils font du taf, le code legacy, même si des fois, il nous fait souffrir. C'est lui qui emprunte, c'est lui qui... permet de gêner souvent du cash ou qui permet de rendre service à des utilisateurs, des utilisatrices. Du coup, effectivement, ce que tu disais, le code legacy, on a a priori des méthodes. pour le gérer. On a des méthodes, des pratiques qui ne marchent pas toutes, mais ce n'est pas une science exacte. Donc vous, votre point, c'est que, si vous parlez de ça, j'imagine que vous avez peut-être commencé à réfléchir sur comment on gère des devs legacy.
Eh bien, c'est l'angle qu'on aimerait prendre avec notre talk, où on aimerait parler de notre expertise en tant que dev, donc plutôt partir de la définition et des techniques. qu'on a l'habitude d'utiliser nous en tant que dev pour gérer du code legacy et voir si on peut l'appliquer à des structures organisationnelles où il y a des dev legacies pour pouvoir un peu résorber ce problème, ces frustrations au quotidien. Donc c'est un peu le point un peu original qu'on voudrait introduire dans ce talk. Mais là c'est le sujet sur lequel on est pas mal en recherche. où on regarde un peu les méthodes de gestion de Legacy Remediation, et on essaye de faire des parallèles, ce qui peut être un peu hasardeux, mais d'un autre côté, ça se recoupe quand même pas mal avec des méthodes de conduite du changement, ce genre de choses, où tu vas faire changer les pratiques des gens au sein des équipes.
En même temps...
Alors, allons-y.
Non, mais en même temps, en regardant des confs d'autres personnes, en lisant des choses, je trouve qu'il y a aussi beaucoup à dire sur qu'est-ce que c'est le code Legacy et à quoi on veut remédier quand on parle de Legacy Remédiation, etc. Parce que c'est ce qu'on disait, c'est à la fois quelque chose qu'on subit, mais à la fois quelque chose qui fait le taf. c'est vrai pour les devs aussi donc il ya aussi une réflexion qu'on aimerait avoir sur Comment avoir du bon legacy, en fait ? Que ce soit humain et technique. C'est-à-dire du legacy qui te sert et qui est, du coup, des équipes qui fonctionnent bien dans la durée.
Dans la définition d'Adrien Joly, le code legacy, c'est un code qui a... La première partie de la définition, c'est un code qui a de la valeur pour l'entreprise. De facto, le développeur legacy, c'est quelqu'un qui a une valeur essentielle à l'entreprise parce qu'il connaît tout l'historique du projet. Il sait des choses que... Pas tout le monde sait. Il sait comment on est arrivé là. Il sait où trouver des bugs, quels bugs sont normaux, dirons-nous. Ce genre de choses, tout l'historique de projet qui peut être un peu touffu, dirons-nous, pour quelqu'un qui arrive dessus de nouveau.
Du coup, là, dans votre réflexion, vous parliez un peu de... chercher des infos, chercher des sources, dans quelle mesure vous appuyez, vous allez essayer de vous appuyer sur de la source académique, entre guillemets, que ce soit des talks, des bouquins, des articles, et dans quelle mesure vous avez aussi peut-être vous des morceaux de retour d'expérience, peut-être de choses que vous avez vues, essayées, je ne sais pas comment vous sourcez votre taf là-dessus.
Ce que j'aime faire habituellement, c'est résoudre les problèmes que j'ai eus moi, donc retour d'expérience sur les problèmes que j'expose. Mais en même temps, il y a beaucoup de sujets qui sont recherchés par des gens dont c'est le métier, et des gens qui ont expérimenté des choses. Et j'aime bien faire un peu un état des lieux de ce qui existe. Et parfois, c'est comme ça que je trouve, je tombe sur des concepts dont je ne savais pas qu'ils existaient, mais qui me permettent de vraiment faire évoluer la manière dont je vois les choses et qui amènent une nouvelle grille de lecture aux choses que je vois dans mon quotidien.
Tu as des exemples un peu concrets de trucs que tu as vus récemment ?
Eh bien, le dernier talk que j'ai fait, c'était sur... qui était sur la sécurité psychologique. Je ne connaissais pas le concept avant. Moi, ce que je voyais, c'est que certaines choses marchaient mieux dans certaines équipes que dans d'autres. Dans certaines équipes, il y avait vraiment beaucoup d'apprentissage global. L'onboarding était facile, ce genre de choses. J'ai commencé par raconter ce qui m'arrivait. Et les gens ont beaucoup relate en se disant Ah oui, moi aussi, c'est comme ça etc. Et en faisant des recherches. Jusqu'à ce que quelqu'un me dise Ah, ce dont tu parles, C'est de la sécurité psychologique. Et du coup, je suis allée lire, j'ai lu des bouquins, j'ai cherché les articles sur Internet. Et effectivement, c'est théorisé, beaucoup recherché depuis 50 ans. Et du coup, ce que j'ai fait et ce que j'aime bien faire, c'est ce concept-là qui est un peu méconnu dans la tech. Peut-être qu'on peut en parler, peut-être qu'on peut l'appliquer à plus d'équipes. Et personnellement, moi, c'est... en faisant Herméneutique, comme je l'ai appris dans le talk de Sarah Dufour, sur le concept de sécurité psychologique, ça m'a aussi donné une grille de lecture de mon quotidien et des leviers pour le changer. Et donc, appliquer à ce qu'on voudrait faire là, c'est un peu similaire, c'est-à-dire que nous, on voit des devs qui se comportent comme du Code Legacy, mais en faisant des recherches sur le Code Legacy, comment on le définit, comment on le traite. Et aussi des recherches, on espère, sur la conduite du changement, comment on fait évoluer les équipes, les frameworks qui existent pour gérer des équipes. Peut-être que ça va nous amener des nouvelles grilles de lecture qui nous permettront de formaliser un peu et de changer notre quotidien sur les dev legacies avec lesquelles on bosse. Ou nous-mêmes quand on est des dev legacies.
Ok, du coup là en fait vous êtes encore en phase d'accumulation de sources, de vous consommer un peu pour créer du... On va créer de la connaissance là-dessus.
D'ailleurs, si tu as des recommandations, on est preneur.
J'en ai assez peu. J'espérais que vous m'en donniez un peu plus sur déjà ce que vous avez eu jusqu'ici. Il y a une partie, je ne sais pas, j'essaie de synthétiser dans ma tête en même temps que ça vient. Il y a une partie un peu conduite du changement qui m'a interpellé. Il y a une partie aussi... Je synthétise, désolé. Je ne sais plus comment vous avez évoqué ça. Quand il y a des process qui sont décrits dans la boîte et qu'en fait, ils ne sont pas respectés et que c'est les devs legacy qui connaissent comment on fait vraiment, plus que l'éventuel doc qui peut traîner à droite à gauche. Ça, c'est des trucs que je trouve intéressants dans le sens où... La première fois où vous m'avez parlé de ce sujet, je me suis dit Ah cool, on va pouvoir tacler les vieux mecs chiants des projets. Et en fait, non seulement c'est d'une moralité douteuse, ma pensée que j'ai eue à ce moment-là, on ne tacle pas des gens comme on tacle du code, le code lui il s'en fout qu'on l'efface, on ne va pas traiter les gens pareil. Mais je trouve ça aussi intéressant de se dire Le code Legacy, c'est lui qui a de la valeur. Donc il y a cet axe un peu de valorisation du legacy, mais en même temps on ne peut pas oublier une partie de remédiation quand il y a un espèce d'immobilisme et de refus d'évoluer vers d'autres choses, que ce soit un refus de personnes qui ne veulent pas ou que ce soit un refus du code parce que le code est ancré depuis tellement longtemps que c'est compliqué de le faire bouger. Est-ce que c'est des axes que vous pensez, que vous envisagez d'exprimer ? dans votre sujet ?
Dans un premier temps, l'idée, c'est de faire des parallèles entre la gestion du code legacy, les techniques et les structures d'équipes de développeurs. Donc forcément, tu as des techniques qui vont être un peu violentes. On ne va pas se le cacher. Mais ça fait partie de l'humour un peu acerbe du talk, je pense. En fait, l'idée, c'est de conclure en donnant des pistes sur comment prévenir ce genre de problème. Parce que tes DevLegacies, c'est ce qu'on dit, ils ont une valeur en tant que connaissance de process, connaissance de métier, etc. Et ça, tu ne veux pas le perdre, tu ne veux pas les faire fuir, parce que c'est valorisable en temps monétairement. Et donc, ton but, c'est aussi de les garder, mais de les faire changer pour pas que ça fruste tes nouveaux devs non plus. Donc, les pistes d'amélioration sont là-dedans.
Après, du coup, comme on a commencé à faire de la biblio, j'ai revu hier le talk de Kavlin Henley que j'avais vu à Newcraft cette année. où il parlait de de dette technique et en fait ça a aussi changé un peu ma perspective là-dessus parce que son take-away c'est un peu que la dette technique c'est pas un problème c'est une conséquence de négligence technique donc on laisse les choses se faire d'elles-mêmes et on n'y revient pas et je trouve que ça s'applique bien à ce qu'on veut faire c'est-à-dire que c'est pas en restant longtemps qu'on devient un dev legacy c'est en remettant pas en cause ses pratiques régulièrement en négligeant son équipe alors elle devient legacy au bout d'un moment alors qu'on peut mais bon après ça c'est normal c'est mutant au début quand on commence un sujet il y a toujours beaucoup de choses qui rentrent d'abord mais moi j'aime bien cette idée que c'est pas une fatalité c'est à dire que si on si on laisse les l'équipe, si on ne prête pas attention à sa propre équipe, alors elle va tourner vers un fonctionnement legacy, c'est-à-dire un truc plus implicite, plus spaghetti, comme si c'était du code. Ce que je disais sur le fait que toutes les communications soient implicites et qu'elles ne suivent pas les process officiels, c'est assez similaire à ça. On passe trop de temps à prendre des raccourcis, à le fameux chemin de... Donc ça me fait penser à quand on marche dans la pelouse et que tout le monde traverse et que ça crée un chemin. Je ne me souviens plus du nom de ce...
Non mais je vois bien l'usage. On a beau faire un joli chemin sinueux qui fait très joli depuis les vues d'en haut, les gens tracent tout droit et du coup ça bouffe la pelouse là où ce n'était pas prévu. Mais les gens prennent le chemin qui est le plus simple a priori, le plus direct.
Donc pour moi, il y a quand même un aspect de si on y prête attention, qu'on remet en cause et qu'on entretient sa dette humaine, en fait, alors on nous dira du legacy qui nous sert au lieu de qu'on subit.
Et surtout que de notre expérience, c'est du legacy que tu subis doublement, parce que grâce à cette magnifique loi de Conway, finalement, quand t'as beaucoup de dev legacy, tu te retrouves facilement avec une big ball of mud de... avec des problèmes pour la maintenir.
Oui, c'est l'aspect technique dont tu parlais. Quand quelqu'un décide de faire tout seul dans son coin et de pousser, c'est des bugs parce que ce n'est pas testé et ce n'est pas dans les pratiques de l'éve. J'aimerais bien arriver à placer le fait que, comme les gens ressemblent à leur chien, le code ressemble à son équipe.
Ah puis là, tu fais ça, tu sors cette phrase, et là j'ai les vieux mèmes qui me passent sur Internet où les gens et leurs chiens se ressemblent souvent, et il y avait des trucs très drôles. Mais quelque part, c'est un des corollaires de la loi de Conway. Ton code finit par ressembler à ton modèle d'organisation et à ton modèle de communication. Si tu as une équipe qui ne communique pas, tu vas avoir des choses qui vont être hyper... hyper hétérogène d'un bout de code à l'autre. Et j'allais dire que c'est globalement inévitable. Effectivement, il faut pouvoir adresser une partie de ta structure de communication pour gérer ta conduite du changement et espérer faire en sorte de modifier un peu la culture qui a fait émerger ce Ausha. Mais en même temps, tu peux la faire par, je ne suis pas expert là-dessus, sur la loi de Conway, mais tu peux la faire par la loi de Conway inversée en agissant sur ton code pour essayer de faire évoluer la culture qui va derrière. Donc ça, c'est deux approches, parce que des fois, faire changer ton organisation quand tu es chez des... Dans des contextes de start-up, c'est facile, ça change tout le temps. De toute façon, il y a une chance sur deux que sous neuf mois, il n'y ait plus personne, que tout soit effondré. Donc ça change plus facilement dans des grosses administrations qui existent depuis 5, 10, 20, 30, 40 ans. Faire bouger des fois vaut mieux repartir par le code, par la technique parfois. À un moment, ce que tu disais Léa, ça m'a rappelé, puisque tu parles de conf que tu as vu récemment. Moi, je suis en train de relire un bouquin. En ce moment, je suis en train de lire la nouvelle édition de Your Code as a Crime Scene de Adam Tornil. J'avais lu la première édition il y a 2-3 ans. Et là, sur la nouvelle, et ça me rappelle des trucs, quand tu parles de dette technique, il a tout un chapitre qui est un peu un plaidoyer sur c'est bien de vouloir s'attaquer à la dette technique et au Legacy. Par contre, il faut s'y attaquer là où c'est pertinent de s'y attaquer. S'il y a un énorme bout de code qui est tout pourri, mais qui marche, et qu'on ne touche pas, eh ben on ne le touche pas. Je ne sais plus où je l'ai entendue celle-ci, c'est qu'on ne nous paye pas pour réparer des trucs qui marchent. Concrètement, je pense qu'il faut centrer toutes les remédiations, tous les outils, toutes les pratiques de gestion du legacy qu'on peut avoir, il faut les mettre là où ça va avoir de la valeur. Et où ça a de la valeur, eh ben ça va avoir de la valeur là où ça nous fait mal en temps normal. Si un fichier qui n'est pas le pire du monde, mais qu'on y retouche toutes les semaines, et qu'à chaque semaine il va de pire en pire, on sait qu'on va avoir un axe de travail là-dessus, qu'on va avoir un réel gain à travailler sur ça. Par contre, là je serais preneur de vos idées sur est-ce que ça c'est applicable en termes d'analyse de comportement humain ? Est-ce qu'on peut voir... Je ne sais pas. Est-ce que c'est transposable sur l'humain ? Est-ce que ça rentre dans votre scope ?
Sur le premier concept, à savoir si tu dois toucher des équipes legacy qui vont finalement fonctionner très bien et te créer de la valeur, je pense qu'il n'y a pas besoin. Si elles arrivent à fonctionner en vase clos et ne pas créer de frustration en dehors. et du coup tu n'as pas besoin de penser à refactorer ce goût d'équipe. Mais c'est sûr que c'est sur les sujets là où il y a de la valeur pour ton business, il faut être le plus attentif et écouter tes devs pour détecter s'il y a des problèmes de développeurs legacy, de gens qui ne font pas circuler les infos, de gens qui ne s'incluent pas dans les pratiques de l'équipe. Parce que tu vas générer de la frustration, du turnover, et la qualité de ton code va le subir aussi.
Après, moi je suis moyen d'accord. Je trouve que ça rentre dans notre scope, mais je ne suis pas d'accord non plus avec le truc on n'est pas payé pour réparer des choses qui marchent c'est vrai mais on n'est pas très bon dans je trouve qu'on n'est pas très bon dans le dev pour mesurer est ce qu'elle marche ou pas les choses et notamment que ce soit dans le code ou dans les équipes si on a un bout dont personne sait comment ça marche ou dans une équipe ce serait l'équivalent ce serait vraiment les faits un peu tour d'ivoire une équipe dont personne sait ce qu'elle fait et comment elle marche mais on sait que ça marche Le problème de ça, c'est que dans l'évaluation du risque, les chances que ça tombe en panne sont faibles, et donc on a tendance à ne pas vouloir y aller, mais les conséquences si ça tombe en panne sont élevées, parce qu'on ne sait pas le réparer. Et c'est quelque chose qu'on prend assez peu en compte dans le dev, les conséquences. Et donc, même si ce n'est pas forcément prioritaire, je trouve que ça vaut le coup des fois de réfectorer quelque chose qui marche, juste parce que... Si ça tombe en panne, on ne saurait pas le faire sinon.
Je vais juste mettre en perspective. Dans le fond, on est d'accord. Mais il y a différentes choses. Ce que tu dis, la partie risque, je peux vous inviter à aller checker un talk récent de Cyril Martraire qui parle de théorie de la résidualité. Alors, je l'ai vu une fois. La première fois, c'est... un peu abrupt comme concept, en même temps c'est un concept sur lequel il y a une thèse qui est en cours, donc c'est pas sec, mais ça reste intéressant, et où justement il propose de soumettre, en exercice de pensée, mais de soumettre nos architectures et notre code à des risques potentiellement, tous les risques possibles et imaginables, et voir qu'est-ce qui peut arriver et qu'est-ce qu'on peut faire soit pour se prémunir de ça au cas où ça arrive, soit pour faire en sorte que ça n'arrive pas, et driver nos architectures par ça. Typiquement, qu'est-ce qui se passe si tout le réseau tombe ? Comment va supporter notre appli ? Est-ce qu'il faut réfléchir à mettre en place un mode hors connexion ou pas ? Par exemple, qu'est-ce qui se passe si j'ai une base de données qui tombe ? Est-ce qu'il y a encore des choses qui peuvent marcher avec des services externes ? Le but, ce n'est pas de dire qu'il faut faire ça ou ça. En général, c'est sur chaque appli quel point est crucial et gérer un petit peu des décisions d'architecture par la gestion du risque. Maintenant, ce que je voulais... Ce que je voulais dire quand je disais qu'on n'est pas payé à réparer des trucs qui marchent, c'est là que le parallèle humain a peut-être sa limite. Concrètement, si un bout de code fonctionne, même si c'est le code le plus dégueulasse du monde, tant qu'on n'a pas à le toucher, il n'y a pas d'intérêt. Il n'y a pas de ROI à venir faire du refacto là-dessus. Là, je me place en tant que manager qui tient le portefeuille. S'il y a mes devs qui disent, on va réparer un bout de code ici, pourquoi ça ne marche pas ? Non, ça marche, laissez-le tranquille. Par contre, c'est bien d'avoir la connaissance de, il y a une grosse big ball of mud là-bas, et le jour où, attention, on va toucher quelque chose là-dessus, stop. Là, on a un gros facteur de risque. Il vaut certainement mieux faire du refacto avant de commencer quoi que ce soit. Ou alors il faut prendre en compte le fait qu'on ne maîtrise pas du tout notre deadline. Et c'est encore un point que défend Adam Tornil dans Your Code as a Crime Scene, puisque lui il propose des pratiques et tout un outillage pour le détecter ça, en amont, et avoir conscience de tes points potentiellement problématiques avant de faire quoi que ce soit. Ce qui permet de driver un petit peu, j'allais dire... certains choix, certains choix de gestion technique et certains choix de communication. Dans le sens où on a plein de points, plein de zones du code qui sont problématiques, on y revient souvent, il faut investir du temps pour faire de l'amélioration continue, pour faire en sorte que ces zones arrêtent de nous coûter autant de pognon. Et aussi identifier, genre ce coin-là, là-bas, on a deux, trois fichiers, 12 000 lignes chacun, qui fonctionnent ensemble, qui sont ultra couplés. Il y a trois ans, on a eu plein de bugs dessus. Maintenant, ça marche. On n'a pas besoin d'y toucher. On n'a pas d'évol qui concerne ça. C'est cool. Par contre, il faut être capable de savoir que ce truc-là existe et de lever une alerte. Bon, on a un truc en lien avec ça. attention, il va falloir faire du refacto ou prévenir toute l'équipe. On se met en best effort sur refactorer ce truc-là et on va prévenir la hiérarchie que non, ce truc-là est hyper risqué. Et peut-être qu'en termes de gestion du risque, le management va dire ça peut-être du coup on ne le fait pas. Si c'est risqué à ce point, si ça nous casse une feature qui est ultra importante, il y a une vraie réflexion à avoir là-dessus. Mais du coup, sans piètre, j'étais en train de me dire que je voulais faire un épisode sur Your Code as a Crime Scene. J'y reviendrai probablement. Mais je vous reparlerai si vous voulez des sources là-dessus. Quand je l'aurai fini, je pourrai vous le prêter le bouquin. Il y a des trucs super intéressants à cet égard-là.
C'est intéressant parce que je sais que c'est un des trucs qui tiennent à cœur à Ian. C'est de proposer un framework ou une méthode pour détecter justement les... les big ball of mud humaines c'est à dire on aimerait bien si on y arrive trouver une forme de questionnaire ou checklist qui vous dit ah attention vous avez une big ball of mud d'humain parce que à l'heure actuelle c'est assez dur à détecter parce que c'est comme du code legacy c'est que ça a des effets pervers de
de des engagements des des personnes Parce que sur ton code Legacy, si c'est dur de l'entretenir, c'est dur de faire des tests dessus, de toute façon il n'y a pas d'autres tests dessus, donc tu ne vas pas commencer à en faire, parce que c'est trop compliqué quand tu vas créer de nouvelles features. Mais de la même façon, si ton organisation fonctionne en mettant en avant tes développeurs Legacy, ou juste ton Legacy humain en général, tu vas adresser le problème une fois ou deux fois, par exemple au moment de la rétro, et s'il n'y a rien qui se passe, tu vas laisser tomber. Et ce sera juste un problème que tu gèreras un peu comme tu peux.
Pour la détection, je te dirais, il y a une troisième partie dans le bouquin que je n'ai pas encore relue, je n'en suis pas encore là, sur justement un petit peu explorer la partie... humaine et sociale du projet via le code parce qu'on peut voir des choses. Je te reparlerai à ce moment-là, tu verras si vous voulez greffer ça dedans. Mais il y a de l'outillage qui existe, notamment sur la gestion du bus factor. En anglais, ils appellent ça le truck factor. Pour les personnes qui ne connaissent pas, c'est combien de personnes de ton équipe peuvent passer sous un bus et que du coup, ton projet tourne encore. Et il n'y a pas une seule réponse sur un projet en général. Il y a des zones qui ont un bus factor qui est très bas. Quant à justement, c'est le principe du dev legacy en général. Quand tu as ton dev qui est là depuis 8-9 ans, il y a des zones où c'est la seule personne qui sait comment ça marche. Et si cette personne-là se barre de manière voulue ou non. Ouais, ça va être compliqué. Il va y avoir un point de gestion à traiter dessus. Et... Et s'il y a des gens qui se disent Ouais, mais ça n'arrive pas. Alors, si ça arrive, des devs qui disparaissent du jour au lendemain pour x ou y raison, ça peut arriver. Et même des fois, alors on dit toujours oui, il y a des préavis s'ils se barrent. J'ai un collègue qui s'est arrivé, vraiment un de leurs collègues, j'ai juste jamais revenu. Il s'est pris une voiture, accident et fin de vie. Ils ont eu à gérer ce problème-là, premier degré. Genre, on a le principal sachant du projet qui est décédé. Donc du jour au lendemain, on a un énorme trou de connaissances, comment on gère, comment on aurait dû gérer en amont. Et sur la conduite du changement et le partage de connaissances, ils ont mis en place plein de trucs. Il faudrait que je retrouve cette personne-là qui nous raconte un peu comment ils ont géré et réagi derrière. Mais c'est un truc qu'on met souvent au second plan, genre non mais ça va pas arriver. Bah si, ça arrive. Et comme tu disais Léa, c'est de la gestion du risque. Qu'est-ce que tu acceptes comme niveau de risque sur certains trucs ?
Et oui, et pour revenir sur l'invisibilité de ce problème, c'est aussi parce que tes développeurs legacy, comme ils sont historiques, c'est eux qui ont la légitimité sur le projet, et c'est par eux que tu vas sonder tes équipes, en tant que manager souvent, parce que tu auras une relation privilégiée avec eux, vu que tu les auras connus depuis super longtemps. Et donc il y a des canaux comme ça, implicites, qui vont se créer, et tu ne vas jamais avoir le problème... chez les nouveaux devs. Pour pouvoir régler ce genre de choses et savoir ce qui se passe, il faut créer des canaux avec tous les membres des équipes pour sonder ce qui se passe.
Est-ce que vous avez une vision de la... justement de ce que tu dis, la posture des devs legacy qui ont des canaux de communication privilégiés de fait de leur ancienneté. Après, c'est peut-être plus lointain, c'est une question qui me venait comme ça sur la gestion de la culture. Quand tu as des nouveaux profils, tu peux avoir toute la richesse des profils humains, mais... Comment ça peut se gérer, s'intégrer à tout ça ? Le fait d'avoir soit des nouveaux profils qui vont prendre beaucoup de place. J'ai déjà eu le cas dans une équipe des jeunes devs qui sortent d'école, qui savent mieux que tout le monde. Le vieux de la vieille, il a deux, trois infos que peut-être t'as pas. Même s'il est vieux et qu'effectivement il est pénible parce qu'il reste campé sur plein de positions, des fois il a peut-être des bonnes raisons. Et à l'inverse, des profils qui vont se faire digérer beaucoup plus vite par le legacy, qui ne vont pas arriver à remettre en cause parce que des fois, c'est une question de profil très personnel. Il y a des gens qui vont chercher à surtout pas faire de vagues. Et je vais essayer de mimiquer le plus possible la culture en place pour m'intégrer, parce que je gère comme ça. Enfin voilà, tous les profils existent. Je ne sais pas si... Au-delà du dev legacy, c'est un peu plus la dette humaine. En fait, j'ai le petit problème avec le dev legacy, c'est que ça a tendance à pointer une personne. Alors que ce n'est pas forcément le cas, c'est plus le système qui est en place. Mais quant à du legacy humain, en sens général, sur l'équipe, ça va se reproduire un peu tout seul. Est-ce que vous avez vu, vous voyez, vous imaginez justement des leviers pour... Et pour limiter l'impact de tout ça ?
Déjà, je suis d'accord avec toi que c'est un système et pas des personnes. Parce que j'ai été dans des startups où il reste le fondateur qui veut faire son truc dans son coin, mais en fait, le système et l'organisation ne lui permettent pas d'avoir l'impact de... disrupter un peu le flow de tout le monde. Et en fait, ce n'est pas un problème. C'est-à-dire qu'il y a toujours cette personne qui a une connaissance extensive du projet et qui a plein d'idées, mais les idées, elles sont absorbées et utilisées d'une manière qui fait grandir tout le monde par l'organisation. Du coup, je suppose qu'on pourrait apprendre d'eux. Mais pas que. Sur les méthodes et... Déjà de manière évidente, l'agilité quand c'est arrivé, moi je n'étais pas dans l'informatique avant l'agilité, mais les frameworks, que ce soit Scrum ou autre, de l'agilité, ça a quand même amené de l'explicite dans l'organisation des équipes et dans le partage de connaissances, qui permettent de remettre en cause un peu comment on fait les choses, de manière plus ritualisée, etc. Même si ça a forcément aussi des effets pervers, etc. Je pense que ça a déjà amené des choses là-dessus. Et je voulais aussi parler dans la lignée de Extreme Programming, où on va dire cette famille de pensées, de faire le code, etc., qui permettent aussi d'expliciter le partage de connaissances, d'expliciter la manière dont les équipes fonctionnent. Et c'est des pistes pour faire rentrer des nouvelles personnes dans l'équipe, diffuser les connaissances Legacy de gens qui sont là depuis longtemps, depuis des gens qui viennent d'arriver.
J'avais une autre remarque sur le... On parle de Legacy. Je rebondis sur des trucs que vous avez dit il y a un petit moment déjà. Sur la notion de Dev Legacy. Un peu en lien avec ce que je disais juste avant. Faire en sorte que les gens ne se fassent pas digérer trop vite par le système. L'agilité adresse ces trucs. Je vais citer ma source du moment, Adam Tornil, il en parle, il justifie ça justement avec l'arrivée des pratiques agiles et des formats d'itération qui sont plus courts qu'avant. Il y a des études assez sérieuses, il faut que je note dans un coin de tête, enfin en vrai sur un bout de papier, que je puisse les ressortir. Il y a des sources sérieuses là-dessus. Il y a une vraie étude qui a été menée sur cette notion de legacy qui est souvent liée avec la dimension, j'allais dire, plutôt maintenance évolutive des applis. À une époque où on n'avait que Waterfall, c'était normal d'avoir des projets qui vivaient 6 mois, 1 an, 1 an et demi avant de partir en prod. Et de fait, on itérait peu ou pas sur de l'existant, on rajoutait de la feature, on rajoutait de la feature, et on commençait à réouvrir l'existant que quand on partait en maintenance et qu'il y avait des évoles à faire. Avec les process agiles, en gros, passer la première itération... Pour ces gens-là et pour Adam Tornil, passer la première itération, qui dure une semaine, deux semaines, trois semaines ou même deux mois, passer ça, on est dans du legacy, parce qu'on va itérer sur du plus court, parce qu'on va relire plus de codes que ce qu'on va en produire. Là où avec Waterfall, on faisait des specs fonctionnels, des specs techniques détaillés, on implémentait, on ajoutait le package, ça partait en recettes, et on passait au sujet suivant, et il y avait généralement très peu de collisions. d'une feature à l'autre puisqu'on a ajouté des trucs. Aujourd'hui, en fait, le legacy, il naît dès l'itération 2, même souvent l'itération 1 puisque tu vas souvent avoir un sprint 0 pour bootstrapper l'archi, les machins. Donc, en gros, dès l'itération 1, quelque part, t'es en legacy, t'es en maintenance et j'ai presque envie de dire n'importe quel dev devient dev legacy quasiment tout de suite, tu deviens ton propre legacy. Ça devient un peu méta, un peu déprimant. J'arrive sur un projet, au bout de 15 jours, ça y est, je suis mon propre legacy, il faut que je gère ma propre résistance au changement, alors que je suis là potentiellement pour amener du changement. Je ne sais pas si c'est des axes, des trucs que vous avez observés, des axes que vous voulez aborder sur le sujet.
Clairement... on n'est pas allé aussi loin sur les concepts de développeurs legacy et même de code legacy comme par itération agile comme tu en parles c'est un axe super intéressant et de la même façon en fait pour pouvoir gérer tes problèmes de legacy humain il faut faire des petites itérations aussi et tester des trucs sur la structure de ton équipe sur quel rôle à quelle personne etc et Comment définir les rôles ? Est-ce que tu mets en place des pratiques de mentoring ? Comment tu fais ce genre de choses ? Pour essayer des choses et trouver ce qui fonctionne avec ton équipe pour résorber aussi ce problème de DevLegacy tout en ayant conscience, comme tu viens de le définir, que dès ta première itération, finalement, tu deviens un DevLegacy parce que tu as un savoir qui est inhérent à ce que tu as fait sur la code base. et qui n'est pas forcément diffusée dans le reste de l'équipe.
Oui, moi, c'est souvent ma conclusion. C'est vraiment un truc que je trouve important, c'est souvent on essaye de résoudre des problèmes, et le problème, c'est nous. C'est souvent la conclusion de la plupart des sujets que j'aborde, qui est qu'on peut toujours commencer par soi-même pour s'améliorer, et ce qui est important, c'est de douter. Je ne sais plus qui a dit ça, mais si tu doutes et que tu remets en cause ta pratique tout le temps, pas la changer, mais juste remettre en cause, challenger les décisions que tu as prises, vérifier, parce qu'une décision, quand tu la prends, des fois, elle est bonne, mais une semaine après, elle n'est plus valable. Et donc, il y a forcément un... À la fois, il faut toujours remettre en cause, à la fois, il faut trouver un équilibre, parce qu'on ne peut pas repartir de zéro à chaque... à chaque itération. Et moi, c'est les sujets qui m'intéressent en général. C'est-à-dire trouver cet équilibre entre ce qu'on acquiert et ce qu'on remet en cause et continuer à évoluer tout le temps. Oui, toujours grandir, toujours apprendre en tant qu'individu et en tant que groupe.
Quelque part, c'est un des principes de l'agilité. À intervalles réguliers, prendre le temps de sortir la tête. J'ai plus le... libelles exactes, mais prendre le temps de sortir la tête du guidon et de remettre en question, de remettre en cause, de se poser, plutôt que d'être dans un rush perpétuel où tu ne remets plus en cause ce que tu fais et comment tu le fais. En sachant que le comment, oui. Et il y a plus en plus de devs qui soutiennent ce que tu disais, c'est que lire du code, écrire du code, c'est la partie facile de notre métier. Gérer des interactions humaines, c'est la partie difficile. Donc oui, on est en plein de... on est en plein dedans.
Et ce que tu disais sur les gens qui seront absorbés par le legacy humain, j'aimerais bien, on verra s'il y a une place dans tout ça parce qu'on est un peu partis dans toutes les directions, mais j'aimerais bien qu'on arrive à placer des choses sur ce qui se fait en mentoring tournant ou en mentoring inversé. C'est un autre de mes dada. Je trouve qu'on n'apprend pas assez des nouvelles personnes des équipes, mais surtout des juniors, des gens qui ont une moins grande expertise technique. On a du mal à intégrer ce qu'ils amènent dans les équipes en général, dans mon expérience en tout cas. Dans notre sujet, il y a aussi un sujet autour de ça, c'est-à-dire... Pour se remettre en question, c'est bien d'apprendre de gens qui ont une vie, que ce soit des sorties d'école, qui ont plein d'idées, qui savent mieux que tout le monde, ils sont un peu pénibles, mais ils savent effectivement plein de choses. Ou des personnes qui ne viennent pas de là, on a des tas de choses à apprendre d'un nouveau membre de l'équipe, au moins dans son questionnement. Parce que ça va être plus facile pour lui ou elle de poser des questions, pourquoi vous avez fait ça de cette manière-là.
La question naïve est toujours un super indicateur. c'est un bon thermomètre je comprends pas pourquoi vous avez fait ça et des fois tu te retrouves à devoir expliquer et des fois tu peux pas parce que tu sais plus et du coup il y a eu un problème de passation de connaissances et des fois, moi ça m'est arrivé de me sentir con en me disant ouais c'était vrai il y a un an et demi quand on a fait ce choix mais ça n'a plus aucun sens maintenant alors que la question était naïve sans chercher à attaquer ça, enfin factuellement ça arrive Et j'aime bien ces parties de questions naïves qu'il faut savoir prendre avec toute la bienveillance possible. Pas faire... Il n'y a pas le temps. Éviter ce travers-là qu'on peut avoir des fois quand on a des fois une hiérarchie qui ne nous laisse pas le temps. C'est pour ça que quand on prend des juniors, c'est bien de laisser le temps aux seniors de s'en occuper. En général c'est la base, si tu fais pas ça il va y avoir une autre problématique, ça c'est un autre axe, une autre problématique de justement de gestion d'équipe prendre des juniors parce que ça coûte pas cher c'est pas une fin en soi tu prends des juniors parce que tu donnes le temps aux seniors de s'en occuper, de les faire monter en compétences, de leur expliquer tout ce qu'il y a à savoir et de transmettre et de gérer aussi le bus factor puisque ça doit venir avec ça sans pour autant les formater Et là, c'est dur.
Mais du coup, l'inverse aussi. Je trouve qu'il faut laisser le temps au senior d'apprendre. Oui,
c'est ce dont je parle dans ma conf, moi, sur la posture d'humilité. De considérer que même si c'est un junior, tu peux apprendre des choses de cette personne et donc vraiment remettre en question ta position pour lui laisser la place de s'exprimer. Parce que c'est en faisant du père avec des juniors que des fois tu apprends des trucs de fou.
Il y a un dernier point qui me faisait question, où en vrai je suis curieux de voir votre talk une fois tout terminé. La première fois que vous en avez parlé, vous me parliez de... un peu de gestion du legacy humain, et des techniques de refacto. Moi, je sais plus ou moins refactorer du code, je vais typer des trucs, je vais encapsuler des comportements, je vais extraire des méthodes, j'ai plein de trucs à faire. J'ai potentiellement... Enfin, j'imagine des trucs, mais j'ai un peu de mal à voir jusqu'où on peut faire des parallèles comme ça sur de l'humain. Vous avez commencé à lister des choses qui s'y prêtent bien, et d'autres pas du tout.
je veux du spoil la métaphore la plus facile c'est la mais c'est plus pour la blague c'est la refonte from scratch où du coup tu tu changes d'équipe pour refaire le produit le parallèle chez les humains c'est tu changes l'équipe tu vires tout le monde tu prends des nouveaux et tu refais et le parallèle il s'étend un peu parce que personnellement c'est pas quelque chose que je trouve qui marche bien de repartir de zéro sur un logiciel et en même temps ça marche pas non plus sur les équipes c'est à dire virer tout le monde et recommencer t'as rien appris du coup de ce que t'as fait la première fois et c'est aussi vrai sur le code voilà Après, pour le reste, on a un peu commencé, mais en même temps, on ne veut pas déshumaniser non plus. C'est-à-dire qu'il y a la blague, c'est marrant, de considérer le Human Legacy comme le Code Legacy. En même temps, on n'est pas non plus là pour... On en a parlé un petit peu, pour montrer du doigt, dire que le Dev Legacy, c'est mal, c'est vous, c'est de votre faute, personnellement, etc. Donc il faut quand même arriver à trouver des parallèles qui... qui à la fois sont pertinents et ne sont pas des parallèles de dictateurs. Donc on y travaille, on aimerait bien que ça fonctionne, mais faudrait voir ce que ça donne quand même.
Et l'idée c'est de l'introduire aussi dans la forme, sur un truc un peu plus type discussion entre Léa et moi, comme on pourrait avoir en buvant une bière, où on pourrait discuter de ces parallèles-là sans vraiment que ça ait un impact dans ce qu'on fait au quotidien. C'est aussi le fait de... Quand on parle de refonte ou de Strangler Fig pour appliquer à des humains, tu peux très bien imaginer ton étranglé des développeurs, mais c'est pas... C'est parce qu'on veut que les gens retenaient de la con. C'est juste pour faire des blagues aussi.
Tu peux redéfinir le Strangler Fig ? Je pense pas que tout le monde qui écoutera ça connaît le pattern.
Le Strangler Fig, c'est un pattern de gestion du legacy sur lequel tu vas... Pour des nouvelles features, mettre... t'isoler complètement de tes interactions avec ton... Oh, isoler, non. Mettre une couche de... d'ACL. Ah, j'ai perdu le... Anticorruption. Anticorruption, je ne sais pas pourquoi je ne l'avais plus. Une couche d'anticorruption à chacune de tes interactions avec le Legacy, pour être complètement isolé de son comportement et avoir aucun effet de bord dû à son fonctionnement. Et au fur et à mesure... tu vas pouvoir faire comme le palmiétrangleur, le figuierétrangleur, grappiller un peu ton legacy, le sortir, ses responsabilités, les mettre dans ton application qui finalement est développée avec des meilleures pratiques et mieux faites, et l'étouffer au fur et à mesure ton legacy pour que jamais il déborde sur ta refonte.
Mais tu vois, c'est... Comme on en a parlé là, je pense que c'est un peu ce qui se passait dans la startup dont je parlais. C'est-à-dire que les fondateurs et les gens qui avaient tout un tas d'idées, ils étaient entourés de, pas de gens qui les étranglent, mais de PO ou de devs qui comprenaient le besoin et agissaient un peu comme une couche anti-corruption, c'est-à-dire... décider, enfin DPO, DPM aussi d'ailleurs, adapter les idées pour en faire quelque chose qui servirait le produit tel qu'il est maintenant. Ce qui permettait à la fois de profiter de toutes ces idées et ne pas complètement refaire un Big Bang à chaque fois qu'il y avait une nouvelle idée géniale. Après, ce n'est pas extrêmement novateur. Il y a plein de gens qui font ça. Il paraît que c'est comme ça que Tesla gère Elon Musk.
Je ne sais pas comment il... Je ne veux pas... Je ne sais pas si j'ai envie de parler de ce mec-là.
On peut le.
Tu pourrais le couter. Mais force est de constater, oui, que je pense qu'il y a plein de choses qui, dans les boîtes d'Elon Musk et d'autres, il y a des équipes qui réussissent malgré leur hiérarchie. Et il y aurait peut-être beaucoup à prendre de ces équipes-là, très premier degré. Donc, il y a peut-être quelque chose à voir là-dedans. Ça fait un moment qu'on cause, du coup. Donc, sur le... Je sais pas par quel bout le prendre. Sur l'avancée de votre sujet, aujourd'hui, alors on a... En fait, on a... J'étais censé vous aider, tout ça, à avancer. En fait, on a juste brainstormé sur tout ce qui peut arriver. On a parlé du sujet, parce que moi, je dérive. Le sujet m'intéresse aussi éminemment, parce que c'est un des... Je pense que c'est un des... des plus gros points qu'on a dans notre métier, c'est de gérer l'existant. Vous, vous vous sentez comment pour, j'allais dire, pour continuer à avancer, à travailler sur ce sujet et pour revenir dans un mois ou deux pour le présenter tout fini, tout beau, tout prêt ?
Moi, je ne suis pas déçue parce que c'est toujours comme ça. J'ai une idée. Ensuite, il y a une phase d'expansion où déjà, il existe des choses. Donc, je vois... Je consomme du savoir. Je vois des vidéos, je lis des trucs. Et il y a un moment où je me dis Oh là là, mais il va me falloir 10 heures pour présenter tout ça parce que, bien sûr que c'est le nouveau framework de lecture du monde entier qui va révolutionner la tech. Après, on arrive à trouver la niche, le point particulier dont on a envie de parler, qu'on trouve intéressant, plus intéressant que le reste. plus facile ou qui va correspondre au format. Et du coup, je pense que de tout ce dont on a parlé, quand on aura fini de voir toutes nos sources et de re-brainstormer encore... Il y aura peut-être, si ça se trouve, rien dans le talk final. J'espère pas, mais...
Je ne pense pas.
Mais du coup, oui, là, on est en phase d'expansion de... Ah, ce sujet, il est lié à ça, qui est lié à ça, qui est lié à ça. Et après, il y aura une phase de concentration.
Oui, clairement.
Moi, j'aimerais beaucoup, pour l'auditoire qui est toujours là, essayer des... des remarques, des souhaits d'activer plus là-dessus. Je trouverais ça intéressant au moment où je vais le publier sur les réseaux, qu'il puisse y avoir des discussions en dessous, je trouverais ça très très cool. Parce que le sujet est justement à hyper basse, comme tu dis. Il y a des sources qui vont de partout, il y a du vécu je pense qu'il y a à prendre en compte. J'aime bien avoir des sources un peu... scientifique, je mets des gros guillemets en visuel, mais un peu... Ouais, avec de la data sourcée. J'aime bien ce type de données qui a en général plus de poids, mais du vécu d'une personne, d'une deuxième, d'une troisième, des fois ça donne des bons axes de lecture et de recherche. Donc moi je trouverais ça intéressant.
Oui, j'allais rebondir sur ce que disait Léa, pour dire qu'on était clairement au début de notre travail et que... Pour l'instant, on a orienté notre talk tel qu'on te l'a présenté, mais on n'est pas sûr qu'il ressemblera à ça à la fin. Et pour le moment, dans le taf qu'on a fait, on essaye d'en sortir un abstract pour pouvoir soumettre, pour pouvoir bénéficier des jours de création de contenu Shodo. Et il faudra venir voir le talk, parce qu'en plus, tu pourras apprécier les illustrations de Eve.
C'est presque une private joke. Du coup, Eve a fait des illustrations pour plusieurs tools qui ont à chaque fois plutôt bien marché. Donc, ça sera avec grand plaisir. S'il y a des gens qui ont envie de discuter avec vous de ça, Léa, t'as au moins un réseau, t'es au moins sur LinkedIn, je crois. Tu es contactable ?
Je suis sur LinkedIn, je m'appelle Léa Coston et on me voit parfois dans les meet-ups lyonnais.
Ok. Yann, je sais pas si t'as... Beaucoup de réseaux, c'est visible.
Alors moi malheureusement je n'ai pas beaucoup de réseaux, donc c'est plus dur de me contacter comme ça. Après vous pouvez dénicher ma première conf et récupérer mon adresse mail perso si vous voulez vraiment me contacter absolument. Mais sinon vous pouvez passer par Léa, je pense qu'elle me fera parvenir les messages. Et sinon oui je traite dans les meetups lyonnais, particulièrement celui des crafters, le meetup Python et LyonJS de temps à autre. Au plaisir de s'y croiser.
Eh bien, merci à tous les deux d'être venus. Ça me fait un épisode qui sort un peu de l'ordinaire. Ça faisait une discussion autant sur le fond que sur la forme, j'aime bien. J'ai vraiment bien envie que vous repassiez quand le sujet sera plus sec. Quitte à vous donner des idées dans la discussion pour faire des suites. parce que je pense que ça peut appeler des suites donc encore une fois merci d'être venu et puis quant à vous, quant à toi cher auditoire, auditeur, auditrice qui nous a écouté jusqu'ici il me reste à te souhaiter une excellente fin de semaine à la prochaine pour un nouvel épisode et d'ici là, geekez bien et codez bien
Share
Embed
You may also like
Description
Léa et Yann ont envie de parler du concept de développeur legacy et on va brainstormer autour de ce concept pour les aider à travailler sur leur talk!
Entre recherche d'informations, recherche d'axes de lecture, venez découvrir le processus d'idéation inhérent à la création d'un talk!
Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.
Transcription
Bonjour à toutes et à tous, et bienvenue dans ce nouvel épisode du podcast Punkin'Dev. Aujourd'hui, je reçois, j'ai l'impression de dire souvent pareil, non pas une, mais deux personnes dans le podcast. Des personnes qui ne sont jamais venues, et rien que ça c'est un grand plaisir. Je vais vous laisser vous présenter, on commence par toi Léa. Bonjour Léa, ça va ?
Bonjour, ça va super, et toi ?
Ça va très bien, est-ce que tu te présenterais pas en deux secondes, rapidement ?
Bien sûr, donc je suis Léa, je suis dev back depuis 4 ou 5 ans. Je travaille pour Shodo Lyon en ce moment et je fais aussi quelques confs, surtout sur des sujets autour des équipes et de comment constituer une bonne équipe change la manière dont on va faire le développement et produit du meilleur dev.
Dac, merci. Donc tu travailles chez Shodo, et chez Shodo tu as un collègue que voilà. Bonjour Yann. Salut. Ça va ?
Ça va et toi ?
Ça va bien. Et bah à ton tour, te présenter. T'as plus le droit de dire que t'es chez Shodo, on l'a déjà dit.
Ah ouais, je suis récemment chez Shodo. Moi ça fait plus de 8 ans que je suis dans le dev, particulièrement en full stack. J'ai rencontré le craft il y a quelques années, et l'année dernière je me suis lancé un peu dans ma première conf, et j'ai bien aimé l'exercice, et c'est pour ça que là, avec Léa, qui est une grande conférencière internationale, je me suis dit qu'on pouvait élaborer un sujet intéressant. Parce qu'on a des expériences qu'on a pu recouper sur des sujets plutôt cools.
Ça, c'est une très bonne nouvelle. Donc du coup, vous allez faire un sujet tous les deux. Qui c'est qui veut me résumer un petit peu le sujet ? Je ne sais pas si vous avez un titre ou un concept là-dedans. Ça ressemble à quoi pour l'instant ?
Pour l'instant, on n'a pas encore de titre. On s'est rendu compte en discutant tous les deux. Je pense qu'on peut dire que Yann et moi, on a travaillé ensemble dans plusieurs... Ce n'est pas la première fois qu'on travaille dans la même entreprise. Et on discute beaucoup de nos pratiques, comment on voit notre métier, etc. Et dans des équipes précédentes, on s'est retrouvés tous les deux à râler sur nos collègues, la manière dont ils font certaines choses. Et c'est Yann qui va raconter son anecdote sur comment on est arrivé sur le... concept qui nous parle à tous les deux de développeur legacy.
Oui, c'est un concept qui a émergé lors d'une discussion de bar évidemment. Après une journée un peu frustrante pour moi. Tout simplement dans une équipe qui avait grandi récemment et dans laquelle on avait des gens qui étaient là depuis assez longtemps, depuis le début du projet et d'autres gens qui arrivaient avec des nouvelles pratiques. on s'est retrouvé en rétro à rediscuter de est-ce que ça vaut vraiment le coup de faire des MR review ? Est-ce que ça vaut vraiment le coup de faire des tests ? Alors que c'était des concepts de qualité qu'on pensait acquis pour une grosse partie de l'équipe. Et le problème c'est que les personnes qui remettaient en question ça c'était les développeurs qui étaient là depuis toujours, qui avaient connu le projet à ses débuts et qui l'avaient transformé en gros plat de spaghettis et c'est pour ça qu'on devait le refactorer pour pour arriver à le maintenir. Suite à cette rétro, on s'était quitté en n'étant pas d'accord, et dans la même journée, on avait un développeur qui avait mergé sur main, forcément déployé en prod, et on s'en était tiré avec 5-6 tickets de bug, parce que le code n'était pas testé, donc le plaisir. Et c'était un des développeurs qui était là depuis le début. Et donc c'est comme ça que j'ai commencé à parler de... de ce concept de développeur legacy, sans trop... Juste pour la blague, parce qu'on parle souvent de code legacy. Et Léa m'en a reparlé à un autre moment, parce qu'elle avait l'expérience de... Une expérience pas tout à fait similaire, mais qu'on pouvait aussi qualifier d'expérience avec des développeurs legacy.
En fait, on a commencé à discuter... En ESN, on... passent beaucoup d'entretiens chez les clients. Et il y a certaines entreprises qui mettent en avant le fait que leurs devs sont là depuis qu'ils n'ont pas beaucoup de turnover, ce qui en soi est une bonne chose pour une culture d'entreprise. Mais en même temps, dans le code, quand on arrive dans une équipe où il n'y a que des devs qui sont là depuis plus de dix ans et qu'il n'y a pas de 109 non plus, on a commencé à dire, ah, mais c'est une bonne chose pour la culture d'entreprise, les gens restent. Mais en même temps, d'un point de vue des pratiques, des fois, c'est un peu un beige flag, on va dire, entre pas vraiment un red flag, mais en même temps, est-ce que c'est une si bonne chose que ça ? Est-ce que vraiment on a envie de rentrer dans cette équipe qui a les mêmes pratiques et les mêmes personnes qui la composent depuis plusieurs années ? Moi, ça m'est arrivé d'être dans des équipes où les devs historiques font beaucoup de choses sur des canaux implicites. Et quand on arrive, c'est dur de comprendre. Il y a des process officiels, mais qui sont... pas vraiment respectées et qui permettent pas de faire ce qu'on veut. Et donc en tant que nouveau dev, pas junior, juste nouveau qui arrive dans cette équipe, on n'a pas forcément la main sur la vraie manière dont les choses se passent. Et donc on s'est dit en discutant que ça se rapprochait un peu de cette idée de dev legacy, c'est-à-dire comme le code, des choses qui sont là depuis longtemps et qui ont un peu leur propre vie en dehors des process officiels.
Alors si j'essaie de recentrer sur la notion de dev legacy, alors je remets la définition, le legacy ça veut dire juste héritage, un code legacy c'est un code dont on hérite. J'ai l'impression que le dev legacy c'est un peu le truc qu'on subit, qui est là, il faut faire avec, comme le code, on peut pas passer outre, ça fait le taf sur certains trucs, mais... Mais ça pose plein d'autres problèmes. Je suis dedans ou vous avez peut-être plus de nuances ?
T'es un peu dedans, mais à la fois, il y a aussi de la nuance. Code Legacy, c'est pas toujours quelque chose de... Comme tu l'as dit, ça veut simplement dire héritage et ça veut pas forcément dire qu'on le subit ou que c'est un problème. C'est juste quelque chose qu'il faut gérer. Il y a des méthodes, il n'y a pas de refacto ou pas. Parfois, il n'y a pas besoin de le résorber, mais ça veut dire que c'est quelque chose qui a une manière de le gérer qui est différente du code moins legacy. Et du coup, les devs legacy, ils ne sont pas forcément... Ce n'est pas forcément une mauvaise chose.
Oui, c'est ce que je disais quelque part. Ils font du taf, le code legacy, même si des fois, il nous fait souffrir. C'est lui qui emprunte, c'est lui qui... permet de gêner souvent du cash ou qui permet de rendre service à des utilisateurs, des utilisatrices. Du coup, effectivement, ce que tu disais, le code legacy, on a a priori des méthodes. pour le gérer. On a des méthodes, des pratiques qui ne marchent pas toutes, mais ce n'est pas une science exacte. Donc vous, votre point, c'est que, si vous parlez de ça, j'imagine que vous avez peut-être commencé à réfléchir sur comment on gère des devs legacy.
Eh bien, c'est l'angle qu'on aimerait prendre avec notre talk, où on aimerait parler de notre expertise en tant que dev, donc plutôt partir de la définition et des techniques. qu'on a l'habitude d'utiliser nous en tant que dev pour gérer du code legacy et voir si on peut l'appliquer à des structures organisationnelles où il y a des dev legacies pour pouvoir un peu résorber ce problème, ces frustrations au quotidien. Donc c'est un peu le point un peu original qu'on voudrait introduire dans ce talk. Mais là c'est le sujet sur lequel on est pas mal en recherche. où on regarde un peu les méthodes de gestion de Legacy Remediation, et on essaye de faire des parallèles, ce qui peut être un peu hasardeux, mais d'un autre côté, ça se recoupe quand même pas mal avec des méthodes de conduite du changement, ce genre de choses, où tu vas faire changer les pratiques des gens au sein des équipes.
En même temps...
Alors, allons-y.
Non, mais en même temps, en regardant des confs d'autres personnes, en lisant des choses, je trouve qu'il y a aussi beaucoup à dire sur qu'est-ce que c'est le code Legacy et à quoi on veut remédier quand on parle de Legacy Remédiation, etc. Parce que c'est ce qu'on disait, c'est à la fois quelque chose qu'on subit, mais à la fois quelque chose qui fait le taf. c'est vrai pour les devs aussi donc il ya aussi une réflexion qu'on aimerait avoir sur Comment avoir du bon legacy, en fait ? Que ce soit humain et technique. C'est-à-dire du legacy qui te sert et qui est, du coup, des équipes qui fonctionnent bien dans la durée.
Dans la définition d'Adrien Joly, le code legacy, c'est un code qui a... La première partie de la définition, c'est un code qui a de la valeur pour l'entreprise. De facto, le développeur legacy, c'est quelqu'un qui a une valeur essentielle à l'entreprise parce qu'il connaît tout l'historique du projet. Il sait des choses que... Pas tout le monde sait. Il sait comment on est arrivé là. Il sait où trouver des bugs, quels bugs sont normaux, dirons-nous. Ce genre de choses, tout l'historique de projet qui peut être un peu touffu, dirons-nous, pour quelqu'un qui arrive dessus de nouveau.
Du coup, là, dans votre réflexion, vous parliez un peu de... chercher des infos, chercher des sources, dans quelle mesure vous appuyez, vous allez essayer de vous appuyer sur de la source académique, entre guillemets, que ce soit des talks, des bouquins, des articles, et dans quelle mesure vous avez aussi peut-être vous des morceaux de retour d'expérience, peut-être de choses que vous avez vues, essayées, je ne sais pas comment vous sourcez votre taf là-dessus.
Ce que j'aime faire habituellement, c'est résoudre les problèmes que j'ai eus moi, donc retour d'expérience sur les problèmes que j'expose. Mais en même temps, il y a beaucoup de sujets qui sont recherchés par des gens dont c'est le métier, et des gens qui ont expérimenté des choses. Et j'aime bien faire un peu un état des lieux de ce qui existe. Et parfois, c'est comme ça que je trouve, je tombe sur des concepts dont je ne savais pas qu'ils existaient, mais qui me permettent de vraiment faire évoluer la manière dont je vois les choses et qui amènent une nouvelle grille de lecture aux choses que je vois dans mon quotidien.
Tu as des exemples un peu concrets de trucs que tu as vus récemment ?
Eh bien, le dernier talk que j'ai fait, c'était sur... qui était sur la sécurité psychologique. Je ne connaissais pas le concept avant. Moi, ce que je voyais, c'est que certaines choses marchaient mieux dans certaines équipes que dans d'autres. Dans certaines équipes, il y avait vraiment beaucoup d'apprentissage global. L'onboarding était facile, ce genre de choses. J'ai commencé par raconter ce qui m'arrivait. Et les gens ont beaucoup relate en se disant Ah oui, moi aussi, c'est comme ça etc. Et en faisant des recherches. Jusqu'à ce que quelqu'un me dise Ah, ce dont tu parles, C'est de la sécurité psychologique. Et du coup, je suis allée lire, j'ai lu des bouquins, j'ai cherché les articles sur Internet. Et effectivement, c'est théorisé, beaucoup recherché depuis 50 ans. Et du coup, ce que j'ai fait et ce que j'aime bien faire, c'est ce concept-là qui est un peu méconnu dans la tech. Peut-être qu'on peut en parler, peut-être qu'on peut l'appliquer à plus d'équipes. Et personnellement, moi, c'est... en faisant Herméneutique, comme je l'ai appris dans le talk de Sarah Dufour, sur le concept de sécurité psychologique, ça m'a aussi donné une grille de lecture de mon quotidien et des leviers pour le changer. Et donc, appliquer à ce qu'on voudrait faire là, c'est un peu similaire, c'est-à-dire que nous, on voit des devs qui se comportent comme du Code Legacy, mais en faisant des recherches sur le Code Legacy, comment on le définit, comment on le traite. Et aussi des recherches, on espère, sur la conduite du changement, comment on fait évoluer les équipes, les frameworks qui existent pour gérer des équipes. Peut-être que ça va nous amener des nouvelles grilles de lecture qui nous permettront de formaliser un peu et de changer notre quotidien sur les dev legacies avec lesquelles on bosse. Ou nous-mêmes quand on est des dev legacies.
Ok, du coup là en fait vous êtes encore en phase d'accumulation de sources, de vous consommer un peu pour créer du... On va créer de la connaissance là-dessus.
D'ailleurs, si tu as des recommandations, on est preneur.
J'en ai assez peu. J'espérais que vous m'en donniez un peu plus sur déjà ce que vous avez eu jusqu'ici. Il y a une partie, je ne sais pas, j'essaie de synthétiser dans ma tête en même temps que ça vient. Il y a une partie un peu conduite du changement qui m'a interpellé. Il y a une partie aussi... Je synthétise, désolé. Je ne sais plus comment vous avez évoqué ça. Quand il y a des process qui sont décrits dans la boîte et qu'en fait, ils ne sont pas respectés et que c'est les devs legacy qui connaissent comment on fait vraiment, plus que l'éventuel doc qui peut traîner à droite à gauche. Ça, c'est des trucs que je trouve intéressants dans le sens où... La première fois où vous m'avez parlé de ce sujet, je me suis dit Ah cool, on va pouvoir tacler les vieux mecs chiants des projets. Et en fait, non seulement c'est d'une moralité douteuse, ma pensée que j'ai eue à ce moment-là, on ne tacle pas des gens comme on tacle du code, le code lui il s'en fout qu'on l'efface, on ne va pas traiter les gens pareil. Mais je trouve ça aussi intéressant de se dire Le code Legacy, c'est lui qui a de la valeur. Donc il y a cet axe un peu de valorisation du legacy, mais en même temps on ne peut pas oublier une partie de remédiation quand il y a un espèce d'immobilisme et de refus d'évoluer vers d'autres choses, que ce soit un refus de personnes qui ne veulent pas ou que ce soit un refus du code parce que le code est ancré depuis tellement longtemps que c'est compliqué de le faire bouger. Est-ce que c'est des axes que vous pensez, que vous envisagez d'exprimer ? dans votre sujet ?
Dans un premier temps, l'idée, c'est de faire des parallèles entre la gestion du code legacy, les techniques et les structures d'équipes de développeurs. Donc forcément, tu as des techniques qui vont être un peu violentes. On ne va pas se le cacher. Mais ça fait partie de l'humour un peu acerbe du talk, je pense. En fait, l'idée, c'est de conclure en donnant des pistes sur comment prévenir ce genre de problème. Parce que tes DevLegacies, c'est ce qu'on dit, ils ont une valeur en tant que connaissance de process, connaissance de métier, etc. Et ça, tu ne veux pas le perdre, tu ne veux pas les faire fuir, parce que c'est valorisable en temps monétairement. Et donc, ton but, c'est aussi de les garder, mais de les faire changer pour pas que ça fruste tes nouveaux devs non plus. Donc, les pistes d'amélioration sont là-dedans.
Après, du coup, comme on a commencé à faire de la biblio, j'ai revu hier le talk de Kavlin Henley que j'avais vu à Newcraft cette année. où il parlait de de dette technique et en fait ça a aussi changé un peu ma perspective là-dessus parce que son take-away c'est un peu que la dette technique c'est pas un problème c'est une conséquence de négligence technique donc on laisse les choses se faire d'elles-mêmes et on n'y revient pas et je trouve que ça s'applique bien à ce qu'on veut faire c'est-à-dire que c'est pas en restant longtemps qu'on devient un dev legacy c'est en remettant pas en cause ses pratiques régulièrement en négligeant son équipe alors elle devient legacy au bout d'un moment alors qu'on peut mais bon après ça c'est normal c'est mutant au début quand on commence un sujet il y a toujours beaucoup de choses qui rentrent d'abord mais moi j'aime bien cette idée que c'est pas une fatalité c'est à dire que si on si on laisse les l'équipe, si on ne prête pas attention à sa propre équipe, alors elle va tourner vers un fonctionnement legacy, c'est-à-dire un truc plus implicite, plus spaghetti, comme si c'était du code. Ce que je disais sur le fait que toutes les communications soient implicites et qu'elles ne suivent pas les process officiels, c'est assez similaire à ça. On passe trop de temps à prendre des raccourcis, à le fameux chemin de... Donc ça me fait penser à quand on marche dans la pelouse et que tout le monde traverse et que ça crée un chemin. Je ne me souviens plus du nom de ce...
Non mais je vois bien l'usage. On a beau faire un joli chemin sinueux qui fait très joli depuis les vues d'en haut, les gens tracent tout droit et du coup ça bouffe la pelouse là où ce n'était pas prévu. Mais les gens prennent le chemin qui est le plus simple a priori, le plus direct.
Donc pour moi, il y a quand même un aspect de si on y prête attention, qu'on remet en cause et qu'on entretient sa dette humaine, en fait, alors on nous dira du legacy qui nous sert au lieu de qu'on subit.
Et surtout que de notre expérience, c'est du legacy que tu subis doublement, parce que grâce à cette magnifique loi de Conway, finalement, quand t'as beaucoup de dev legacy, tu te retrouves facilement avec une big ball of mud de... avec des problèmes pour la maintenir.
Oui, c'est l'aspect technique dont tu parlais. Quand quelqu'un décide de faire tout seul dans son coin et de pousser, c'est des bugs parce que ce n'est pas testé et ce n'est pas dans les pratiques de l'éve. J'aimerais bien arriver à placer le fait que, comme les gens ressemblent à leur chien, le code ressemble à son équipe.
Ah puis là, tu fais ça, tu sors cette phrase, et là j'ai les vieux mèmes qui me passent sur Internet où les gens et leurs chiens se ressemblent souvent, et il y avait des trucs très drôles. Mais quelque part, c'est un des corollaires de la loi de Conway. Ton code finit par ressembler à ton modèle d'organisation et à ton modèle de communication. Si tu as une équipe qui ne communique pas, tu vas avoir des choses qui vont être hyper... hyper hétérogène d'un bout de code à l'autre. Et j'allais dire que c'est globalement inévitable. Effectivement, il faut pouvoir adresser une partie de ta structure de communication pour gérer ta conduite du changement et espérer faire en sorte de modifier un peu la culture qui a fait émerger ce Ausha. Mais en même temps, tu peux la faire par, je ne suis pas expert là-dessus, sur la loi de Conway, mais tu peux la faire par la loi de Conway inversée en agissant sur ton code pour essayer de faire évoluer la culture qui va derrière. Donc ça, c'est deux approches, parce que des fois, faire changer ton organisation quand tu es chez des... Dans des contextes de start-up, c'est facile, ça change tout le temps. De toute façon, il y a une chance sur deux que sous neuf mois, il n'y ait plus personne, que tout soit effondré. Donc ça change plus facilement dans des grosses administrations qui existent depuis 5, 10, 20, 30, 40 ans. Faire bouger des fois vaut mieux repartir par le code, par la technique parfois. À un moment, ce que tu disais Léa, ça m'a rappelé, puisque tu parles de conf que tu as vu récemment. Moi, je suis en train de relire un bouquin. En ce moment, je suis en train de lire la nouvelle édition de Your Code as a Crime Scene de Adam Tornil. J'avais lu la première édition il y a 2-3 ans. Et là, sur la nouvelle, et ça me rappelle des trucs, quand tu parles de dette technique, il a tout un chapitre qui est un peu un plaidoyer sur c'est bien de vouloir s'attaquer à la dette technique et au Legacy. Par contre, il faut s'y attaquer là où c'est pertinent de s'y attaquer. S'il y a un énorme bout de code qui est tout pourri, mais qui marche, et qu'on ne touche pas, eh ben on ne le touche pas. Je ne sais plus où je l'ai entendue celle-ci, c'est qu'on ne nous paye pas pour réparer des trucs qui marchent. Concrètement, je pense qu'il faut centrer toutes les remédiations, tous les outils, toutes les pratiques de gestion du legacy qu'on peut avoir, il faut les mettre là où ça va avoir de la valeur. Et où ça a de la valeur, eh ben ça va avoir de la valeur là où ça nous fait mal en temps normal. Si un fichier qui n'est pas le pire du monde, mais qu'on y retouche toutes les semaines, et qu'à chaque semaine il va de pire en pire, on sait qu'on va avoir un axe de travail là-dessus, qu'on va avoir un réel gain à travailler sur ça. Par contre, là je serais preneur de vos idées sur est-ce que ça c'est applicable en termes d'analyse de comportement humain ? Est-ce qu'on peut voir... Je ne sais pas. Est-ce que c'est transposable sur l'humain ? Est-ce que ça rentre dans votre scope ?
Sur le premier concept, à savoir si tu dois toucher des équipes legacy qui vont finalement fonctionner très bien et te créer de la valeur, je pense qu'il n'y a pas besoin. Si elles arrivent à fonctionner en vase clos et ne pas créer de frustration en dehors. et du coup tu n'as pas besoin de penser à refactorer ce goût d'équipe. Mais c'est sûr que c'est sur les sujets là où il y a de la valeur pour ton business, il faut être le plus attentif et écouter tes devs pour détecter s'il y a des problèmes de développeurs legacy, de gens qui ne font pas circuler les infos, de gens qui ne s'incluent pas dans les pratiques de l'équipe. Parce que tu vas générer de la frustration, du turnover, et la qualité de ton code va le subir aussi.
Après, moi je suis moyen d'accord. Je trouve que ça rentre dans notre scope, mais je ne suis pas d'accord non plus avec le truc on n'est pas payé pour réparer des choses qui marchent c'est vrai mais on n'est pas très bon dans je trouve qu'on n'est pas très bon dans le dev pour mesurer est ce qu'elle marche ou pas les choses et notamment que ce soit dans le code ou dans les équipes si on a un bout dont personne sait comment ça marche ou dans une équipe ce serait l'équivalent ce serait vraiment les faits un peu tour d'ivoire une équipe dont personne sait ce qu'elle fait et comment elle marche mais on sait que ça marche Le problème de ça, c'est que dans l'évaluation du risque, les chances que ça tombe en panne sont faibles, et donc on a tendance à ne pas vouloir y aller, mais les conséquences si ça tombe en panne sont élevées, parce qu'on ne sait pas le réparer. Et c'est quelque chose qu'on prend assez peu en compte dans le dev, les conséquences. Et donc, même si ce n'est pas forcément prioritaire, je trouve que ça vaut le coup des fois de réfectorer quelque chose qui marche, juste parce que... Si ça tombe en panne, on ne saurait pas le faire sinon.
Je vais juste mettre en perspective. Dans le fond, on est d'accord. Mais il y a différentes choses. Ce que tu dis, la partie risque, je peux vous inviter à aller checker un talk récent de Cyril Martraire qui parle de théorie de la résidualité. Alors, je l'ai vu une fois. La première fois, c'est... un peu abrupt comme concept, en même temps c'est un concept sur lequel il y a une thèse qui est en cours, donc c'est pas sec, mais ça reste intéressant, et où justement il propose de soumettre, en exercice de pensée, mais de soumettre nos architectures et notre code à des risques potentiellement, tous les risques possibles et imaginables, et voir qu'est-ce qui peut arriver et qu'est-ce qu'on peut faire soit pour se prémunir de ça au cas où ça arrive, soit pour faire en sorte que ça n'arrive pas, et driver nos architectures par ça. Typiquement, qu'est-ce qui se passe si tout le réseau tombe ? Comment va supporter notre appli ? Est-ce qu'il faut réfléchir à mettre en place un mode hors connexion ou pas ? Par exemple, qu'est-ce qui se passe si j'ai une base de données qui tombe ? Est-ce qu'il y a encore des choses qui peuvent marcher avec des services externes ? Le but, ce n'est pas de dire qu'il faut faire ça ou ça. En général, c'est sur chaque appli quel point est crucial et gérer un petit peu des décisions d'architecture par la gestion du risque. Maintenant, ce que je voulais... Ce que je voulais dire quand je disais qu'on n'est pas payé à réparer des trucs qui marchent, c'est là que le parallèle humain a peut-être sa limite. Concrètement, si un bout de code fonctionne, même si c'est le code le plus dégueulasse du monde, tant qu'on n'a pas à le toucher, il n'y a pas d'intérêt. Il n'y a pas de ROI à venir faire du refacto là-dessus. Là, je me place en tant que manager qui tient le portefeuille. S'il y a mes devs qui disent, on va réparer un bout de code ici, pourquoi ça ne marche pas ? Non, ça marche, laissez-le tranquille. Par contre, c'est bien d'avoir la connaissance de, il y a une grosse big ball of mud là-bas, et le jour où, attention, on va toucher quelque chose là-dessus, stop. Là, on a un gros facteur de risque. Il vaut certainement mieux faire du refacto avant de commencer quoi que ce soit. Ou alors il faut prendre en compte le fait qu'on ne maîtrise pas du tout notre deadline. Et c'est encore un point que défend Adam Tornil dans Your Code as a Crime Scene, puisque lui il propose des pratiques et tout un outillage pour le détecter ça, en amont, et avoir conscience de tes points potentiellement problématiques avant de faire quoi que ce soit. Ce qui permet de driver un petit peu, j'allais dire... certains choix, certains choix de gestion technique et certains choix de communication. Dans le sens où on a plein de points, plein de zones du code qui sont problématiques, on y revient souvent, il faut investir du temps pour faire de l'amélioration continue, pour faire en sorte que ces zones arrêtent de nous coûter autant de pognon. Et aussi identifier, genre ce coin-là, là-bas, on a deux, trois fichiers, 12 000 lignes chacun, qui fonctionnent ensemble, qui sont ultra couplés. Il y a trois ans, on a eu plein de bugs dessus. Maintenant, ça marche. On n'a pas besoin d'y toucher. On n'a pas d'évol qui concerne ça. C'est cool. Par contre, il faut être capable de savoir que ce truc-là existe et de lever une alerte. Bon, on a un truc en lien avec ça. attention, il va falloir faire du refacto ou prévenir toute l'équipe. On se met en best effort sur refactorer ce truc-là et on va prévenir la hiérarchie que non, ce truc-là est hyper risqué. Et peut-être qu'en termes de gestion du risque, le management va dire ça peut-être du coup on ne le fait pas. Si c'est risqué à ce point, si ça nous casse une feature qui est ultra importante, il y a une vraie réflexion à avoir là-dessus. Mais du coup, sans piètre, j'étais en train de me dire que je voulais faire un épisode sur Your Code as a Crime Scene. J'y reviendrai probablement. Mais je vous reparlerai si vous voulez des sources là-dessus. Quand je l'aurai fini, je pourrai vous le prêter le bouquin. Il y a des trucs super intéressants à cet égard-là.
C'est intéressant parce que je sais que c'est un des trucs qui tiennent à cœur à Ian. C'est de proposer un framework ou une méthode pour détecter justement les... les big ball of mud humaines c'est à dire on aimerait bien si on y arrive trouver une forme de questionnaire ou checklist qui vous dit ah attention vous avez une big ball of mud d'humain parce que à l'heure actuelle c'est assez dur à détecter parce que c'est comme du code legacy c'est que ça a des effets pervers de
de des engagements des des personnes Parce que sur ton code Legacy, si c'est dur de l'entretenir, c'est dur de faire des tests dessus, de toute façon il n'y a pas d'autres tests dessus, donc tu ne vas pas commencer à en faire, parce que c'est trop compliqué quand tu vas créer de nouvelles features. Mais de la même façon, si ton organisation fonctionne en mettant en avant tes développeurs Legacy, ou juste ton Legacy humain en général, tu vas adresser le problème une fois ou deux fois, par exemple au moment de la rétro, et s'il n'y a rien qui se passe, tu vas laisser tomber. Et ce sera juste un problème que tu gèreras un peu comme tu peux.
Pour la détection, je te dirais, il y a une troisième partie dans le bouquin que je n'ai pas encore relue, je n'en suis pas encore là, sur justement un petit peu explorer la partie... humaine et sociale du projet via le code parce qu'on peut voir des choses. Je te reparlerai à ce moment-là, tu verras si vous voulez greffer ça dedans. Mais il y a de l'outillage qui existe, notamment sur la gestion du bus factor. En anglais, ils appellent ça le truck factor. Pour les personnes qui ne connaissent pas, c'est combien de personnes de ton équipe peuvent passer sous un bus et que du coup, ton projet tourne encore. Et il n'y a pas une seule réponse sur un projet en général. Il y a des zones qui ont un bus factor qui est très bas. Quant à justement, c'est le principe du dev legacy en général. Quand tu as ton dev qui est là depuis 8-9 ans, il y a des zones où c'est la seule personne qui sait comment ça marche. Et si cette personne-là se barre de manière voulue ou non. Ouais, ça va être compliqué. Il va y avoir un point de gestion à traiter dessus. Et... Et s'il y a des gens qui se disent Ouais, mais ça n'arrive pas. Alors, si ça arrive, des devs qui disparaissent du jour au lendemain pour x ou y raison, ça peut arriver. Et même des fois, alors on dit toujours oui, il y a des préavis s'ils se barrent. J'ai un collègue qui s'est arrivé, vraiment un de leurs collègues, j'ai juste jamais revenu. Il s'est pris une voiture, accident et fin de vie. Ils ont eu à gérer ce problème-là, premier degré. Genre, on a le principal sachant du projet qui est décédé. Donc du jour au lendemain, on a un énorme trou de connaissances, comment on gère, comment on aurait dû gérer en amont. Et sur la conduite du changement et le partage de connaissances, ils ont mis en place plein de trucs. Il faudrait que je retrouve cette personne-là qui nous raconte un peu comment ils ont géré et réagi derrière. Mais c'est un truc qu'on met souvent au second plan, genre non mais ça va pas arriver. Bah si, ça arrive. Et comme tu disais Léa, c'est de la gestion du risque. Qu'est-ce que tu acceptes comme niveau de risque sur certains trucs ?
Et oui, et pour revenir sur l'invisibilité de ce problème, c'est aussi parce que tes développeurs legacy, comme ils sont historiques, c'est eux qui ont la légitimité sur le projet, et c'est par eux que tu vas sonder tes équipes, en tant que manager souvent, parce que tu auras une relation privilégiée avec eux, vu que tu les auras connus depuis super longtemps. Et donc il y a des canaux comme ça, implicites, qui vont se créer, et tu ne vas jamais avoir le problème... chez les nouveaux devs. Pour pouvoir régler ce genre de choses et savoir ce qui se passe, il faut créer des canaux avec tous les membres des équipes pour sonder ce qui se passe.
Est-ce que vous avez une vision de la... justement de ce que tu dis, la posture des devs legacy qui ont des canaux de communication privilégiés de fait de leur ancienneté. Après, c'est peut-être plus lointain, c'est une question qui me venait comme ça sur la gestion de la culture. Quand tu as des nouveaux profils, tu peux avoir toute la richesse des profils humains, mais... Comment ça peut se gérer, s'intégrer à tout ça ? Le fait d'avoir soit des nouveaux profils qui vont prendre beaucoup de place. J'ai déjà eu le cas dans une équipe des jeunes devs qui sortent d'école, qui savent mieux que tout le monde. Le vieux de la vieille, il a deux, trois infos que peut-être t'as pas. Même s'il est vieux et qu'effectivement il est pénible parce qu'il reste campé sur plein de positions, des fois il a peut-être des bonnes raisons. Et à l'inverse, des profils qui vont se faire digérer beaucoup plus vite par le legacy, qui ne vont pas arriver à remettre en cause parce que des fois, c'est une question de profil très personnel. Il y a des gens qui vont chercher à surtout pas faire de vagues. Et je vais essayer de mimiquer le plus possible la culture en place pour m'intégrer, parce que je gère comme ça. Enfin voilà, tous les profils existent. Je ne sais pas si... Au-delà du dev legacy, c'est un peu plus la dette humaine. En fait, j'ai le petit problème avec le dev legacy, c'est que ça a tendance à pointer une personne. Alors que ce n'est pas forcément le cas, c'est plus le système qui est en place. Mais quant à du legacy humain, en sens général, sur l'équipe, ça va se reproduire un peu tout seul. Est-ce que vous avez vu, vous voyez, vous imaginez justement des leviers pour... Et pour limiter l'impact de tout ça ?
Déjà, je suis d'accord avec toi que c'est un système et pas des personnes. Parce que j'ai été dans des startups où il reste le fondateur qui veut faire son truc dans son coin, mais en fait, le système et l'organisation ne lui permettent pas d'avoir l'impact de... disrupter un peu le flow de tout le monde. Et en fait, ce n'est pas un problème. C'est-à-dire qu'il y a toujours cette personne qui a une connaissance extensive du projet et qui a plein d'idées, mais les idées, elles sont absorbées et utilisées d'une manière qui fait grandir tout le monde par l'organisation. Du coup, je suppose qu'on pourrait apprendre d'eux. Mais pas que. Sur les méthodes et... Déjà de manière évidente, l'agilité quand c'est arrivé, moi je n'étais pas dans l'informatique avant l'agilité, mais les frameworks, que ce soit Scrum ou autre, de l'agilité, ça a quand même amené de l'explicite dans l'organisation des équipes et dans le partage de connaissances, qui permettent de remettre en cause un peu comment on fait les choses, de manière plus ritualisée, etc. Même si ça a forcément aussi des effets pervers, etc. Je pense que ça a déjà amené des choses là-dessus. Et je voulais aussi parler dans la lignée de Extreme Programming, où on va dire cette famille de pensées, de faire le code, etc., qui permettent aussi d'expliciter le partage de connaissances, d'expliciter la manière dont les équipes fonctionnent. Et c'est des pistes pour faire rentrer des nouvelles personnes dans l'équipe, diffuser les connaissances Legacy de gens qui sont là depuis longtemps, depuis des gens qui viennent d'arriver.
J'avais une autre remarque sur le... On parle de Legacy. Je rebondis sur des trucs que vous avez dit il y a un petit moment déjà. Sur la notion de Dev Legacy. Un peu en lien avec ce que je disais juste avant. Faire en sorte que les gens ne se fassent pas digérer trop vite par le système. L'agilité adresse ces trucs. Je vais citer ma source du moment, Adam Tornil, il en parle, il justifie ça justement avec l'arrivée des pratiques agiles et des formats d'itération qui sont plus courts qu'avant. Il y a des études assez sérieuses, il faut que je note dans un coin de tête, enfin en vrai sur un bout de papier, que je puisse les ressortir. Il y a des sources sérieuses là-dessus. Il y a une vraie étude qui a été menée sur cette notion de legacy qui est souvent liée avec la dimension, j'allais dire, plutôt maintenance évolutive des applis. À une époque où on n'avait que Waterfall, c'était normal d'avoir des projets qui vivaient 6 mois, 1 an, 1 an et demi avant de partir en prod. Et de fait, on itérait peu ou pas sur de l'existant, on rajoutait de la feature, on rajoutait de la feature, et on commençait à réouvrir l'existant que quand on partait en maintenance et qu'il y avait des évoles à faire. Avec les process agiles, en gros, passer la première itération... Pour ces gens-là et pour Adam Tornil, passer la première itération, qui dure une semaine, deux semaines, trois semaines ou même deux mois, passer ça, on est dans du legacy, parce qu'on va itérer sur du plus court, parce qu'on va relire plus de codes que ce qu'on va en produire. Là où avec Waterfall, on faisait des specs fonctionnels, des specs techniques détaillés, on implémentait, on ajoutait le package, ça partait en recettes, et on passait au sujet suivant, et il y avait généralement très peu de collisions. d'une feature à l'autre puisqu'on a ajouté des trucs. Aujourd'hui, en fait, le legacy, il naît dès l'itération 2, même souvent l'itération 1 puisque tu vas souvent avoir un sprint 0 pour bootstrapper l'archi, les machins. Donc, en gros, dès l'itération 1, quelque part, t'es en legacy, t'es en maintenance et j'ai presque envie de dire n'importe quel dev devient dev legacy quasiment tout de suite, tu deviens ton propre legacy. Ça devient un peu méta, un peu déprimant. J'arrive sur un projet, au bout de 15 jours, ça y est, je suis mon propre legacy, il faut que je gère ma propre résistance au changement, alors que je suis là potentiellement pour amener du changement. Je ne sais pas si c'est des axes, des trucs que vous avez observés, des axes que vous voulez aborder sur le sujet.
Clairement... on n'est pas allé aussi loin sur les concepts de développeurs legacy et même de code legacy comme par itération agile comme tu en parles c'est un axe super intéressant et de la même façon en fait pour pouvoir gérer tes problèmes de legacy humain il faut faire des petites itérations aussi et tester des trucs sur la structure de ton équipe sur quel rôle à quelle personne etc et Comment définir les rôles ? Est-ce que tu mets en place des pratiques de mentoring ? Comment tu fais ce genre de choses ? Pour essayer des choses et trouver ce qui fonctionne avec ton équipe pour résorber aussi ce problème de DevLegacy tout en ayant conscience, comme tu viens de le définir, que dès ta première itération, finalement, tu deviens un DevLegacy parce que tu as un savoir qui est inhérent à ce que tu as fait sur la code base. et qui n'est pas forcément diffusée dans le reste de l'équipe.
Oui, moi, c'est souvent ma conclusion. C'est vraiment un truc que je trouve important, c'est souvent on essaye de résoudre des problèmes, et le problème, c'est nous. C'est souvent la conclusion de la plupart des sujets que j'aborde, qui est qu'on peut toujours commencer par soi-même pour s'améliorer, et ce qui est important, c'est de douter. Je ne sais plus qui a dit ça, mais si tu doutes et que tu remets en cause ta pratique tout le temps, pas la changer, mais juste remettre en cause, challenger les décisions que tu as prises, vérifier, parce qu'une décision, quand tu la prends, des fois, elle est bonne, mais une semaine après, elle n'est plus valable. Et donc, il y a forcément un... À la fois, il faut toujours remettre en cause, à la fois, il faut trouver un équilibre, parce qu'on ne peut pas repartir de zéro à chaque... à chaque itération. Et moi, c'est les sujets qui m'intéressent en général. C'est-à-dire trouver cet équilibre entre ce qu'on acquiert et ce qu'on remet en cause et continuer à évoluer tout le temps. Oui, toujours grandir, toujours apprendre en tant qu'individu et en tant que groupe.
Quelque part, c'est un des principes de l'agilité. À intervalles réguliers, prendre le temps de sortir la tête. J'ai plus le... libelles exactes, mais prendre le temps de sortir la tête du guidon et de remettre en question, de remettre en cause, de se poser, plutôt que d'être dans un rush perpétuel où tu ne remets plus en cause ce que tu fais et comment tu le fais. En sachant que le comment, oui. Et il y a plus en plus de devs qui soutiennent ce que tu disais, c'est que lire du code, écrire du code, c'est la partie facile de notre métier. Gérer des interactions humaines, c'est la partie difficile. Donc oui, on est en plein de... on est en plein dedans.
Et ce que tu disais sur les gens qui seront absorbés par le legacy humain, j'aimerais bien, on verra s'il y a une place dans tout ça parce qu'on est un peu partis dans toutes les directions, mais j'aimerais bien qu'on arrive à placer des choses sur ce qui se fait en mentoring tournant ou en mentoring inversé. C'est un autre de mes dada. Je trouve qu'on n'apprend pas assez des nouvelles personnes des équipes, mais surtout des juniors, des gens qui ont une moins grande expertise technique. On a du mal à intégrer ce qu'ils amènent dans les équipes en général, dans mon expérience en tout cas. Dans notre sujet, il y a aussi un sujet autour de ça, c'est-à-dire... Pour se remettre en question, c'est bien d'apprendre de gens qui ont une vie, que ce soit des sorties d'école, qui ont plein d'idées, qui savent mieux que tout le monde, ils sont un peu pénibles, mais ils savent effectivement plein de choses. Ou des personnes qui ne viennent pas de là, on a des tas de choses à apprendre d'un nouveau membre de l'équipe, au moins dans son questionnement. Parce que ça va être plus facile pour lui ou elle de poser des questions, pourquoi vous avez fait ça de cette manière-là.
La question naïve est toujours un super indicateur. c'est un bon thermomètre je comprends pas pourquoi vous avez fait ça et des fois tu te retrouves à devoir expliquer et des fois tu peux pas parce que tu sais plus et du coup il y a eu un problème de passation de connaissances et des fois, moi ça m'est arrivé de me sentir con en me disant ouais c'était vrai il y a un an et demi quand on a fait ce choix mais ça n'a plus aucun sens maintenant alors que la question était naïve sans chercher à attaquer ça, enfin factuellement ça arrive Et j'aime bien ces parties de questions naïves qu'il faut savoir prendre avec toute la bienveillance possible. Pas faire... Il n'y a pas le temps. Éviter ce travers-là qu'on peut avoir des fois quand on a des fois une hiérarchie qui ne nous laisse pas le temps. C'est pour ça que quand on prend des juniors, c'est bien de laisser le temps aux seniors de s'en occuper. En général c'est la base, si tu fais pas ça il va y avoir une autre problématique, ça c'est un autre axe, une autre problématique de justement de gestion d'équipe prendre des juniors parce que ça coûte pas cher c'est pas une fin en soi tu prends des juniors parce que tu donnes le temps aux seniors de s'en occuper, de les faire monter en compétences, de leur expliquer tout ce qu'il y a à savoir et de transmettre et de gérer aussi le bus factor puisque ça doit venir avec ça sans pour autant les formater Et là, c'est dur.
Mais du coup, l'inverse aussi. Je trouve qu'il faut laisser le temps au senior d'apprendre. Oui,
c'est ce dont je parle dans ma conf, moi, sur la posture d'humilité. De considérer que même si c'est un junior, tu peux apprendre des choses de cette personne et donc vraiment remettre en question ta position pour lui laisser la place de s'exprimer. Parce que c'est en faisant du père avec des juniors que des fois tu apprends des trucs de fou.
Il y a un dernier point qui me faisait question, où en vrai je suis curieux de voir votre talk une fois tout terminé. La première fois que vous en avez parlé, vous me parliez de... un peu de gestion du legacy humain, et des techniques de refacto. Moi, je sais plus ou moins refactorer du code, je vais typer des trucs, je vais encapsuler des comportements, je vais extraire des méthodes, j'ai plein de trucs à faire. J'ai potentiellement... Enfin, j'imagine des trucs, mais j'ai un peu de mal à voir jusqu'où on peut faire des parallèles comme ça sur de l'humain. Vous avez commencé à lister des choses qui s'y prêtent bien, et d'autres pas du tout.
je veux du spoil la métaphore la plus facile c'est la mais c'est plus pour la blague c'est la refonte from scratch où du coup tu tu changes d'équipe pour refaire le produit le parallèle chez les humains c'est tu changes l'équipe tu vires tout le monde tu prends des nouveaux et tu refais et le parallèle il s'étend un peu parce que personnellement c'est pas quelque chose que je trouve qui marche bien de repartir de zéro sur un logiciel et en même temps ça marche pas non plus sur les équipes c'est à dire virer tout le monde et recommencer t'as rien appris du coup de ce que t'as fait la première fois et c'est aussi vrai sur le code voilà Après, pour le reste, on a un peu commencé, mais en même temps, on ne veut pas déshumaniser non plus. C'est-à-dire qu'il y a la blague, c'est marrant, de considérer le Human Legacy comme le Code Legacy. En même temps, on n'est pas non plus là pour... On en a parlé un petit peu, pour montrer du doigt, dire que le Dev Legacy, c'est mal, c'est vous, c'est de votre faute, personnellement, etc. Donc il faut quand même arriver à trouver des parallèles qui... qui à la fois sont pertinents et ne sont pas des parallèles de dictateurs. Donc on y travaille, on aimerait bien que ça fonctionne, mais faudrait voir ce que ça donne quand même.
Et l'idée c'est de l'introduire aussi dans la forme, sur un truc un peu plus type discussion entre Léa et moi, comme on pourrait avoir en buvant une bière, où on pourrait discuter de ces parallèles-là sans vraiment que ça ait un impact dans ce qu'on fait au quotidien. C'est aussi le fait de... Quand on parle de refonte ou de Strangler Fig pour appliquer à des humains, tu peux très bien imaginer ton étranglé des développeurs, mais c'est pas... C'est parce qu'on veut que les gens retenaient de la con. C'est juste pour faire des blagues aussi.
Tu peux redéfinir le Strangler Fig ? Je pense pas que tout le monde qui écoutera ça connaît le pattern.
Le Strangler Fig, c'est un pattern de gestion du legacy sur lequel tu vas... Pour des nouvelles features, mettre... t'isoler complètement de tes interactions avec ton... Oh, isoler, non. Mettre une couche de... d'ACL. Ah, j'ai perdu le... Anticorruption. Anticorruption, je ne sais pas pourquoi je ne l'avais plus. Une couche d'anticorruption à chacune de tes interactions avec le Legacy, pour être complètement isolé de son comportement et avoir aucun effet de bord dû à son fonctionnement. Et au fur et à mesure... tu vas pouvoir faire comme le palmiétrangleur, le figuierétrangleur, grappiller un peu ton legacy, le sortir, ses responsabilités, les mettre dans ton application qui finalement est développée avec des meilleures pratiques et mieux faites, et l'étouffer au fur et à mesure ton legacy pour que jamais il déborde sur ta refonte.
Mais tu vois, c'est... Comme on en a parlé là, je pense que c'est un peu ce qui se passait dans la startup dont je parlais. C'est-à-dire que les fondateurs et les gens qui avaient tout un tas d'idées, ils étaient entourés de, pas de gens qui les étranglent, mais de PO ou de devs qui comprenaient le besoin et agissaient un peu comme une couche anti-corruption, c'est-à-dire... décider, enfin DPO, DPM aussi d'ailleurs, adapter les idées pour en faire quelque chose qui servirait le produit tel qu'il est maintenant. Ce qui permettait à la fois de profiter de toutes ces idées et ne pas complètement refaire un Big Bang à chaque fois qu'il y avait une nouvelle idée géniale. Après, ce n'est pas extrêmement novateur. Il y a plein de gens qui font ça. Il paraît que c'est comme ça que Tesla gère Elon Musk.
Je ne sais pas comment il... Je ne veux pas... Je ne sais pas si j'ai envie de parler de ce mec-là.
On peut le.
Tu pourrais le couter. Mais force est de constater, oui, que je pense qu'il y a plein de choses qui, dans les boîtes d'Elon Musk et d'autres, il y a des équipes qui réussissent malgré leur hiérarchie. Et il y aurait peut-être beaucoup à prendre de ces équipes-là, très premier degré. Donc, il y a peut-être quelque chose à voir là-dedans. Ça fait un moment qu'on cause, du coup. Donc, sur le... Je sais pas par quel bout le prendre. Sur l'avancée de votre sujet, aujourd'hui, alors on a... En fait, on a... J'étais censé vous aider, tout ça, à avancer. En fait, on a juste brainstormé sur tout ce qui peut arriver. On a parlé du sujet, parce que moi, je dérive. Le sujet m'intéresse aussi éminemment, parce que c'est un des... Je pense que c'est un des... des plus gros points qu'on a dans notre métier, c'est de gérer l'existant. Vous, vous vous sentez comment pour, j'allais dire, pour continuer à avancer, à travailler sur ce sujet et pour revenir dans un mois ou deux pour le présenter tout fini, tout beau, tout prêt ?
Moi, je ne suis pas déçue parce que c'est toujours comme ça. J'ai une idée. Ensuite, il y a une phase d'expansion où déjà, il existe des choses. Donc, je vois... Je consomme du savoir. Je vois des vidéos, je lis des trucs. Et il y a un moment où je me dis Oh là là, mais il va me falloir 10 heures pour présenter tout ça parce que, bien sûr que c'est le nouveau framework de lecture du monde entier qui va révolutionner la tech. Après, on arrive à trouver la niche, le point particulier dont on a envie de parler, qu'on trouve intéressant, plus intéressant que le reste. plus facile ou qui va correspondre au format. Et du coup, je pense que de tout ce dont on a parlé, quand on aura fini de voir toutes nos sources et de re-brainstormer encore... Il y aura peut-être, si ça se trouve, rien dans le talk final. J'espère pas, mais...
Je ne pense pas.
Mais du coup, oui, là, on est en phase d'expansion de... Ah, ce sujet, il est lié à ça, qui est lié à ça, qui est lié à ça. Et après, il y aura une phase de concentration.
Oui, clairement.
Moi, j'aimerais beaucoup, pour l'auditoire qui est toujours là, essayer des... des remarques, des souhaits d'activer plus là-dessus. Je trouverais ça intéressant au moment où je vais le publier sur les réseaux, qu'il puisse y avoir des discussions en dessous, je trouverais ça très très cool. Parce que le sujet est justement à hyper basse, comme tu dis. Il y a des sources qui vont de partout, il y a du vécu je pense qu'il y a à prendre en compte. J'aime bien avoir des sources un peu... scientifique, je mets des gros guillemets en visuel, mais un peu... Ouais, avec de la data sourcée. J'aime bien ce type de données qui a en général plus de poids, mais du vécu d'une personne, d'une deuxième, d'une troisième, des fois ça donne des bons axes de lecture et de recherche. Donc moi je trouverais ça intéressant.
Oui, j'allais rebondir sur ce que disait Léa, pour dire qu'on était clairement au début de notre travail et que... Pour l'instant, on a orienté notre talk tel qu'on te l'a présenté, mais on n'est pas sûr qu'il ressemblera à ça à la fin. Et pour le moment, dans le taf qu'on a fait, on essaye d'en sortir un abstract pour pouvoir soumettre, pour pouvoir bénéficier des jours de création de contenu Shodo. Et il faudra venir voir le talk, parce qu'en plus, tu pourras apprécier les illustrations de Eve.
C'est presque une private joke. Du coup, Eve a fait des illustrations pour plusieurs tools qui ont à chaque fois plutôt bien marché. Donc, ça sera avec grand plaisir. S'il y a des gens qui ont envie de discuter avec vous de ça, Léa, t'as au moins un réseau, t'es au moins sur LinkedIn, je crois. Tu es contactable ?
Je suis sur LinkedIn, je m'appelle Léa Coston et on me voit parfois dans les meet-ups lyonnais.
Ok. Yann, je sais pas si t'as... Beaucoup de réseaux, c'est visible.
Alors moi malheureusement je n'ai pas beaucoup de réseaux, donc c'est plus dur de me contacter comme ça. Après vous pouvez dénicher ma première conf et récupérer mon adresse mail perso si vous voulez vraiment me contacter absolument. Mais sinon vous pouvez passer par Léa, je pense qu'elle me fera parvenir les messages. Et sinon oui je traite dans les meetups lyonnais, particulièrement celui des crafters, le meetup Python et LyonJS de temps à autre. Au plaisir de s'y croiser.
Eh bien, merci à tous les deux d'être venus. Ça me fait un épisode qui sort un peu de l'ordinaire. Ça faisait une discussion autant sur le fond que sur la forme, j'aime bien. J'ai vraiment bien envie que vous repassiez quand le sujet sera plus sec. Quitte à vous donner des idées dans la discussion pour faire des suites. parce que je pense que ça peut appeler des suites donc encore une fois merci d'être venu et puis quant à vous, quant à toi cher auditoire, auditeur, auditrice qui nous a écouté jusqu'ici il me reste à te souhaiter une excellente fin de semaine à la prochaine pour un nouvel épisode et d'ici là, geekez bien et codez bien
Description
Léa et Yann ont envie de parler du concept de développeur legacy et on va brainstormer autour de ce concept pour les aider à travailler sur leur talk!
Entre recherche d'informations, recherche d'axes de lecture, venez découvrir le processus d'idéation inhérent à la création d'un talk!
Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.
Transcription
Bonjour à toutes et à tous, et bienvenue dans ce nouvel épisode du podcast Punkin'Dev. Aujourd'hui, je reçois, j'ai l'impression de dire souvent pareil, non pas une, mais deux personnes dans le podcast. Des personnes qui ne sont jamais venues, et rien que ça c'est un grand plaisir. Je vais vous laisser vous présenter, on commence par toi Léa. Bonjour Léa, ça va ?
Bonjour, ça va super, et toi ?
Ça va très bien, est-ce que tu te présenterais pas en deux secondes, rapidement ?
Bien sûr, donc je suis Léa, je suis dev back depuis 4 ou 5 ans. Je travaille pour Shodo Lyon en ce moment et je fais aussi quelques confs, surtout sur des sujets autour des équipes et de comment constituer une bonne équipe change la manière dont on va faire le développement et produit du meilleur dev.
Dac, merci. Donc tu travailles chez Shodo, et chez Shodo tu as un collègue que voilà. Bonjour Yann. Salut. Ça va ?
Ça va et toi ?
Ça va bien. Et bah à ton tour, te présenter. T'as plus le droit de dire que t'es chez Shodo, on l'a déjà dit.
Ah ouais, je suis récemment chez Shodo. Moi ça fait plus de 8 ans que je suis dans le dev, particulièrement en full stack. J'ai rencontré le craft il y a quelques années, et l'année dernière je me suis lancé un peu dans ma première conf, et j'ai bien aimé l'exercice, et c'est pour ça que là, avec Léa, qui est une grande conférencière internationale, je me suis dit qu'on pouvait élaborer un sujet intéressant. Parce qu'on a des expériences qu'on a pu recouper sur des sujets plutôt cools.
Ça, c'est une très bonne nouvelle. Donc du coup, vous allez faire un sujet tous les deux. Qui c'est qui veut me résumer un petit peu le sujet ? Je ne sais pas si vous avez un titre ou un concept là-dedans. Ça ressemble à quoi pour l'instant ?
Pour l'instant, on n'a pas encore de titre. On s'est rendu compte en discutant tous les deux. Je pense qu'on peut dire que Yann et moi, on a travaillé ensemble dans plusieurs... Ce n'est pas la première fois qu'on travaille dans la même entreprise. Et on discute beaucoup de nos pratiques, comment on voit notre métier, etc. Et dans des équipes précédentes, on s'est retrouvés tous les deux à râler sur nos collègues, la manière dont ils font certaines choses. Et c'est Yann qui va raconter son anecdote sur comment on est arrivé sur le... concept qui nous parle à tous les deux de développeur legacy.
Oui, c'est un concept qui a émergé lors d'une discussion de bar évidemment. Après une journée un peu frustrante pour moi. Tout simplement dans une équipe qui avait grandi récemment et dans laquelle on avait des gens qui étaient là depuis assez longtemps, depuis le début du projet et d'autres gens qui arrivaient avec des nouvelles pratiques. on s'est retrouvé en rétro à rediscuter de est-ce que ça vaut vraiment le coup de faire des MR review ? Est-ce que ça vaut vraiment le coup de faire des tests ? Alors que c'était des concepts de qualité qu'on pensait acquis pour une grosse partie de l'équipe. Et le problème c'est que les personnes qui remettaient en question ça c'était les développeurs qui étaient là depuis toujours, qui avaient connu le projet à ses débuts et qui l'avaient transformé en gros plat de spaghettis et c'est pour ça qu'on devait le refactorer pour pour arriver à le maintenir. Suite à cette rétro, on s'était quitté en n'étant pas d'accord, et dans la même journée, on avait un développeur qui avait mergé sur main, forcément déployé en prod, et on s'en était tiré avec 5-6 tickets de bug, parce que le code n'était pas testé, donc le plaisir. Et c'était un des développeurs qui était là depuis le début. Et donc c'est comme ça que j'ai commencé à parler de... de ce concept de développeur legacy, sans trop... Juste pour la blague, parce qu'on parle souvent de code legacy. Et Léa m'en a reparlé à un autre moment, parce qu'elle avait l'expérience de... Une expérience pas tout à fait similaire, mais qu'on pouvait aussi qualifier d'expérience avec des développeurs legacy.
En fait, on a commencé à discuter... En ESN, on... passent beaucoup d'entretiens chez les clients. Et il y a certaines entreprises qui mettent en avant le fait que leurs devs sont là depuis qu'ils n'ont pas beaucoup de turnover, ce qui en soi est une bonne chose pour une culture d'entreprise. Mais en même temps, dans le code, quand on arrive dans une équipe où il n'y a que des devs qui sont là depuis plus de dix ans et qu'il n'y a pas de 109 non plus, on a commencé à dire, ah, mais c'est une bonne chose pour la culture d'entreprise, les gens restent. Mais en même temps, d'un point de vue des pratiques, des fois, c'est un peu un beige flag, on va dire, entre pas vraiment un red flag, mais en même temps, est-ce que c'est une si bonne chose que ça ? Est-ce que vraiment on a envie de rentrer dans cette équipe qui a les mêmes pratiques et les mêmes personnes qui la composent depuis plusieurs années ? Moi, ça m'est arrivé d'être dans des équipes où les devs historiques font beaucoup de choses sur des canaux implicites. Et quand on arrive, c'est dur de comprendre. Il y a des process officiels, mais qui sont... pas vraiment respectées et qui permettent pas de faire ce qu'on veut. Et donc en tant que nouveau dev, pas junior, juste nouveau qui arrive dans cette équipe, on n'a pas forcément la main sur la vraie manière dont les choses se passent. Et donc on s'est dit en discutant que ça se rapprochait un peu de cette idée de dev legacy, c'est-à-dire comme le code, des choses qui sont là depuis longtemps et qui ont un peu leur propre vie en dehors des process officiels.
Alors si j'essaie de recentrer sur la notion de dev legacy, alors je remets la définition, le legacy ça veut dire juste héritage, un code legacy c'est un code dont on hérite. J'ai l'impression que le dev legacy c'est un peu le truc qu'on subit, qui est là, il faut faire avec, comme le code, on peut pas passer outre, ça fait le taf sur certains trucs, mais... Mais ça pose plein d'autres problèmes. Je suis dedans ou vous avez peut-être plus de nuances ?
T'es un peu dedans, mais à la fois, il y a aussi de la nuance. Code Legacy, c'est pas toujours quelque chose de... Comme tu l'as dit, ça veut simplement dire héritage et ça veut pas forcément dire qu'on le subit ou que c'est un problème. C'est juste quelque chose qu'il faut gérer. Il y a des méthodes, il n'y a pas de refacto ou pas. Parfois, il n'y a pas besoin de le résorber, mais ça veut dire que c'est quelque chose qui a une manière de le gérer qui est différente du code moins legacy. Et du coup, les devs legacy, ils ne sont pas forcément... Ce n'est pas forcément une mauvaise chose.
Oui, c'est ce que je disais quelque part. Ils font du taf, le code legacy, même si des fois, il nous fait souffrir. C'est lui qui emprunte, c'est lui qui... permet de gêner souvent du cash ou qui permet de rendre service à des utilisateurs, des utilisatrices. Du coup, effectivement, ce que tu disais, le code legacy, on a a priori des méthodes. pour le gérer. On a des méthodes, des pratiques qui ne marchent pas toutes, mais ce n'est pas une science exacte. Donc vous, votre point, c'est que, si vous parlez de ça, j'imagine que vous avez peut-être commencé à réfléchir sur comment on gère des devs legacy.
Eh bien, c'est l'angle qu'on aimerait prendre avec notre talk, où on aimerait parler de notre expertise en tant que dev, donc plutôt partir de la définition et des techniques. qu'on a l'habitude d'utiliser nous en tant que dev pour gérer du code legacy et voir si on peut l'appliquer à des structures organisationnelles où il y a des dev legacies pour pouvoir un peu résorber ce problème, ces frustrations au quotidien. Donc c'est un peu le point un peu original qu'on voudrait introduire dans ce talk. Mais là c'est le sujet sur lequel on est pas mal en recherche. où on regarde un peu les méthodes de gestion de Legacy Remediation, et on essaye de faire des parallèles, ce qui peut être un peu hasardeux, mais d'un autre côté, ça se recoupe quand même pas mal avec des méthodes de conduite du changement, ce genre de choses, où tu vas faire changer les pratiques des gens au sein des équipes.
En même temps...
Alors, allons-y.
Non, mais en même temps, en regardant des confs d'autres personnes, en lisant des choses, je trouve qu'il y a aussi beaucoup à dire sur qu'est-ce que c'est le code Legacy et à quoi on veut remédier quand on parle de Legacy Remédiation, etc. Parce que c'est ce qu'on disait, c'est à la fois quelque chose qu'on subit, mais à la fois quelque chose qui fait le taf. c'est vrai pour les devs aussi donc il ya aussi une réflexion qu'on aimerait avoir sur Comment avoir du bon legacy, en fait ? Que ce soit humain et technique. C'est-à-dire du legacy qui te sert et qui est, du coup, des équipes qui fonctionnent bien dans la durée.
Dans la définition d'Adrien Joly, le code legacy, c'est un code qui a... La première partie de la définition, c'est un code qui a de la valeur pour l'entreprise. De facto, le développeur legacy, c'est quelqu'un qui a une valeur essentielle à l'entreprise parce qu'il connaît tout l'historique du projet. Il sait des choses que... Pas tout le monde sait. Il sait comment on est arrivé là. Il sait où trouver des bugs, quels bugs sont normaux, dirons-nous. Ce genre de choses, tout l'historique de projet qui peut être un peu touffu, dirons-nous, pour quelqu'un qui arrive dessus de nouveau.
Du coup, là, dans votre réflexion, vous parliez un peu de... chercher des infos, chercher des sources, dans quelle mesure vous appuyez, vous allez essayer de vous appuyer sur de la source académique, entre guillemets, que ce soit des talks, des bouquins, des articles, et dans quelle mesure vous avez aussi peut-être vous des morceaux de retour d'expérience, peut-être de choses que vous avez vues, essayées, je ne sais pas comment vous sourcez votre taf là-dessus.
Ce que j'aime faire habituellement, c'est résoudre les problèmes que j'ai eus moi, donc retour d'expérience sur les problèmes que j'expose. Mais en même temps, il y a beaucoup de sujets qui sont recherchés par des gens dont c'est le métier, et des gens qui ont expérimenté des choses. Et j'aime bien faire un peu un état des lieux de ce qui existe. Et parfois, c'est comme ça que je trouve, je tombe sur des concepts dont je ne savais pas qu'ils existaient, mais qui me permettent de vraiment faire évoluer la manière dont je vois les choses et qui amènent une nouvelle grille de lecture aux choses que je vois dans mon quotidien.
Tu as des exemples un peu concrets de trucs que tu as vus récemment ?
Eh bien, le dernier talk que j'ai fait, c'était sur... qui était sur la sécurité psychologique. Je ne connaissais pas le concept avant. Moi, ce que je voyais, c'est que certaines choses marchaient mieux dans certaines équipes que dans d'autres. Dans certaines équipes, il y avait vraiment beaucoup d'apprentissage global. L'onboarding était facile, ce genre de choses. J'ai commencé par raconter ce qui m'arrivait. Et les gens ont beaucoup relate en se disant Ah oui, moi aussi, c'est comme ça etc. Et en faisant des recherches. Jusqu'à ce que quelqu'un me dise Ah, ce dont tu parles, C'est de la sécurité psychologique. Et du coup, je suis allée lire, j'ai lu des bouquins, j'ai cherché les articles sur Internet. Et effectivement, c'est théorisé, beaucoup recherché depuis 50 ans. Et du coup, ce que j'ai fait et ce que j'aime bien faire, c'est ce concept-là qui est un peu méconnu dans la tech. Peut-être qu'on peut en parler, peut-être qu'on peut l'appliquer à plus d'équipes. Et personnellement, moi, c'est... en faisant Herméneutique, comme je l'ai appris dans le talk de Sarah Dufour, sur le concept de sécurité psychologique, ça m'a aussi donné une grille de lecture de mon quotidien et des leviers pour le changer. Et donc, appliquer à ce qu'on voudrait faire là, c'est un peu similaire, c'est-à-dire que nous, on voit des devs qui se comportent comme du Code Legacy, mais en faisant des recherches sur le Code Legacy, comment on le définit, comment on le traite. Et aussi des recherches, on espère, sur la conduite du changement, comment on fait évoluer les équipes, les frameworks qui existent pour gérer des équipes. Peut-être que ça va nous amener des nouvelles grilles de lecture qui nous permettront de formaliser un peu et de changer notre quotidien sur les dev legacies avec lesquelles on bosse. Ou nous-mêmes quand on est des dev legacies.
Ok, du coup là en fait vous êtes encore en phase d'accumulation de sources, de vous consommer un peu pour créer du... On va créer de la connaissance là-dessus.
D'ailleurs, si tu as des recommandations, on est preneur.
J'en ai assez peu. J'espérais que vous m'en donniez un peu plus sur déjà ce que vous avez eu jusqu'ici. Il y a une partie, je ne sais pas, j'essaie de synthétiser dans ma tête en même temps que ça vient. Il y a une partie un peu conduite du changement qui m'a interpellé. Il y a une partie aussi... Je synthétise, désolé. Je ne sais plus comment vous avez évoqué ça. Quand il y a des process qui sont décrits dans la boîte et qu'en fait, ils ne sont pas respectés et que c'est les devs legacy qui connaissent comment on fait vraiment, plus que l'éventuel doc qui peut traîner à droite à gauche. Ça, c'est des trucs que je trouve intéressants dans le sens où... La première fois où vous m'avez parlé de ce sujet, je me suis dit Ah cool, on va pouvoir tacler les vieux mecs chiants des projets. Et en fait, non seulement c'est d'une moralité douteuse, ma pensée que j'ai eue à ce moment-là, on ne tacle pas des gens comme on tacle du code, le code lui il s'en fout qu'on l'efface, on ne va pas traiter les gens pareil. Mais je trouve ça aussi intéressant de se dire Le code Legacy, c'est lui qui a de la valeur. Donc il y a cet axe un peu de valorisation du legacy, mais en même temps on ne peut pas oublier une partie de remédiation quand il y a un espèce d'immobilisme et de refus d'évoluer vers d'autres choses, que ce soit un refus de personnes qui ne veulent pas ou que ce soit un refus du code parce que le code est ancré depuis tellement longtemps que c'est compliqué de le faire bouger. Est-ce que c'est des axes que vous pensez, que vous envisagez d'exprimer ? dans votre sujet ?
Dans un premier temps, l'idée, c'est de faire des parallèles entre la gestion du code legacy, les techniques et les structures d'équipes de développeurs. Donc forcément, tu as des techniques qui vont être un peu violentes. On ne va pas se le cacher. Mais ça fait partie de l'humour un peu acerbe du talk, je pense. En fait, l'idée, c'est de conclure en donnant des pistes sur comment prévenir ce genre de problème. Parce que tes DevLegacies, c'est ce qu'on dit, ils ont une valeur en tant que connaissance de process, connaissance de métier, etc. Et ça, tu ne veux pas le perdre, tu ne veux pas les faire fuir, parce que c'est valorisable en temps monétairement. Et donc, ton but, c'est aussi de les garder, mais de les faire changer pour pas que ça fruste tes nouveaux devs non plus. Donc, les pistes d'amélioration sont là-dedans.
Après, du coup, comme on a commencé à faire de la biblio, j'ai revu hier le talk de Kavlin Henley que j'avais vu à Newcraft cette année. où il parlait de de dette technique et en fait ça a aussi changé un peu ma perspective là-dessus parce que son take-away c'est un peu que la dette technique c'est pas un problème c'est une conséquence de négligence technique donc on laisse les choses se faire d'elles-mêmes et on n'y revient pas et je trouve que ça s'applique bien à ce qu'on veut faire c'est-à-dire que c'est pas en restant longtemps qu'on devient un dev legacy c'est en remettant pas en cause ses pratiques régulièrement en négligeant son équipe alors elle devient legacy au bout d'un moment alors qu'on peut mais bon après ça c'est normal c'est mutant au début quand on commence un sujet il y a toujours beaucoup de choses qui rentrent d'abord mais moi j'aime bien cette idée que c'est pas une fatalité c'est à dire que si on si on laisse les l'équipe, si on ne prête pas attention à sa propre équipe, alors elle va tourner vers un fonctionnement legacy, c'est-à-dire un truc plus implicite, plus spaghetti, comme si c'était du code. Ce que je disais sur le fait que toutes les communications soient implicites et qu'elles ne suivent pas les process officiels, c'est assez similaire à ça. On passe trop de temps à prendre des raccourcis, à le fameux chemin de... Donc ça me fait penser à quand on marche dans la pelouse et que tout le monde traverse et que ça crée un chemin. Je ne me souviens plus du nom de ce...
Non mais je vois bien l'usage. On a beau faire un joli chemin sinueux qui fait très joli depuis les vues d'en haut, les gens tracent tout droit et du coup ça bouffe la pelouse là où ce n'était pas prévu. Mais les gens prennent le chemin qui est le plus simple a priori, le plus direct.
Donc pour moi, il y a quand même un aspect de si on y prête attention, qu'on remet en cause et qu'on entretient sa dette humaine, en fait, alors on nous dira du legacy qui nous sert au lieu de qu'on subit.
Et surtout que de notre expérience, c'est du legacy que tu subis doublement, parce que grâce à cette magnifique loi de Conway, finalement, quand t'as beaucoup de dev legacy, tu te retrouves facilement avec une big ball of mud de... avec des problèmes pour la maintenir.
Oui, c'est l'aspect technique dont tu parlais. Quand quelqu'un décide de faire tout seul dans son coin et de pousser, c'est des bugs parce que ce n'est pas testé et ce n'est pas dans les pratiques de l'éve. J'aimerais bien arriver à placer le fait que, comme les gens ressemblent à leur chien, le code ressemble à son équipe.
Ah puis là, tu fais ça, tu sors cette phrase, et là j'ai les vieux mèmes qui me passent sur Internet où les gens et leurs chiens se ressemblent souvent, et il y avait des trucs très drôles. Mais quelque part, c'est un des corollaires de la loi de Conway. Ton code finit par ressembler à ton modèle d'organisation et à ton modèle de communication. Si tu as une équipe qui ne communique pas, tu vas avoir des choses qui vont être hyper... hyper hétérogène d'un bout de code à l'autre. Et j'allais dire que c'est globalement inévitable. Effectivement, il faut pouvoir adresser une partie de ta structure de communication pour gérer ta conduite du changement et espérer faire en sorte de modifier un peu la culture qui a fait émerger ce Ausha. Mais en même temps, tu peux la faire par, je ne suis pas expert là-dessus, sur la loi de Conway, mais tu peux la faire par la loi de Conway inversée en agissant sur ton code pour essayer de faire évoluer la culture qui va derrière. Donc ça, c'est deux approches, parce que des fois, faire changer ton organisation quand tu es chez des... Dans des contextes de start-up, c'est facile, ça change tout le temps. De toute façon, il y a une chance sur deux que sous neuf mois, il n'y ait plus personne, que tout soit effondré. Donc ça change plus facilement dans des grosses administrations qui existent depuis 5, 10, 20, 30, 40 ans. Faire bouger des fois vaut mieux repartir par le code, par la technique parfois. À un moment, ce que tu disais Léa, ça m'a rappelé, puisque tu parles de conf que tu as vu récemment. Moi, je suis en train de relire un bouquin. En ce moment, je suis en train de lire la nouvelle édition de Your Code as a Crime Scene de Adam Tornil. J'avais lu la première édition il y a 2-3 ans. Et là, sur la nouvelle, et ça me rappelle des trucs, quand tu parles de dette technique, il a tout un chapitre qui est un peu un plaidoyer sur c'est bien de vouloir s'attaquer à la dette technique et au Legacy. Par contre, il faut s'y attaquer là où c'est pertinent de s'y attaquer. S'il y a un énorme bout de code qui est tout pourri, mais qui marche, et qu'on ne touche pas, eh ben on ne le touche pas. Je ne sais plus où je l'ai entendue celle-ci, c'est qu'on ne nous paye pas pour réparer des trucs qui marchent. Concrètement, je pense qu'il faut centrer toutes les remédiations, tous les outils, toutes les pratiques de gestion du legacy qu'on peut avoir, il faut les mettre là où ça va avoir de la valeur. Et où ça a de la valeur, eh ben ça va avoir de la valeur là où ça nous fait mal en temps normal. Si un fichier qui n'est pas le pire du monde, mais qu'on y retouche toutes les semaines, et qu'à chaque semaine il va de pire en pire, on sait qu'on va avoir un axe de travail là-dessus, qu'on va avoir un réel gain à travailler sur ça. Par contre, là je serais preneur de vos idées sur est-ce que ça c'est applicable en termes d'analyse de comportement humain ? Est-ce qu'on peut voir... Je ne sais pas. Est-ce que c'est transposable sur l'humain ? Est-ce que ça rentre dans votre scope ?
Sur le premier concept, à savoir si tu dois toucher des équipes legacy qui vont finalement fonctionner très bien et te créer de la valeur, je pense qu'il n'y a pas besoin. Si elles arrivent à fonctionner en vase clos et ne pas créer de frustration en dehors. et du coup tu n'as pas besoin de penser à refactorer ce goût d'équipe. Mais c'est sûr que c'est sur les sujets là où il y a de la valeur pour ton business, il faut être le plus attentif et écouter tes devs pour détecter s'il y a des problèmes de développeurs legacy, de gens qui ne font pas circuler les infos, de gens qui ne s'incluent pas dans les pratiques de l'équipe. Parce que tu vas générer de la frustration, du turnover, et la qualité de ton code va le subir aussi.
Après, moi je suis moyen d'accord. Je trouve que ça rentre dans notre scope, mais je ne suis pas d'accord non plus avec le truc on n'est pas payé pour réparer des choses qui marchent c'est vrai mais on n'est pas très bon dans je trouve qu'on n'est pas très bon dans le dev pour mesurer est ce qu'elle marche ou pas les choses et notamment que ce soit dans le code ou dans les équipes si on a un bout dont personne sait comment ça marche ou dans une équipe ce serait l'équivalent ce serait vraiment les faits un peu tour d'ivoire une équipe dont personne sait ce qu'elle fait et comment elle marche mais on sait que ça marche Le problème de ça, c'est que dans l'évaluation du risque, les chances que ça tombe en panne sont faibles, et donc on a tendance à ne pas vouloir y aller, mais les conséquences si ça tombe en panne sont élevées, parce qu'on ne sait pas le réparer. Et c'est quelque chose qu'on prend assez peu en compte dans le dev, les conséquences. Et donc, même si ce n'est pas forcément prioritaire, je trouve que ça vaut le coup des fois de réfectorer quelque chose qui marche, juste parce que... Si ça tombe en panne, on ne saurait pas le faire sinon.
Je vais juste mettre en perspective. Dans le fond, on est d'accord. Mais il y a différentes choses. Ce que tu dis, la partie risque, je peux vous inviter à aller checker un talk récent de Cyril Martraire qui parle de théorie de la résidualité. Alors, je l'ai vu une fois. La première fois, c'est... un peu abrupt comme concept, en même temps c'est un concept sur lequel il y a une thèse qui est en cours, donc c'est pas sec, mais ça reste intéressant, et où justement il propose de soumettre, en exercice de pensée, mais de soumettre nos architectures et notre code à des risques potentiellement, tous les risques possibles et imaginables, et voir qu'est-ce qui peut arriver et qu'est-ce qu'on peut faire soit pour se prémunir de ça au cas où ça arrive, soit pour faire en sorte que ça n'arrive pas, et driver nos architectures par ça. Typiquement, qu'est-ce qui se passe si tout le réseau tombe ? Comment va supporter notre appli ? Est-ce qu'il faut réfléchir à mettre en place un mode hors connexion ou pas ? Par exemple, qu'est-ce qui se passe si j'ai une base de données qui tombe ? Est-ce qu'il y a encore des choses qui peuvent marcher avec des services externes ? Le but, ce n'est pas de dire qu'il faut faire ça ou ça. En général, c'est sur chaque appli quel point est crucial et gérer un petit peu des décisions d'architecture par la gestion du risque. Maintenant, ce que je voulais... Ce que je voulais dire quand je disais qu'on n'est pas payé à réparer des trucs qui marchent, c'est là que le parallèle humain a peut-être sa limite. Concrètement, si un bout de code fonctionne, même si c'est le code le plus dégueulasse du monde, tant qu'on n'a pas à le toucher, il n'y a pas d'intérêt. Il n'y a pas de ROI à venir faire du refacto là-dessus. Là, je me place en tant que manager qui tient le portefeuille. S'il y a mes devs qui disent, on va réparer un bout de code ici, pourquoi ça ne marche pas ? Non, ça marche, laissez-le tranquille. Par contre, c'est bien d'avoir la connaissance de, il y a une grosse big ball of mud là-bas, et le jour où, attention, on va toucher quelque chose là-dessus, stop. Là, on a un gros facteur de risque. Il vaut certainement mieux faire du refacto avant de commencer quoi que ce soit. Ou alors il faut prendre en compte le fait qu'on ne maîtrise pas du tout notre deadline. Et c'est encore un point que défend Adam Tornil dans Your Code as a Crime Scene, puisque lui il propose des pratiques et tout un outillage pour le détecter ça, en amont, et avoir conscience de tes points potentiellement problématiques avant de faire quoi que ce soit. Ce qui permet de driver un petit peu, j'allais dire... certains choix, certains choix de gestion technique et certains choix de communication. Dans le sens où on a plein de points, plein de zones du code qui sont problématiques, on y revient souvent, il faut investir du temps pour faire de l'amélioration continue, pour faire en sorte que ces zones arrêtent de nous coûter autant de pognon. Et aussi identifier, genre ce coin-là, là-bas, on a deux, trois fichiers, 12 000 lignes chacun, qui fonctionnent ensemble, qui sont ultra couplés. Il y a trois ans, on a eu plein de bugs dessus. Maintenant, ça marche. On n'a pas besoin d'y toucher. On n'a pas d'évol qui concerne ça. C'est cool. Par contre, il faut être capable de savoir que ce truc-là existe et de lever une alerte. Bon, on a un truc en lien avec ça. attention, il va falloir faire du refacto ou prévenir toute l'équipe. On se met en best effort sur refactorer ce truc-là et on va prévenir la hiérarchie que non, ce truc-là est hyper risqué. Et peut-être qu'en termes de gestion du risque, le management va dire ça peut-être du coup on ne le fait pas. Si c'est risqué à ce point, si ça nous casse une feature qui est ultra importante, il y a une vraie réflexion à avoir là-dessus. Mais du coup, sans piètre, j'étais en train de me dire que je voulais faire un épisode sur Your Code as a Crime Scene. J'y reviendrai probablement. Mais je vous reparlerai si vous voulez des sources là-dessus. Quand je l'aurai fini, je pourrai vous le prêter le bouquin. Il y a des trucs super intéressants à cet égard-là.
C'est intéressant parce que je sais que c'est un des trucs qui tiennent à cœur à Ian. C'est de proposer un framework ou une méthode pour détecter justement les... les big ball of mud humaines c'est à dire on aimerait bien si on y arrive trouver une forme de questionnaire ou checklist qui vous dit ah attention vous avez une big ball of mud d'humain parce que à l'heure actuelle c'est assez dur à détecter parce que c'est comme du code legacy c'est que ça a des effets pervers de
de des engagements des des personnes Parce que sur ton code Legacy, si c'est dur de l'entretenir, c'est dur de faire des tests dessus, de toute façon il n'y a pas d'autres tests dessus, donc tu ne vas pas commencer à en faire, parce que c'est trop compliqué quand tu vas créer de nouvelles features. Mais de la même façon, si ton organisation fonctionne en mettant en avant tes développeurs Legacy, ou juste ton Legacy humain en général, tu vas adresser le problème une fois ou deux fois, par exemple au moment de la rétro, et s'il n'y a rien qui se passe, tu vas laisser tomber. Et ce sera juste un problème que tu gèreras un peu comme tu peux.
Pour la détection, je te dirais, il y a une troisième partie dans le bouquin que je n'ai pas encore relue, je n'en suis pas encore là, sur justement un petit peu explorer la partie... humaine et sociale du projet via le code parce qu'on peut voir des choses. Je te reparlerai à ce moment-là, tu verras si vous voulez greffer ça dedans. Mais il y a de l'outillage qui existe, notamment sur la gestion du bus factor. En anglais, ils appellent ça le truck factor. Pour les personnes qui ne connaissent pas, c'est combien de personnes de ton équipe peuvent passer sous un bus et que du coup, ton projet tourne encore. Et il n'y a pas une seule réponse sur un projet en général. Il y a des zones qui ont un bus factor qui est très bas. Quant à justement, c'est le principe du dev legacy en général. Quand tu as ton dev qui est là depuis 8-9 ans, il y a des zones où c'est la seule personne qui sait comment ça marche. Et si cette personne-là se barre de manière voulue ou non. Ouais, ça va être compliqué. Il va y avoir un point de gestion à traiter dessus. Et... Et s'il y a des gens qui se disent Ouais, mais ça n'arrive pas. Alors, si ça arrive, des devs qui disparaissent du jour au lendemain pour x ou y raison, ça peut arriver. Et même des fois, alors on dit toujours oui, il y a des préavis s'ils se barrent. J'ai un collègue qui s'est arrivé, vraiment un de leurs collègues, j'ai juste jamais revenu. Il s'est pris une voiture, accident et fin de vie. Ils ont eu à gérer ce problème-là, premier degré. Genre, on a le principal sachant du projet qui est décédé. Donc du jour au lendemain, on a un énorme trou de connaissances, comment on gère, comment on aurait dû gérer en amont. Et sur la conduite du changement et le partage de connaissances, ils ont mis en place plein de trucs. Il faudrait que je retrouve cette personne-là qui nous raconte un peu comment ils ont géré et réagi derrière. Mais c'est un truc qu'on met souvent au second plan, genre non mais ça va pas arriver. Bah si, ça arrive. Et comme tu disais Léa, c'est de la gestion du risque. Qu'est-ce que tu acceptes comme niveau de risque sur certains trucs ?
Et oui, et pour revenir sur l'invisibilité de ce problème, c'est aussi parce que tes développeurs legacy, comme ils sont historiques, c'est eux qui ont la légitimité sur le projet, et c'est par eux que tu vas sonder tes équipes, en tant que manager souvent, parce que tu auras une relation privilégiée avec eux, vu que tu les auras connus depuis super longtemps. Et donc il y a des canaux comme ça, implicites, qui vont se créer, et tu ne vas jamais avoir le problème... chez les nouveaux devs. Pour pouvoir régler ce genre de choses et savoir ce qui se passe, il faut créer des canaux avec tous les membres des équipes pour sonder ce qui se passe.
Est-ce que vous avez une vision de la... justement de ce que tu dis, la posture des devs legacy qui ont des canaux de communication privilégiés de fait de leur ancienneté. Après, c'est peut-être plus lointain, c'est une question qui me venait comme ça sur la gestion de la culture. Quand tu as des nouveaux profils, tu peux avoir toute la richesse des profils humains, mais... Comment ça peut se gérer, s'intégrer à tout ça ? Le fait d'avoir soit des nouveaux profils qui vont prendre beaucoup de place. J'ai déjà eu le cas dans une équipe des jeunes devs qui sortent d'école, qui savent mieux que tout le monde. Le vieux de la vieille, il a deux, trois infos que peut-être t'as pas. Même s'il est vieux et qu'effectivement il est pénible parce qu'il reste campé sur plein de positions, des fois il a peut-être des bonnes raisons. Et à l'inverse, des profils qui vont se faire digérer beaucoup plus vite par le legacy, qui ne vont pas arriver à remettre en cause parce que des fois, c'est une question de profil très personnel. Il y a des gens qui vont chercher à surtout pas faire de vagues. Et je vais essayer de mimiquer le plus possible la culture en place pour m'intégrer, parce que je gère comme ça. Enfin voilà, tous les profils existent. Je ne sais pas si... Au-delà du dev legacy, c'est un peu plus la dette humaine. En fait, j'ai le petit problème avec le dev legacy, c'est que ça a tendance à pointer une personne. Alors que ce n'est pas forcément le cas, c'est plus le système qui est en place. Mais quant à du legacy humain, en sens général, sur l'équipe, ça va se reproduire un peu tout seul. Est-ce que vous avez vu, vous voyez, vous imaginez justement des leviers pour... Et pour limiter l'impact de tout ça ?
Déjà, je suis d'accord avec toi que c'est un système et pas des personnes. Parce que j'ai été dans des startups où il reste le fondateur qui veut faire son truc dans son coin, mais en fait, le système et l'organisation ne lui permettent pas d'avoir l'impact de... disrupter un peu le flow de tout le monde. Et en fait, ce n'est pas un problème. C'est-à-dire qu'il y a toujours cette personne qui a une connaissance extensive du projet et qui a plein d'idées, mais les idées, elles sont absorbées et utilisées d'une manière qui fait grandir tout le monde par l'organisation. Du coup, je suppose qu'on pourrait apprendre d'eux. Mais pas que. Sur les méthodes et... Déjà de manière évidente, l'agilité quand c'est arrivé, moi je n'étais pas dans l'informatique avant l'agilité, mais les frameworks, que ce soit Scrum ou autre, de l'agilité, ça a quand même amené de l'explicite dans l'organisation des équipes et dans le partage de connaissances, qui permettent de remettre en cause un peu comment on fait les choses, de manière plus ritualisée, etc. Même si ça a forcément aussi des effets pervers, etc. Je pense que ça a déjà amené des choses là-dessus. Et je voulais aussi parler dans la lignée de Extreme Programming, où on va dire cette famille de pensées, de faire le code, etc., qui permettent aussi d'expliciter le partage de connaissances, d'expliciter la manière dont les équipes fonctionnent. Et c'est des pistes pour faire rentrer des nouvelles personnes dans l'équipe, diffuser les connaissances Legacy de gens qui sont là depuis longtemps, depuis des gens qui viennent d'arriver.
J'avais une autre remarque sur le... On parle de Legacy. Je rebondis sur des trucs que vous avez dit il y a un petit moment déjà. Sur la notion de Dev Legacy. Un peu en lien avec ce que je disais juste avant. Faire en sorte que les gens ne se fassent pas digérer trop vite par le système. L'agilité adresse ces trucs. Je vais citer ma source du moment, Adam Tornil, il en parle, il justifie ça justement avec l'arrivée des pratiques agiles et des formats d'itération qui sont plus courts qu'avant. Il y a des études assez sérieuses, il faut que je note dans un coin de tête, enfin en vrai sur un bout de papier, que je puisse les ressortir. Il y a des sources sérieuses là-dessus. Il y a une vraie étude qui a été menée sur cette notion de legacy qui est souvent liée avec la dimension, j'allais dire, plutôt maintenance évolutive des applis. À une époque où on n'avait que Waterfall, c'était normal d'avoir des projets qui vivaient 6 mois, 1 an, 1 an et demi avant de partir en prod. Et de fait, on itérait peu ou pas sur de l'existant, on rajoutait de la feature, on rajoutait de la feature, et on commençait à réouvrir l'existant que quand on partait en maintenance et qu'il y avait des évoles à faire. Avec les process agiles, en gros, passer la première itération... Pour ces gens-là et pour Adam Tornil, passer la première itération, qui dure une semaine, deux semaines, trois semaines ou même deux mois, passer ça, on est dans du legacy, parce qu'on va itérer sur du plus court, parce qu'on va relire plus de codes que ce qu'on va en produire. Là où avec Waterfall, on faisait des specs fonctionnels, des specs techniques détaillés, on implémentait, on ajoutait le package, ça partait en recettes, et on passait au sujet suivant, et il y avait généralement très peu de collisions. d'une feature à l'autre puisqu'on a ajouté des trucs. Aujourd'hui, en fait, le legacy, il naît dès l'itération 2, même souvent l'itération 1 puisque tu vas souvent avoir un sprint 0 pour bootstrapper l'archi, les machins. Donc, en gros, dès l'itération 1, quelque part, t'es en legacy, t'es en maintenance et j'ai presque envie de dire n'importe quel dev devient dev legacy quasiment tout de suite, tu deviens ton propre legacy. Ça devient un peu méta, un peu déprimant. J'arrive sur un projet, au bout de 15 jours, ça y est, je suis mon propre legacy, il faut que je gère ma propre résistance au changement, alors que je suis là potentiellement pour amener du changement. Je ne sais pas si c'est des axes, des trucs que vous avez observés, des axes que vous voulez aborder sur le sujet.
Clairement... on n'est pas allé aussi loin sur les concepts de développeurs legacy et même de code legacy comme par itération agile comme tu en parles c'est un axe super intéressant et de la même façon en fait pour pouvoir gérer tes problèmes de legacy humain il faut faire des petites itérations aussi et tester des trucs sur la structure de ton équipe sur quel rôle à quelle personne etc et Comment définir les rôles ? Est-ce que tu mets en place des pratiques de mentoring ? Comment tu fais ce genre de choses ? Pour essayer des choses et trouver ce qui fonctionne avec ton équipe pour résorber aussi ce problème de DevLegacy tout en ayant conscience, comme tu viens de le définir, que dès ta première itération, finalement, tu deviens un DevLegacy parce que tu as un savoir qui est inhérent à ce que tu as fait sur la code base. et qui n'est pas forcément diffusée dans le reste de l'équipe.
Oui, moi, c'est souvent ma conclusion. C'est vraiment un truc que je trouve important, c'est souvent on essaye de résoudre des problèmes, et le problème, c'est nous. C'est souvent la conclusion de la plupart des sujets que j'aborde, qui est qu'on peut toujours commencer par soi-même pour s'améliorer, et ce qui est important, c'est de douter. Je ne sais plus qui a dit ça, mais si tu doutes et que tu remets en cause ta pratique tout le temps, pas la changer, mais juste remettre en cause, challenger les décisions que tu as prises, vérifier, parce qu'une décision, quand tu la prends, des fois, elle est bonne, mais une semaine après, elle n'est plus valable. Et donc, il y a forcément un... À la fois, il faut toujours remettre en cause, à la fois, il faut trouver un équilibre, parce qu'on ne peut pas repartir de zéro à chaque... à chaque itération. Et moi, c'est les sujets qui m'intéressent en général. C'est-à-dire trouver cet équilibre entre ce qu'on acquiert et ce qu'on remet en cause et continuer à évoluer tout le temps. Oui, toujours grandir, toujours apprendre en tant qu'individu et en tant que groupe.
Quelque part, c'est un des principes de l'agilité. À intervalles réguliers, prendre le temps de sortir la tête. J'ai plus le... libelles exactes, mais prendre le temps de sortir la tête du guidon et de remettre en question, de remettre en cause, de se poser, plutôt que d'être dans un rush perpétuel où tu ne remets plus en cause ce que tu fais et comment tu le fais. En sachant que le comment, oui. Et il y a plus en plus de devs qui soutiennent ce que tu disais, c'est que lire du code, écrire du code, c'est la partie facile de notre métier. Gérer des interactions humaines, c'est la partie difficile. Donc oui, on est en plein de... on est en plein dedans.
Et ce que tu disais sur les gens qui seront absorbés par le legacy humain, j'aimerais bien, on verra s'il y a une place dans tout ça parce qu'on est un peu partis dans toutes les directions, mais j'aimerais bien qu'on arrive à placer des choses sur ce qui se fait en mentoring tournant ou en mentoring inversé. C'est un autre de mes dada. Je trouve qu'on n'apprend pas assez des nouvelles personnes des équipes, mais surtout des juniors, des gens qui ont une moins grande expertise technique. On a du mal à intégrer ce qu'ils amènent dans les équipes en général, dans mon expérience en tout cas. Dans notre sujet, il y a aussi un sujet autour de ça, c'est-à-dire... Pour se remettre en question, c'est bien d'apprendre de gens qui ont une vie, que ce soit des sorties d'école, qui ont plein d'idées, qui savent mieux que tout le monde, ils sont un peu pénibles, mais ils savent effectivement plein de choses. Ou des personnes qui ne viennent pas de là, on a des tas de choses à apprendre d'un nouveau membre de l'équipe, au moins dans son questionnement. Parce que ça va être plus facile pour lui ou elle de poser des questions, pourquoi vous avez fait ça de cette manière-là.
La question naïve est toujours un super indicateur. c'est un bon thermomètre je comprends pas pourquoi vous avez fait ça et des fois tu te retrouves à devoir expliquer et des fois tu peux pas parce que tu sais plus et du coup il y a eu un problème de passation de connaissances et des fois, moi ça m'est arrivé de me sentir con en me disant ouais c'était vrai il y a un an et demi quand on a fait ce choix mais ça n'a plus aucun sens maintenant alors que la question était naïve sans chercher à attaquer ça, enfin factuellement ça arrive Et j'aime bien ces parties de questions naïves qu'il faut savoir prendre avec toute la bienveillance possible. Pas faire... Il n'y a pas le temps. Éviter ce travers-là qu'on peut avoir des fois quand on a des fois une hiérarchie qui ne nous laisse pas le temps. C'est pour ça que quand on prend des juniors, c'est bien de laisser le temps aux seniors de s'en occuper. En général c'est la base, si tu fais pas ça il va y avoir une autre problématique, ça c'est un autre axe, une autre problématique de justement de gestion d'équipe prendre des juniors parce que ça coûte pas cher c'est pas une fin en soi tu prends des juniors parce que tu donnes le temps aux seniors de s'en occuper, de les faire monter en compétences, de leur expliquer tout ce qu'il y a à savoir et de transmettre et de gérer aussi le bus factor puisque ça doit venir avec ça sans pour autant les formater Et là, c'est dur.
Mais du coup, l'inverse aussi. Je trouve qu'il faut laisser le temps au senior d'apprendre. Oui,
c'est ce dont je parle dans ma conf, moi, sur la posture d'humilité. De considérer que même si c'est un junior, tu peux apprendre des choses de cette personne et donc vraiment remettre en question ta position pour lui laisser la place de s'exprimer. Parce que c'est en faisant du père avec des juniors que des fois tu apprends des trucs de fou.
Il y a un dernier point qui me faisait question, où en vrai je suis curieux de voir votre talk une fois tout terminé. La première fois que vous en avez parlé, vous me parliez de... un peu de gestion du legacy humain, et des techniques de refacto. Moi, je sais plus ou moins refactorer du code, je vais typer des trucs, je vais encapsuler des comportements, je vais extraire des méthodes, j'ai plein de trucs à faire. J'ai potentiellement... Enfin, j'imagine des trucs, mais j'ai un peu de mal à voir jusqu'où on peut faire des parallèles comme ça sur de l'humain. Vous avez commencé à lister des choses qui s'y prêtent bien, et d'autres pas du tout.
je veux du spoil la métaphore la plus facile c'est la mais c'est plus pour la blague c'est la refonte from scratch où du coup tu tu changes d'équipe pour refaire le produit le parallèle chez les humains c'est tu changes l'équipe tu vires tout le monde tu prends des nouveaux et tu refais et le parallèle il s'étend un peu parce que personnellement c'est pas quelque chose que je trouve qui marche bien de repartir de zéro sur un logiciel et en même temps ça marche pas non plus sur les équipes c'est à dire virer tout le monde et recommencer t'as rien appris du coup de ce que t'as fait la première fois et c'est aussi vrai sur le code voilà Après, pour le reste, on a un peu commencé, mais en même temps, on ne veut pas déshumaniser non plus. C'est-à-dire qu'il y a la blague, c'est marrant, de considérer le Human Legacy comme le Code Legacy. En même temps, on n'est pas non plus là pour... On en a parlé un petit peu, pour montrer du doigt, dire que le Dev Legacy, c'est mal, c'est vous, c'est de votre faute, personnellement, etc. Donc il faut quand même arriver à trouver des parallèles qui... qui à la fois sont pertinents et ne sont pas des parallèles de dictateurs. Donc on y travaille, on aimerait bien que ça fonctionne, mais faudrait voir ce que ça donne quand même.
Et l'idée c'est de l'introduire aussi dans la forme, sur un truc un peu plus type discussion entre Léa et moi, comme on pourrait avoir en buvant une bière, où on pourrait discuter de ces parallèles-là sans vraiment que ça ait un impact dans ce qu'on fait au quotidien. C'est aussi le fait de... Quand on parle de refonte ou de Strangler Fig pour appliquer à des humains, tu peux très bien imaginer ton étranglé des développeurs, mais c'est pas... C'est parce qu'on veut que les gens retenaient de la con. C'est juste pour faire des blagues aussi.
Tu peux redéfinir le Strangler Fig ? Je pense pas que tout le monde qui écoutera ça connaît le pattern.
Le Strangler Fig, c'est un pattern de gestion du legacy sur lequel tu vas... Pour des nouvelles features, mettre... t'isoler complètement de tes interactions avec ton... Oh, isoler, non. Mettre une couche de... d'ACL. Ah, j'ai perdu le... Anticorruption. Anticorruption, je ne sais pas pourquoi je ne l'avais plus. Une couche d'anticorruption à chacune de tes interactions avec le Legacy, pour être complètement isolé de son comportement et avoir aucun effet de bord dû à son fonctionnement. Et au fur et à mesure... tu vas pouvoir faire comme le palmiétrangleur, le figuierétrangleur, grappiller un peu ton legacy, le sortir, ses responsabilités, les mettre dans ton application qui finalement est développée avec des meilleures pratiques et mieux faites, et l'étouffer au fur et à mesure ton legacy pour que jamais il déborde sur ta refonte.
Mais tu vois, c'est... Comme on en a parlé là, je pense que c'est un peu ce qui se passait dans la startup dont je parlais. C'est-à-dire que les fondateurs et les gens qui avaient tout un tas d'idées, ils étaient entourés de, pas de gens qui les étranglent, mais de PO ou de devs qui comprenaient le besoin et agissaient un peu comme une couche anti-corruption, c'est-à-dire... décider, enfin DPO, DPM aussi d'ailleurs, adapter les idées pour en faire quelque chose qui servirait le produit tel qu'il est maintenant. Ce qui permettait à la fois de profiter de toutes ces idées et ne pas complètement refaire un Big Bang à chaque fois qu'il y avait une nouvelle idée géniale. Après, ce n'est pas extrêmement novateur. Il y a plein de gens qui font ça. Il paraît que c'est comme ça que Tesla gère Elon Musk.
Je ne sais pas comment il... Je ne veux pas... Je ne sais pas si j'ai envie de parler de ce mec-là.
On peut le.
Tu pourrais le couter. Mais force est de constater, oui, que je pense qu'il y a plein de choses qui, dans les boîtes d'Elon Musk et d'autres, il y a des équipes qui réussissent malgré leur hiérarchie. Et il y aurait peut-être beaucoup à prendre de ces équipes-là, très premier degré. Donc, il y a peut-être quelque chose à voir là-dedans. Ça fait un moment qu'on cause, du coup. Donc, sur le... Je sais pas par quel bout le prendre. Sur l'avancée de votre sujet, aujourd'hui, alors on a... En fait, on a... J'étais censé vous aider, tout ça, à avancer. En fait, on a juste brainstormé sur tout ce qui peut arriver. On a parlé du sujet, parce que moi, je dérive. Le sujet m'intéresse aussi éminemment, parce que c'est un des... Je pense que c'est un des... des plus gros points qu'on a dans notre métier, c'est de gérer l'existant. Vous, vous vous sentez comment pour, j'allais dire, pour continuer à avancer, à travailler sur ce sujet et pour revenir dans un mois ou deux pour le présenter tout fini, tout beau, tout prêt ?
Moi, je ne suis pas déçue parce que c'est toujours comme ça. J'ai une idée. Ensuite, il y a une phase d'expansion où déjà, il existe des choses. Donc, je vois... Je consomme du savoir. Je vois des vidéos, je lis des trucs. Et il y a un moment où je me dis Oh là là, mais il va me falloir 10 heures pour présenter tout ça parce que, bien sûr que c'est le nouveau framework de lecture du monde entier qui va révolutionner la tech. Après, on arrive à trouver la niche, le point particulier dont on a envie de parler, qu'on trouve intéressant, plus intéressant que le reste. plus facile ou qui va correspondre au format. Et du coup, je pense que de tout ce dont on a parlé, quand on aura fini de voir toutes nos sources et de re-brainstormer encore... Il y aura peut-être, si ça se trouve, rien dans le talk final. J'espère pas, mais...
Je ne pense pas.
Mais du coup, oui, là, on est en phase d'expansion de... Ah, ce sujet, il est lié à ça, qui est lié à ça, qui est lié à ça. Et après, il y aura une phase de concentration.
Oui, clairement.
Moi, j'aimerais beaucoup, pour l'auditoire qui est toujours là, essayer des... des remarques, des souhaits d'activer plus là-dessus. Je trouverais ça intéressant au moment où je vais le publier sur les réseaux, qu'il puisse y avoir des discussions en dessous, je trouverais ça très très cool. Parce que le sujet est justement à hyper basse, comme tu dis. Il y a des sources qui vont de partout, il y a du vécu je pense qu'il y a à prendre en compte. J'aime bien avoir des sources un peu... scientifique, je mets des gros guillemets en visuel, mais un peu... Ouais, avec de la data sourcée. J'aime bien ce type de données qui a en général plus de poids, mais du vécu d'une personne, d'une deuxième, d'une troisième, des fois ça donne des bons axes de lecture et de recherche. Donc moi je trouverais ça intéressant.
Oui, j'allais rebondir sur ce que disait Léa, pour dire qu'on était clairement au début de notre travail et que... Pour l'instant, on a orienté notre talk tel qu'on te l'a présenté, mais on n'est pas sûr qu'il ressemblera à ça à la fin. Et pour le moment, dans le taf qu'on a fait, on essaye d'en sortir un abstract pour pouvoir soumettre, pour pouvoir bénéficier des jours de création de contenu Shodo. Et il faudra venir voir le talk, parce qu'en plus, tu pourras apprécier les illustrations de Eve.
C'est presque une private joke. Du coup, Eve a fait des illustrations pour plusieurs tools qui ont à chaque fois plutôt bien marché. Donc, ça sera avec grand plaisir. S'il y a des gens qui ont envie de discuter avec vous de ça, Léa, t'as au moins un réseau, t'es au moins sur LinkedIn, je crois. Tu es contactable ?
Je suis sur LinkedIn, je m'appelle Léa Coston et on me voit parfois dans les meet-ups lyonnais.
Ok. Yann, je sais pas si t'as... Beaucoup de réseaux, c'est visible.
Alors moi malheureusement je n'ai pas beaucoup de réseaux, donc c'est plus dur de me contacter comme ça. Après vous pouvez dénicher ma première conf et récupérer mon adresse mail perso si vous voulez vraiment me contacter absolument. Mais sinon vous pouvez passer par Léa, je pense qu'elle me fera parvenir les messages. Et sinon oui je traite dans les meetups lyonnais, particulièrement celui des crafters, le meetup Python et LyonJS de temps à autre. Au plaisir de s'y croiser.
Eh bien, merci à tous les deux d'être venus. Ça me fait un épisode qui sort un peu de l'ordinaire. Ça faisait une discussion autant sur le fond que sur la forme, j'aime bien. J'ai vraiment bien envie que vous repassiez quand le sujet sera plus sec. Quitte à vous donner des idées dans la discussion pour faire des suites. parce que je pense que ça peut appeler des suites donc encore une fois merci d'être venu et puis quant à vous, quant à toi cher auditoire, auditeur, auditrice qui nous a écouté jusqu'ici il me reste à te souhaiter une excellente fin de semaine à la prochaine pour un nouvel épisode et d'ici là, geekez bien et codez bien
Share
Embed
You may also like