Rencontre avec l’un des pionniers du TDD en France – Thomas Pierrain
César – « Thomas bonjour, ravi de pouvoir faire ce Podcast avec toi
Thomas – Merci à toi, plaisir partagé.
C – On s ‘était rencontré il y a quelques années aux NCrafts, tu avais pu donner une conférence et j’avais été impressionné par ton background et tout ce que tu mets en place au quotidien. Le plus simple serait que tu puisses nous parler un peu et nous raconter ton parcours
Ça fait plus de 20 ans que je fais du développement logiciel pour vivre. J’ai commencé à mettre les pieds dans le web avant que la première bulle internet n’explose. C’était dans les années 98/2000, ça date un peu (rires). Ensuite, j’ai travaillé dans des Web Agency dans lesquelles c’était un peu la ‘demmerde’ et question développeurs ce n’était pas top.
Ensuite je suis entré dans une société de service dans laquelle j’ai appris le métier. J’ai fait un peu de forfait, de la régie ; J’ai appris pas mal de choses. Il y a eu des petits trucs avec la boîte, c’était compliqué, j’ai fait un peu de service puis j’ai rejoint la Société Générale Onbound Investissement complètement par hasard puisque je voulais faire de l’XP. Je suis finalement resté 12 ans. Durant ces années j’ai fait pas mal de chose : tech lead, dev, architecte, j’ai même fait de l’architecture d’entreprise.
Depuis 2017, j’ai créé ma structure avec Bruno Boucard : 42Skillz pour développer différemment avec des gens qui ont une vision différente. Je ne fais pas vraiment de coaching dans le sens où les gens l’entende, je fais partie des équipes. Là, je gère une équipe de 5 personnes pour un groupe hôtelier un peu plus de la moitié de mes semaines. Le temps qu’il me reste est axé sur le conseil et l’information pour mes autres clients.
C – Ça me fait déjà penser à plein de questions que j’ai envie de te poser. Quelque chose qui a dû être structurant ce sont tes 12 ans au sein de la Société Générale, peut-être avant de parler de ça, revenons sur ce que tu as dit sur tes premières expériences dans le service avec ce qui pouvait être du forfait ou de la régie. Est-ce que tu as vu une vraie différence entre ce que tu as vécu toi sur ces parties-là ?
A l’époque, et je ne sais pas si ça a vraiment changé, j’ai eu un entretien d’embauche assez cool, et on m’a dit “c’est bon tu es embauché”. On m’a envoyé dès le premier jour en régie, pour France Télécom Multimédia & Jeux. C’était une plateforme de mise en relation de joueurs sur Internet. Je débarque dans une équipe et je suis pris en charge par un des gars de ma boîte, Sébastien, qui m’accueille et qui est présent sur la mission depuis plusieurs mois et qui fait partie des murs.
Il m’explique le fonctionnement et je me suis vraiment senti bien. Le mode régie me plaisait bien, et comme j’étais assez autonome, et que je comprenais les enjeux, on m’a souvent confié de faire des outils, des quiz, des outils de tournoi, des modules presque autonomes.
Finalement, au bout d’un certain temps en régie, le directeur technique avait demandé des propositions pour évoluer. Je suis donc revenu dans la boîte au moment où ont commencé les forfaits. Je n’étais déjà pas fort en estimation, mais j’avais envie de plaire à l’époque, donc je n’osais pas dire non. Mes estimations étaient bien souvent trop optimistes…
Au début j’étais seul, puis on s’est retrouvé à 2, puis à 3. Je me suis rendu compte que c’était intense. Soit j’avais mal estimé, soit il fallait bosser comme des fous, c’était assez stressant. Là je me suis dit “il doit me manquer un truc, ce n’est pas possible. Sois-je n’ai pas ce qu’il faut pour la gestion de projet, ça ne peut pas être aussi fatiguant et stressant que ça de faire du soft… Je dois mal m’y prendre.”
C – Parce que vous étiez en mode Scrum et que t’avais des exigences en termes de livraison ?
Non, à l’époque c’était plus à l’arrache. Je débutais et faisais mes gammes. Ce qui m’intéressais le plus c’était l’architecture et le design. J’adorais le travail d’équipe mais tout ce qui était préparer, planifier et toute la partie pilotage ce n’était pas mon truc. Je ne savais pas comment m’y prendre, ni comment demander de l’aide. Au bout de quelques mois, voire quelques années, il s’est passé un truc dans la boîte pour laquelle je bossais qui s’est retrouvé en cessation de paiement. C’était une situation un peu compliquée. J’en ai profité pour me dire que c’était le moment de repartir en formation pour définir plus clairement ce qu’est la gestion de projet.
J’ai fait le tour des formations et j’en ai trouvé une qui était pas mal, et qui permettait de faire de la gestion de projet. J’ai fait ça 6 à 8 mois. Je me demandais “est-ce que je suis nul parce que je n’aime pas ça ou est-ce qu’il me manque quelque chose de théorique ?”
J’ai eu la réponse à la fin de la formation, c’est vraiment parce que je n’aime pas ça (Rires). Ça m’a aidé par la suite. Souvent, en tant que développeur, on est balloté de missions en mission, on nous propose à chaque fois des setups que l’on ne peut pas refuser, etc. J’avais pas mal de collègues dans le même cas que moi. Il fallait être opportuniste, et pas forcément faire les choses parce qu’on avait envie de les faire.
Quand je suis arrivé à la Société Générale, ça les a fait marrer quand je leur ai dit dès les entretiens d’embauche que je ne voulais pas être chef de projet, malgré le fait que j’en avait un peu sur mon CV…
C – Donc ils se sont dit : ‘c’est bien, c’est un techos, il va rester dans la technique, ça nous plait’ ?
Là les devs et les techs leads c’est exactement ce qu’ils se sont dit, et les manager se sont demandé quel animal j’étais. Eux voyaient ça comme une promotion.
C – C’était l’évolution naturelle oui.
Oui, c’est la chenille développeur qui se transforme en papillon chef de projet, c’est ce qu’on nous a vendu durant des années. Moi je leur ai dit que ce qui m’intéressait vraiment c’était l’aspect technique, quitte à aller vers l’architecture mais pas de gestion de projet.
C’est ce qui m’a permis de garder ce cap-là durant toutes les années à la SG ou on essayait régulièrement de me confier des responsabilités de ce type. Autant, sur le management d’équipe, j’adorais et j’étais à l’aise ; Autant sur le pilotage, pas vraiment.
On faisait souvent des duos avec des gens, et partout où j’ai pu bosser avec des personnes qui étaient eux dans le pilotage et moi orienté équipe, ça s’est très bien passé. Je n’ai pas regretté mon choix. En sommes, je m’en suis un peu servi comme un bilan de compétences.
C – Ok, et du coup, est-ce dès ce moment-là que tu t’es intéressé aux bonnes pratiques et à la qualité de code ?
J’étais plutôt axé sur du design orienté objet de mon côté, mais c’était léger. En réalité, je pense que j’avais le syndrome de l’imposteur à fond. J’apprenais le métier, ce qu’était le multithreading, ce qu’était un gestionnaire de conf, comment travailler correctement en équipe. Des bases.
Je suis resté à la fac, mais seulement 2 ans sur une formation informatique. Je pouvais faire de l’assembleur et plein d’autres choses, mais j’avais encore de grosses lacunes.
Du coup, quand j’ai fini ma formation, je me suis dit “ok, je ne veux pas être pilote projet, je vais plutôt me diriger vers l’aspect technique. Bon, je fais quoi ?”
Et, comme j’avais bien glandé à la fac (rires) – enfin je faisais plus de musique que de maths – j’ai tenté une validation des acquis par l’expérience (VAE) pour avoir des équivalences de diplômes qui pouvaient me manquer pour ma recherche d’emploi. Je n’avais aucun diplôme d’ingénierie. Donc j’ai fait ça et j’ai vu que je pouvais faire coïncider une seconde formation plus technique. À l’époque c’était JAVA, JEE et .NET. C’était la naissance de .NET. La formation durait 6 à 8 mois, et avec cette formation plus un mémoire j’avais l’équivalent d’une licence.
J’ai donc entamé les démarches dans le but de me faire moins “croquer” par les RH. Du coup, c’est lors de cette deuxième formation .NET, architecture distribuée, Java, que j’ai rencontré un type qui était dingue. Jean Baptiste Defard. Le matin on avait des cours sur Merise avec un prof à l’ancienne, même si ça faisait longtemps que tout le monde aurait dû arrêter de faire du Merise qui était une vieille méthode de travail française du ministère de l’industrie.
Et l’après-midi on avait JB Defard qui avait une chemise hawaïenne et qui nous parlait d’XP, d’agilité, qui nous expliquait pourquoi Merise c’était de la m****. Ce qu’on apprenait le matin était détricoté l’après-midi.
CESAR – Lui en faisait déjà avec des clients ? Avait sa société ? Comment ça se structurait dans ce qu’il vous racontait ?
Alors, à l’époque JB Defard était médecin, il avait fait des études de médecine et il a toujours fait de l’informatique à côté. Il s’éclatait plus en informatique et il passait son temps à monter des équipes de développeurs en XP, pour bosser aux quatre coins du monde. Il passait son temps à monter et lancer ses équipes avec des jeunes développeurs. En mode indépendant.
Il avait ce côté un peu cool mais grande gueule. Il était passionnant parce qu’il n’y avait aucune passivité, il fallait lui poser des questions, qu’on réagisse pour que ça avance. Impossible de rester assoupi dans ses cours. Il était pertinent et utilisait énormément le storytelling. Ça a fait écho sur plein de choses chez moi et c’est là que j’ai vraiment découvert l’XP.
C – Qu’est-ce que tu peux dire sur l’XP ? Souvent on fait référence au fait de faire de l’XP en Pair Programming, mais comment ça résonnait à l’époque pour toi ?
Je me disais que ça avait l’air moderne, exigeant, pointu. Et surtout ça me parlait ce qu’il disait. J’avais envie de bosser comme ça. Entre ces cours et ce que je lisais à côté, je me suis vite orienté vers cette façon de travailler. A l’époque j’ai pris XP en voyant surtout le côté pratique avec : le client sur site, le TDD, le Pair Programming, etc. Ça m’intriguait parce que je n’en avais pas encore fait beaucoup. C’est bien après avoir pratiqué durant de nombreuses années que j’ai vu ce que c’était pour moi. C’est à dire une révolution sociale au sens ou dans l’XP tout est fait pour l’équipe et pour bonifier et rendre performante cette même équipe. C’est vraiment un changement de modèle total.
Quand on fait de l’eXtrem Programming c’est plus que faire des pratiques XP. Tu peux toutes les faire sans pour autant faire de l’XP. Si chacun bosse dans son coin, si tu omets le binômage, si tout n’est pas fait pour optimiser le travail en équipe, alors c’est raté. Et le travail en équipe ce n’est pas que de l’efficacité, c’est surtout qu’on va pouvoir bénéficier de l’entraide entre nous. C’est vraiment cet aspect de confort psychologique et rassurant qui permet à tout le monde de progresser vachement plus vite que quand il y a deux trois personnes qui ont le syndrome de l’imposteur à côté d’une superstar. L’XP est fait pour porter un ensemble et pas uniquement des individualités.
C – Finalement tu parles de l’eXtrem Programming d’il y a quelques années. Est-ce que à l’époque c’était contre les tendances ? Tu pratiques depuis un certain temps mais étais-tu déjà à contre-courant à cette époque et comment ça s’est matérialisé ?
Une fois que j’ai fini ma formation, j’ai un ancien collègue qui m’a proposé du boulot pour faire du forfait avec lui. J’ai commencé par ça et dans cette société de service j’ai essayé de vendre de l’XP mais c’était chaud. J’avais créé une communauté qui tentait de pousser toutes les nouvelles pratiques, mais c’était compliqué. Il n’y avait que les passionnés comme nous qui arrivions à en faire un peu. Ce n’est pas les alcooliques anonymes, mais on était peu, on se rejoignait de temps en temps. C’était il y a longtemps maintenant (rires).
Mais oui, j’étais à contre-courant et je n’arrivais pas à trouver une boîte ou je pouvais faire du XP. Donc la SOGE était finalement la seule solution. Je suis arrivé par hasard, mais comme c’est ce que je voulais faire, c’était parti ! J’ai commencé à en faire vraiment en 2005 lors de mon entrée à la Société Générale. On était la première équipe à faire de l’XP en France à cette époque.
Après, c’est vrai que se retrouver à contre-courant c’est un truc qui m’est arrivé à plusieurs reprises. De me rendre compte que par rapport aux pratiques By-The-Book, très souvent au bout d’un certain temps je n’étais pas satisfait. C’était super d’apprendre la pratique et de le faire, mais j’avais toujours cette impression de ne pas être à l’aise et de pousser les murs. Dans ma carrière ça m’est arrivé avec le TDD et l’histoire de la pyramide de tests. Pour moi, c’est vraiment un truc trop foireux (la pyramide. NDLR) qui induit les gens en erreur depuis des générations et des générations, ça ne me plaisait vraiment pas.
Quand tu es entre experts tu peux te dire que si on lit la pyramide d’une certaine façon ça peut faire du sens, mais 80% des gens ne comprennent pas vraiment ce que ça veut dire.
C – Tu as eu ce besoin et sentiment où un moment donné tu t’es dit “parce que je le pratique tous les jours, je me rends compte que ce qu’on vend dans le bouquin ce n’est pas ma réalité et je vais me poser les questions pour faire en sorte que cette pratique ne soit pas dénuée de sens” ?
Qu’elle soit comprise au moins. C’est un peu ça le pattern. A l’époque on discutait avec Arnaud Lemaire et Bruno Boucard (son associé. NDLR), et on a émis l’idée de sortir un bouquin sur notre retour d’expérience et nos pratiques. On s ‘est dit, on va l’appeler “No Cargo”.
Le Cargo Cult c’est reproduire des choses sans comprendre pourquoi. Pour moi, la pyramide c’est ce qui génère des générations de cargo cult. Je l’ai vu dans énormément de contextes et de missions différentes. Un autre moment, c’est sur l’architecture hexagonale, ça fait des années que je pratique en prod et que j’essayais de le promouvoir ce pattern que j’aime bien. En général les gens testent uniquement la partie métier (l’hexagone), et se mette un peu ‘à la couture’ de la partie métier en début et sortie et substitut la partie adapteur qui passe du métier à la partie technique.
Je me suis rendu compte après de nombreuses expériences qu’on avait toujours des petits bugs de m*** dans les adaptateurs qui n’étaient pas couverts par nos tests d’acceptation. Les tests d’intégration en revanche, il y avait toujours des bugs. Ok, on faisait le minimum syndical à cause du biais d’optimisme relatif aux développeurs. On n’a pas de difficulté à écrire des tests sur des situations qui se passent bien, mais tous les trucs tordus il faut déjà se faire plus violence. J’ai donc remarqué que les gens, régulièrement, en mettant en production, oubliaient des choses. Il manquait des trucs, donc bien que nos tests passent tous au vert, ce n’était jamais vraiment qualitatif.
Je me suis qu’on allait changer. Après plusieurs expérimentations, je me suis rendu compte que ce qui nous plaisait bien c’était les tests d’acceptation dans lesquels on intègre les adaptateurs. Ceux qui font le lien entre le métier et le reste ; on ne fait pas d’IO, de réseau ou de disque, on veut des tests rapides. On va aller stuber à l’extrême limite des adaptateurs. On repousse les murs de ce qu’on va aller tester. Et ça, les gens quand tu leur en parles la première fois…. Entre ceux qui n’en ont pas vraiment fait et ceux qui en ont fait plein, ceux qui bossent seuls, il y a toujours quelqu’un pour penser que tu ne connais pas.
A chaque fois dans des équipes avec des expériences différentes chez chaque développeur, il y a toujours des moments où ça fuit. Ce qui m’intéresse c’est le travail collectif. D’où l’intérêt d’ailleurs de l’XP. Du coup, je souhaitais mettre en place des pratiques qui conviennent à tout le monde quel que soit le niveau d’expertise de l’équipe.
Pareil pour le BDD ! Mon associé, Bruno, à monter le Meetup BDD Paris. Au début, il m’a demandé un coup de main, mais ça ne me bottait pas plus que ça. J’y voyais des choses intéressantes, mais payer le coup de la traduction en Gerkin était hyper fastidieux. Je ne connaissais pas de situations réussies où on a écrit des scénarios Given, When, Then. Les gens du métier s’en fiche généralement, mais même s’ils aiment, ils préfèrent que le développeur les rédige, puis ils relisent.
J’en ai fait avec Specflow, du Cucumber, sur différents projets, et j’ai remarqué que l’adaptation pour brancher des tests en Given When Then sur notre code test n’en valait pas la chandelle puisque finalement il y avait très peu de gens côté métier qui voulaient jouer le jeu. Je préférais écrire des tests de développeurs orientés métier plutôt que perdre du temps là-dessus.
Il m’a dit de l’accompagner, et m’a conduit vers l’Example Mapping. Et en discutant avec la communauté londonienne de Cucumber, j’ai vu qu’ils avaient repackagé le BDD il y a quelques années.
Il y a désormais 3 étapes : l’exploration (pour capturer le besoin), la formulation (comment je passe de la compréhension de besoin à la traduction), et l’automatisation (comment j’automatise et je branche mes Given, When, Then, sur mon code).
Autant la première partie m’intéresse, autant les deux autres…
C – Est-ce que finalement l’Agile qui a été inventé par des Devs et repris par des chefs de projets, n’a pas été un cargo cult et trop utilisé By-The-Book ? Est-ce qu’aujourd’hui il n’y a pas un vrai culte autour du Scrum, de l’estimation et de l’agilité ?
Si. Pour moi, Scrum et Agile c’était le cargo cult par excellence pendant des années. Pendant des années, j’ai eu des armées de gens qui venaient m’expliquer comment faire de l’agile, alors qu’on était plus agile en faisant de l’XP que leur version de Scrum pourrie qu’ils nous proposaient.
Il y a eu un moment où j’en ai eu marre. Partout où je vois écris Agile depuis 8/10 ans, je fuis… Parce que souvent c’est du cargo cult.
C – Le Scrum master certifié qui vient t’apprendre ton métier…
Ça fait des années que je ne supporte plus Scrum. Les gens disent toujours “ce n’est pas la faute de Scrum”, c’est la faute des gens qui le font mal. Sans déconner, quand il y a autant de coïncidences, au bout d’un moment ce n’est plus du hasard.
Ne serait-ce que le terme de sprint déjà…. Dans XP, il y a une autre pratique appelée le Sustainable PACE (le rythme soutenable) ; C’est le fait de dire que si tu veux avancer, faut être capable d’avancer longtemps. C’est plus un marathon qu’une course le développement logiciel. Il faut savoir maintenir son énergie pour rester efficace, et surtout ne pas être toujours au taquet ou proche burn-out, prendre du temps avec sa famille et ses amis, faire autre chose. C’est souvent quand tu fais autre chose que tu as de bonnes idées. A l’époque c’était quand même assez révolutionnaire.
Avec Scrum, et je l’ai vu dans plein d’endroits et notamment Londres, Hong-Kong et Paris, tous les gens comprennent la même chose : courir. Tout était fait pour aller vite et à chaque fois je voyais le même pattern qui était : on démarre “from scratch”, le métier est content on lui montre des démos, ça refactore quasiment jamais, les techniques d’ingénierie logicielles sont quasi inexistantes. Au bout d’un moment c’est comme si l’équipe avait un gros élastique dans le dos, et plus on avance plus c’est difficile de continuer. C’est normal après avoir accumulé autant de dettes techniques. Les démos sont de plus en plus pourries et le business commence à s’inquiéter. C’est une machine à perdre…
C – Oui parce qu’ils voient la vélocité baisser. Tu ne penses pas qu’il y a eu une OPA de la part du métier, voire des responsables qui n’avaient pas mis les pieds dans le développement, et qui a un moment donné l’ont vu comme une forme de micro-management et d’hyper-contrôle en disant : “vous allez me coder de la feature, et on check la vélocité et le nombre de features que vous produisez” ?
T – Les grandes structures elles adorent les KPI’s. Tu arrives avec des KPI’s vélocités, ça plait forcément à ceux qui font de la gestion et pilotage de projet. Ça plait à certains manager qui veulent le contrôle.
C – C’est un peu le serpent qui se mord la queue puisque souvent les budgets sont décidés à l’année et les contraintes budgétaires s’affilient à des deadlines. Ils obligent donc à produire telle ou telle chose à telle date, et donc il y a cette contrainte de temps qu’il faut respecter. Et forcément, c’est au détriment de la qualité.
T – Exactement, dans la ligne droite d’XP j’ai plus pratiqué du Kanban, du travail en flux. D’ailleurs le client pour lequel je travaille actuellement, sur l’équipe API que j’ai pris en main, au début tout le monde travaillait en Scrum avec des sprints puisque le côté Front faisait la même chose.
Je leur ai vite suggéré une migration en flux, puisque le métier changeait d’avis régulièrement donc pourquoi ne pas accepter de faire autre chose si on n’a pas déjà commencé la tâche suivante. Si le métier a envie que ça change, pourquoi pas. Il faut s’adapter.
Là ou dans Scrum tu as ce fameux Sprint, et tout ce que tu as négocié dans ce cadre-là tu n’en bouges plus.
C – Rien que la terminologie… Sprint tu ne peux pas être sur un effort de long terme. Quand tu fais un sprint tu es censé faire un 100m ou 200m sur plusieurs années ce n’est pas possible.
T – C’est l’épuisement dont je parlais tout à l’heure. C’est ce terme, cette sémantique qui génère des erreurs et du cargo cult. Il y a très peu de gens qui cherchent véritablement à comprendre ce qu’il y a derrière les mots.
Honnêtement, Scrum je pense qu’il n’y a rien à racheter. Je l’ai vu même par des gens qui aimaient ça et qui pensaient faire bien… Je n’ai pas vu la même efficacité, la même agilité, souplesse, que ce que l’on a quand on fait du XP, du Kanban ou du flux.
Souvent, côté IT, il y a des structures qui se disent que Scrum est une protection vis-à-vis du métier qui est indécis. Pour éviter de tricoter et détricoter, ils se mettent des cadences. Quand on est là, c’est qu’il y a un problème déjà côté métier.
C – Il y a un désalignement complet entre le métier et l’équipe dev.
T – Exactement. En fait, tu vas cacher sous le tapis la merde organisationnelle, les dysfonctionnements. Je préfère la version où on a un feedback qui nous fait nous rendre compte des dysfonctionnements. On fait des rétros, on en parle, on voit ce qu’on peut faire et on essaye de faire bouger les choses pour que les problèmes structurels changent. Sinon on répète toujours les mêmes erreurs et ça génère du cynisme puisque les développeurs ne sont pas dupes.
Toute la terminologie de Scrum/Agile(tm) est mauvaise. Attention, parfois il y a des gens bien attentionnés, mais à 80% j’ai perdu mon temps sur Scrum.
C – Et sur le TDD. Comment tu as intégré cette pratique ?
T – J’y suis venu par le projet de 2005 à la SG, avec Bruno Boucard, qui était à l’époque l’architecte et qui avait réussi à convaincre le métier de faire le premier projet XP. On était 5 sur le projet, et on binômait. J’ai dû faire toutes les erreurs possibles et imaginables que tu peux faire avec le TDD, genre tester des méthodes privées, avoir des tests trop orientés implémentation et pas assez comportements, avoir une granularité trop fine, faire des tests de méthodes…. J’ai appris sur le tas, j’ai lu le bouquin de Ken Beck sur le TDD que les autres connaissaient déjà. Ils avaient été formés par quelqu’un avant sur toutes les pratiques. Moi j’arrivai, j’avais lu le livre mais sans plus. Le TDD, j’avais essayé d’en faire un peu tout seul mais c’est plus dur.
Ça a été la confrontation sur le terrain, sur des problématiques complexes. Ça s’est fait collectivement. J’ai tellement aimé ça qu’après j’ai eu des phases durant laquelle je voulais en mettre partout, tout le temps. Je ne savais pas vraiment où m’arrêter.
C – Tu es devenu obsessionnel du sujet et tu voulais prêcher la bonne parole
T – J’avais l’impression en plus d’avoir tout compris, et que c’était exactement comme ça qu’il fallait faire. Quand ce premier projet s’est bien déroulé, ils ont fini par nous éclater et nous sommes tous partis évangéliser autour de cette expérience.
C – Tu me parles souvent de cette dynamique d’équipe, mais collectivement vous êtes devenus véloces à quel moment sur le TDD ?
T – On est devenu véloces assez rapidement, notamment parce que l’équipe était constituée en majorité de seniors, et de gens vraiment expérimentés et bons. J’ai débarqué dans une équipe de personnes dont je lisais les bouquins. C’était l’époque de l’âge d’or un peu, j’étais entouré de talents et il y avait une vraie émulation via des formations, etc.
J’ai eu à nouveau le syndrome de l’imposteur en arrivant là-bas en voyant le niveau affiché.
C – En te disant que tu étais le plus junior, le moins expérimenté parmi des gens qui ont déjà rédigés des livres et fait leurs preuves ?
T – C’est ça. On faisait du multithreading et moi j’avais uniquement fait le BA.BA quasiment 4 ans avant. C’était des applications orientées Low-Latency. Beaucoup d’enjeux de complexités. On faisait de la programmation réactive et événementielle en 2005 c’était notre quotidien. Je passais d’un monde d’applications de gestion qui comprenaient leurs propres bases de données, ses écrans, dans des services qui se connectent à plein de données marché, qui font plein de calculs, qui impliquent des choses, qui prennent des décisions, le tout sous les 5 millisecondes. Par hyper orienté latence mais exigent, avec des problématiques de parallélisme.
J’avais beaucoup de complexité à cette époque à digérer autant d’informations en plus de la partie XP. L’XP au final m’apportait des moments de répit par rapport à la complexité par ailleurs sur le projet, et de mon sentiment d’être un peu un imposteur. L’équipe était mortelle donc petit à petit j’ai pris mes marques.
Quand je suis arrivé sur l’autre projet, qu’on nous a éclaté, on était déjà sur une dynamique positive et on m’a dit : “tu vas t’occuper d’un pricer pour des obligations, (un système qui calcule des prix en permanence), soit quasiment 40 000 réponses par seconde. On était une équipe de 8 dans laquelle j’étais un peu le capitaine TDD, le tech-lead.
On est tombé dans un premier gros piège. On avait écrit beaucoup, beaucoup de tests, mais que des tests d’implémentations. On ne testait pas la grosse boîte qui était le pricer, on testait chaque classe, chaque méthode. Ce qui fait que quand tu voulais changer le design (et ça nous est arrivé régulièrement), tu pétais 100, 150 tests…
Tu pouvais un peu les refactorer mais c’était hyper fastidieux puisqu’il fallait se replonger sur chaque contexte. Ça nous ralentissait. Y’avait un mec dans l’équipe qui n’étais pas convaincu de l’approche Test-Driven-Development depuis le début et qui a sauté sur l’occasion pour critiquer ouvertement. A cette époque on s’était réuni pour en discuter et réfléchir sur la suite à donner. J’étais avec des gens supers, et on a trouvé collectivement en diagnostiquant nos erreurs. On ne pensait pas que ce soit le TDD qui était la mauvaise approche, mais plutôt notre façon de faire qui n’était pas correcte. Il fallait repenser nos tests pour en améliorer la solidité.
A chaque fois dans le TDD il y a des épreuves à surmonter.
C – C’Est-ce qui t’as fait poser des questions et a amené ton côté “no-cargo cult”, se poser les bonnes questions pour déterminer ton approche à toi ?
T – C’est d’autant plus vrai avec un truc que tu aimes vraiment. Avec une passion, tu vas pardonner 2, 3 approximations etc. Cette difficulté-là te pousse à bien démonter le mécanisme, comprendre ce qui se joue, qu’est ce qui est bien fait ou non ? Le TDD se fait par palier. Là, pendant 3-4 ans j’ai bien galéré à travers mon plaisir. Ensuite, je me suis senti de plus en plus à l’aise, j’ai pris des habitudes pendant 2-3 ans avant de les casser ensuite.
Ça doit faire une quinzaine d’années que je fais du TDD, et peut-être 8 que j’ai trouvé un style qui me plaît bien et qui fonctionne avec l’ensemble des équipes pour lesquelles je travaille.
C – On parle souvent de Sandro Mancuso ou d’Uncle Bob, tu te rapproches plutôt de quel style aujourd’hui ? C’est intéressant que tu parles de cette évolution-là, tu t’es posé les questions et tu n’es plus dans le test ultra-granulaire que tu vas forcément casser, mais tu t’approches de quoi aujourd’hui ?
T – Aujourd’hui, le style que je pratique, on lui a donné un nom : l’Outside Diamond. Le diamant c’est pour remplacer la pyramide. C’est un diamant découpé en plusieurs étages : tout en bas, très fins et très étroits ce sont les tests unitaires grain-fins. Ensuite, les tests d’acceptations (mon sujet, l’étude, mon service, mon appli) et les contre-tests qu’on rédige par centaines. Ils doivent être rapides. Là on est au centre du diamant, avec la zone la plus large. Puis viennent les tests d’intégration et de contrat. C’est bien d ‘avoir des tests qui vont vite, mais il faut d’autres types de tests pour vérifier l’assemblage. Puis vient la phase d’exploration.
En gros c’est pour se dire : qu’est-ce qu’on fait comme type de tests plus fréquemment ? Et l’ ”outsiding” c’est sur le Workflow. C’est à dire que quand je bosse, je le fais toujours depuis l’extérieur. Il y a différentes approches. L’approche classistes c’est partir du centre et sédimenter le système vers l’extérieur, c’est pour ça qu’on parle d’Insight Out. J’en ai fait beaucoup au début (c’était notamment la version Ken Beck), et je me suis rendu compte que je n’étais pas suffisamment fort pour arriver pile poil où il fallait arriver à la fin. Je me suis posé des questions et je suis tombé sur un livre qui parlait du ‘style de l’ombre’ et qui disait : “je parle de l’extérieur et je vais décrire les comportements attendus”. Quand j’écris un test d’acceptation rouge, pour le mettre au vert il faut cheminer un peu, je vais donc faire plein de petits tests unitaires grains-fins qu’on appelle la double boucle.
Je me suis rendu compte dans un second temps que j’adorais l’Outsiding façon Londres, mais je n’aimais pas le côté Mockiste, et l’utilisation intensive de Mocks contre l’implémentation interne. Dans leur style tu substitut des éléments qui n’existent pas encore ; Alors que finalement dans ma version finale d’Outside Diamond, les simulacres ne vont se substituer qu’à des choses extérieurs (API, Base de données). L’intérieur de mon compte par contre je ne vais jamais le stuber dans mon style.
C – L’outside Diamond, c’est quoi pour toi ? Une sorte de variante de l’approche londonienne ? C’est une évolution, elle est soutenue par d’autres personnes où c’est quelque chose que vous testez encore ?
T – C’est dans la lignée du style de Londres mais sans le côté mockiste. Ça vient avec d’autres caractéristiques surtout. Finalement il y a peu de gens qui font véritablement du TDD aujourd’hui. Il fallait que je trouve un moyen d’expliquer ce que je fais. On a d’abord cherché un nom qui était accrocheur. J’ai fait une présentation sur DDD Africa (en ligne sur YouTube) qui explique les motivations et le style. Je me suis dit que j’allais accompagner cette présentation d’autres choses, donc je me suis lancé sur une série d’articles de blog.
Le premier est sur le ‘Why’ et le second est sur le ‘How’. L’un de mes intérêts principaux serait d’en parler plus largement avec d’autres gens qui le pratique. Je trouve que sur ce sujet on est trop cargo cult. C’est à dire que la plupart des gens rencontrés suivaient soit la version de Kent Beck, soit la version du BOSE mais sans vraiment dissocier le côté mock.
J’ai commencé à avoir quelques contacts qui se montrent intéressés par cette approche mais c’est vraiment très récent.
C – Donc de converger vers une sorte de variante parisienne ?
T – Je ne sais pas si ça va être très inclusif de la nommer ‘parisienne’ (rires). En tout cas ça fait longtemps que je veux en parler, ça doit bien faire 4 ans que je soumets ça à différents CFP, différentes conférences. Ce sujet-là n’est jamais retenu. Peut-être que je le vends mal après tout. Mon objectif restant de le promouvoir un peu plus. Pourquoi ? Parce que ça enlève du stress aux équipes, ça détend. On tombe moins dans les pièges. J’ai vu le bien que ça apportait sur les gens avec qui je bosse : des débutant.es, des plus expérimenté.es.
C – Aujourd’hui, quand tu rencontres des jeunes développeur.ses, tu les vois sensibilisés aux bonnes pratiques ? Quelles sont les recommandations que tu pourrais leur faire concernant l’ensemble de ces approches et méthodes ?
T – Ce serait d’essayer de comprendre ce qu’ils font. Un autre cargo cult que je peux observer c’est que 80% des équipes de développeurs que j’ai croisé pratiquent une façon de travailler proche de celle de l’Open-Source. C’est-à-dire que quand tu fais de l’Open Source tu ne connais pas les gens avec qui tu vas bosser. Tu vas donc essayer d’éviter que n’importe qui débarque et te détruise ton code, change des choses de manière trop profonde. Tu vas donc avoir des pull request, des revues de code, des dialogues. C’est un mode totalement asynchrone.
Tout ce workflow-là a été calqué sans réfléchir dans énormément de boîtes. Il fut une période où c’était cool de faire “comme de l’Open-Source”. Dans les façons de travailler, je vois très souvent des gens qui bossent côte à côte mais communique via Slack ou Pull Request au lieu de se parler, de faire de l’intégration continue ou du binômage.
C – Donc pour toi ce serait 2 choses. La première étant de se poser des questions, et la seconde d’instaurer une communication et un dialogue efficace au sein de l’équipe. Au-delà du Pair Programming y’a vraiment une notion d’échange ?
T – Carrément, parce que quand tu bosses avec quelqu’un mais que plutôt que se parler tu t’écris, c’est dommage, il y a une perte de temps. On est très introverti dans le développement, on est plus à même de rédiger que de discuter. Les codes reviews deviennent donc indispensables vu que les gens ne font pas de binômages.
Chez un de mes clients, j’ai débarqué et j’ai l’impression d’être au bureau de la SECU. Dans un monde un peu kafkaïen ou il n’y a que du contexte. Donc sois-tu fais ta feature sans véritablement de feedback. Le feedback arrive toujours au pire moment, à la fin, quand c’est trop tard. Travailler chacun en silo c’est une prise de risque inutile.
Si tu es une petite équipe de devs, n’utilise pas les techniques qui sont designés pour des situations où tu ne peux pas faire confiance aux autres.
Le Pair Programming, c’est comme du code review mais au bon moment ! Et ça te fait gagner du temps. Quand on pair ou qu’on mob, la code review peut être faite dans un second temps. On peut pousser le code en prod avant.
C- C’est une sorte de Trunk Base Development ?
T – Ah mais c’est ça oui. Si tu fais des branches tu ne fais pas d’intégration continue. Bon ça c’est la version hardcore de la vision. J’ai arrêté de le dire parce que finalement ce n’est pas compris.
C – Tu parlais de ce que tu étais en train de mettre en place dans l’équipe. Tu gères 5 personnes et tu es passé en flux. Qu’est-ce que tu as pu insuffler à l’équipe et quel était leur degré d’acceptation par rapport aux remarques ? Comment le changement s’est fait ?
T – Dans le passé j’ai souvent été tech lead et manager d’équipe avec un peu de leadership. Il m’est arrivé parfois de tomber sur des os. Le Change Management c’est un sujet qui m’intéresse vraiment parce que j’ai été confronté à pas mal de problèmes. Là c’est la première fois où j’ai procédé un peu différemment. Quand je suis arrivé, j’étais déjà assez serein puisque le groupe était de qualité. Il n’y a pas de personnalité toxique et c’est la première fois que je vois ça depuis très longtemps. Il y a un tech lead qui est très fort, en front en back, en archi, c’est un vrai plaisir de travailler avec lui.
La contrepartie c’est que les autres sont totalement inhibés par le tech-lead, puisque tout passe par lui. Quand je suis arrivé j’ai trouvé ça un peu gênant. Les autres managers me voyaient arriver avec leurs sourcils froncés et qui étaient inquiets. Je me suis dit qu’il ne fallait pas tout révolutionner d’un coup, s’eut-été trop risqué.
C – Malgré toi, tu fais de la politique. Aujourd’hui tu es obligé d’arriver avec des notions de changements et de faire du Change Management de façon délicate pour que ce soit accepté ?
T – Tu es obligé, sinon tu te fais dégager ou tu te fais bouffer très rapidement. La situation risque vite de se détériorer. Pendant très longtemps j’étais naïf et je pensais que si tu étais bon et que tu travaillais beaucoup ça suffisait. Mes nombreuses années dans une banque d’investissement m’ont montré que le Change Management était hyper important. Tu peux proposer un truc génial mais si tu as un ennemi ou deux dans la boîte, ce sera très difficile à faire passer.
J’ai 46 balais, je suis forcément moins naïf qu’avant. Mais sur cette dernière mission dont je te parle, je suis resté en retrait pendant 2 mois et demi, j’observais. Je proposais mon aide mais sans être forcément révolutionnaire. Dans ma tête en revanche c’était plus sûr, il fallait que ça change. Il fallait que j’émancipe mes deux devs Back pour qu’ils sortent de la dépendance de notre tech lead. Ils ne font pas de tests, ils ne font pas de TDD, il faut les sensibiliser à ça etc.
Au bout de 2 mois et demi, j’ai agi. Je leur ai dit qu’il fallait raisonner en tant qu’équipe, et qu’on mette en place des process à même de construire ça. Je leur ai demandé ce qui pouvait nous mener à cette unité. Workshop, on se met dans une salle pendant 2heures, je récolte les besoins de chacun et ça fini par revenir vers moi. Je me suis donc exprimé en leur expliquant que j’aimerai partir vers du Continuous Delivery, que j’adorerais qu’on puisse – sans avoir à passer par le tech lead – passer du code en prod plusieurs fois par jour sans que ce soit exceptionnel. J’adorerais faire du TDD et être détendu, ne pas faire de la QA manuelle et des tests d’intégration à gogo. Je leur ai demandé si ça les tentait, ils étaient positifs.
En les sollicitant, je cherche à les rendre plus autonomes, sans réfléchir à leur place. Petit à petit, et à force de suggestions, on a commencé à écrire des tests, puis à structurer le code. On a fait quelques sessions de Mob, du white board. Au début ça fonctionnait comme ça, en progressant sur le TDD, l’architecture hexagonale, des smock tests, l’utilisation de faiseurs.
Je voulais qu’ils voient d’eux-mêmes vers où aller et les diriger tendrement vers l’Outside Diamond que la majorité de l’équipe pratique désormais. Maintenant c’est l’équipe qui s’auto-gère.
C – Et ça, il a fallu à peu près combien de temps pour arriver à les rendre autonomes ?
T – Ça a été difficile parce que je n’aime pas le silence par exemple. Sur certains daily, si les gens ne prennent pas la parole, j’occupais la place en prenant en main l’animation. Au bout d’un moment il a bien fallu que je les responsabilise sur ces parties là aussi afin qu’ils déterminent eux-mêmes ce qui fonctionne ou non. Je montrais trop la direction, je leur ai donc demandé d’animer le board. Déjà parce que c’est énergivore. Donc on a lancé une sorte de daily tournant, ou chacun devra prendre la parole.
Tous les jours, quelqu’un est “on duty” et elle gère l’animation du board le matin mais aussi celui qui va gérer les relations avec tout le monde. Au début tout le monde courrait comme des poulets sans têtes, parce que les PO allaient directement taper sur Slack en privé à tel ou tel dev. Là aussi il fallait instaurer cet esprit d’équipe, que chacun puisse avancer sur le projet sans être terrorisé en reprenant le travail de quelqu’un d’absent.
C – Que chacun puisse prendre sa place dans l’équipe.
T – Exactement. La question que je leur ai posée c’était : ‘comment on peut faire ça ?’ Et la réponse a été de faire tourner les rôles. Il y aura un mode guichet, celui qui s’en occupe est celui qui supervise la prod, qui redispatche derrière les tâches de chacun.
C’est plein de petites pratiques comme ça qui font atteindre l’objectif de l’intégration continue. On s’était donné 6 mois pour arriver.
C – A peu près 6 mois pour être autonome, ou en tout cas arriver à pousser de la CI
T – Avec la Covid, le temps partiel, je dirais 6 à 8 mois. Aussi d’ailleurs parce qu’il y avait une culture qui était très forte lorsque je suis arrivé.
C – Y’avait les process, y’avait la manière de faire, et tu sentais que le changement ne serait pas simple ?
T – C’était presque accepté. La souffrance était intériorisée. Quand tu en discutes après avec eux, ils se rendent compte que ce n’était pas bon avant. Quand je les ai dirigés vers un nouveau processus avec mes petites marottes : TDD, architecture hexagonale, des ateliers, ils ont accepté très rapidement.
C’est progressif mais finalement l’équipe apporte beaucoup à tout le monde. J’ai beaucoup de plaisir à bosser avec eux.
C – Quand tu fais de la qualité, que tu es dans un climat où finalement tout le monde bosse en remote, qu’est-ce que ça change dans cette montée en compétence ? Dans cette prise d’autonomie autour de la qualité de code ? Et comment est-ce que tu vois ça aujourd’hui ?
T – Alors chez nous c’est particulier. Il y a une personne qui est arrivé 3 semaines avant le premier confinement, il y a donc quand même eu un minimum de relations interpersonnelles. Les gens se connaissaient de visu. Ils étaient fans de baby-foot et il y avait deux trois moments où les gens se rejoignaient, donc on n’est pas parti de rien. Ça a été un peu difficile au tout début, notamment parce que j’ai eu la Covid…
On s’était mis d’accord sur le design de notre board, on avait commencé à avancer, et tout à coup tu restes chez toi, ça a été un peu rude à mettre en place en distanciel. On a galéré surtout au niveau de la façon de travailler. Est-ce qu’on utilise Visual Studio Live ? Et finalement non, on a préféré faire des Git Push et toutes les 20 minutes ont se met un Mobster (petit chrono) pour éviter de trop ventouser le clavier. On s’échange, on se Pull, on se récupère le truc, on partage l’écran, etc.
Ça nous a pris du temps mais maintenant ça marche bien. Je faisais partie des sceptiques, moi qui adore travailler en équipe, et finalement l’efficacité est toujours présente, même loin les uns des autres.
On en revient au Sustainable Place, on avance par baby-step.
C – De vraiment faire en genre que les éléments soient validés avant d’en proposer d’autres, afin qu’il n’y ait pas de surcharge ?
T – Exactement, et y compris les katas ! On en refait depuis seulement quelques petits mois, et là c’est avec les PO, les autres développeurs front. On remarque une vraie demande et j’en ai été le premier surpris au niveau du succès. Ça se rechambre, ça se taquine, c’est agréable.
Avec des gens qui se connaissaient déjà avant finalement ça se passe relativement bien. Le truc qui me manque le plus, c’est le partage de caméra. J’ai essayé de montrer l’exemple en activant la mienne parce que j’aime voir les gens avec qui je communique… On est deux trois à le faire régulièrement mais ce n’est pas général. Y’a que les points One-to-One que je fais avec eux toutes les 3 semaines ou je leur demande vraiment d’activer la caméra, histoire de garder un lien physique.
Le volet non verbal, tous les petits signaux faibles que je distinguais avant me manque.
C – L’interpersonnel, le lien que tu peux créer.
T – Tout à fait. Là j’étais un peu frustré mais j’ai pris le pli. Le non verbal je le détecte au silence ou à une tonalité. On s’adapte, ça se passe bien. Je suis très agréablement surpris.
C – Comment est-ce que toi tu vois l’évolution du Crafts dans les prochaines années ? Dans le sens où tu penses que c’est une tendance qui va continuer à venir s’infuser dans toutes les équipes donc ça va devenir une forme de normes, ou tu penses que ça va être vampirisé comme l’a pu l’être l’agile by the book ?
T – J’en ai aucune idée (rire). Honnêtement je pense que tous les sujets que j’aime bien, la partie XP, l’Agilité, se sont un peu fait phagocyter par Scrum. Le DDD, qui est une autre de mes marottes, risque à termes de devenir le prochain Agile.
Honnêtement je n’arrive pas à voir. J’espère pouvoir continuer à prendre autant de plaisir que ça à développer du logiciel avec des gens, à comprendre le métier. Plus j’avance et plus je m’intéresse au volet métier. Tu vois dans l’hôtellerie je m’éclate comme un fou.
Il y a toujours eu des cycles entre les modes des gens du métier qui font un peu d’informatique et vice versa. Il y a rarement des choses nouvelles, on marche le plus souvent sur les épaules des géants. On redécouvre plus qu’on ne créé. Les langages fonctionnels, tout le monde ne jure que par ça aujourd’hui alors que ça existe depuis longtemps. »
MERCI BEAUCOUP à Thomas Pierrain pour son intervention et son partage d’expérience.
