On y est, notre dernier jour en tant que spectateurs d'une conférence d’ores et déjà incroyable ! Pour être tout à fait honnête, ce qui a fini de motiver notre participation est encore à venir puisque c'est la keynote de cette journée.

En échangeant avec les participants de DDD Europe 2020, nous (Anthony et Colin) savons que nous ne sommes pas les seuls à attendre avec impatience le passage sur la grande scène de Monsieur Kent Beck ! Pour rappel, le Monsieur est notamment :

• Le papa d'Extreme Programming ;
• Un des plus grands évangélisateurs du TDD ;
• L'auteur de SUNIT (premier framework de tests unitaires) ;
• Signataire du Manifeste pour le développement Agile de logiciels.

Ce que beaucoup considèrent déjà comme le Main Event va commencer ! Nous sommes cependant perplexes à la lecture du titre du talk : "Continued Learning: The Beauty of Maintenance".

Kent monte sur scène, il explique qu'il ne savait pas de quoi parler dans une conférence sur le DDD. Il a donc mis un titre très générique (et aucune description) pour sa présentation.

Son but était de parler avec les participants pendant les premiers jours et de décider des sujets qu'il allait aborder en fonction de ces discussions. Nous allons donc assister à une présentation sur mesure.

Pas de slides, un écran tactile et un speaker d'un niveau stratosphérique à l'humour décapant : le début de la fin de cette conférence s'annonce vraiment sous les meilleurs auspices.

Après une introduction expliquant, qu'à un an près, il aurait fait de la musique et non pas de l'informatique (car il a changé de spécialité chaque année à l'université en alternant musique et informatique), il commence la présentation du premier des 4 sujets qui seront abordés :

1. Comment gérer son stress lorsqu'on fait une présentation ;
2. Cohésion et couplage ;
3. Le retour du Waterfall ;
4. Une pensée pour la fin.

Comment gérer son stress lorsqu'on fait une présentation

Mr Beck décide de commencer par un sujet pas du tout technique. Il nous le présente comme venant d'une discussion qu'il a eue dans l'ascenseur le matin même :

- A guy: "Aren't you stressed for your talk?" ("N'êtes-vous pas stressé pour votre talk ?")
- Kent: "I wasn't, but, now that you ask me, I am!" ("Je ne l'étais pas, mais, maintenant que vous me le demandez, je le suis !")

Puis, il nous avoue immédiatement que, non, il n'a pas répondu ça même si ça pourrait être une réponse très marrante !

Il nous donne ensuite sa vraie réponse : en faisant référence à "A Soprano on Her Head", il nous explique comment il a appris à transformer le stress qu'il ressentait avant de monter sur scène :

"Quand vous êtes stressés, que vous avez peur, avant d'aller présenter quelque chose vous avez les mains moites, le coeur qui bat rapidement et du mal à respirer non ?

Bien, maintenant imaginez vous enfant, derrière la porte pour aller chercher les cadeaux de Noël. N'avez-vous pas les mains moites, le coeur qui bat rapidement et du mal à respirer ?

Etiez-vous stressé ? N'était-ce pas plutôt de l'excitation ?

Nous avons pris l'habitude d'associer ces sensations au stress, à la peur, des sentiments négatifs mais nous pouvons tout aussi bien les associer à de l'excitation !

Maintenant, quand on me demande si je suis stressé avant de monter sur scène je répond : "Non ! Je suis excité !""

Avec le recul, nous pouvons rapprocher ce premier sujet d'un bref échange que nous avons eu avec lui les jours précédents. Nous avions profité de quelques secondes de sa disponibilité pour le remercier de ce qu'il a fait pour notre profession. Sa réponse a été immédiate : il nous a conseillé d'enseigner, de partager les connaissances que nous avions acquises.

En commençant son intervention avec un moyen d'échanger plus simplement et en nous invitant à enseigner, il confirme l'importance qu'il accorde au partage.

Bien que ce premier sujet ait été présenté de main de maître, il s'avère que c'est un travail que nous avions déjà fait. Nous en sortons cependant avec une bien meilleure manière d'expliquer cette approche et nous sommes impatients d'attaquer les geeky stuff.

Cohésion et couplage

Pour ce sujet technique, Mr Beck a décidé de parler d'un sujet au combien commun dans notre profession : la cohésion et le couplage.

Son premier constat est qu'il pense que tout le monde ne partage pas la même définition de ces termes. Il rappelle donc la définition originelle du couplage définie dans Structured Design : Si A et B sont couplés, si on change A, on doit changer B.

Il explique ensuite qu'on voit parfois un couplage plus fort que ce qu'il n'est réellement. Par exemple, si un service renvoie A et B et que ce service est utilisé par un autre service qui est, lui-même, utilisé par un troisième service :

Si, dans le service 1, on veut changer A pour C (un nouvel attribut), on ne peut pas faire le changement en une fois car cela obligerait à synchroniser les changements. Il est cependant tout à fait possible de faire ce changement en plusieurs étapes. Tout d'abord, ajouter C dans le service 1 :

Puis consommer C dans le service 2 :

On peut alors consommer C et supprimer A dans le service 3 :

Puis supprimer A dans le service 1 :

Puis dans le service 2 pour arriver au résultat voulu initialement :

Il a échangé à de nombreuses reprises sur ce problème et cette approche et, selon lui, beaucoup de personnes ont du mal à accepter cette solution qui commence par empirer les choses. Il nous donne alors ce qu'il présente comme une leçon de vie : "Things always get worse before they get better!" ("Les choses empirent toujours avant de s'améliorer !").

Pour continuer sur le sujet du couplage, il nous donne une anecdote vécue pendant qu'il travaillait chez facebook : une mécanique de sauvegarde a été changée sur l'application A et la solution B est totalement tombée ! En fait, les deux applications étaient hébergées sur des serveurs distincts mais dans le même rack. Les nouvelles sauvegardes de A ont totalement saturées le switch, rendant B indisponible.

Le but de cet exemple tiré d'un cas réel était de mettre l'accent sur un fait essentiel : "The most expensive is the coupling you don't see" ("Le couplage le plus cher est le couplage que l'on ne voit pas"). En fait, le couplage que l'on peut voir sera relativement simple (et donc peu coûteux) à changer. A l'inverse, ce type de couplage tout à fait inattendu va coûter des fortunes en analyses et en reconception.

Ces rappels sur le couplage faits, il insiste sur l'importance du découplage : "Decoupling things reduces the cost of changing things over time because those changes then don't cascade and become big changes." ("Découpler les choses réduit le coût des changements dans le temps puisque les changements ne vont pas entraîner des modifications en cascade et devenir de gros changements.").

Une transition toute faite pour parler du coût d'une solution, il présente alors cette équation :  "Cost of a solution ≃ cost of change ≃ cost of Big change" en expliquant que le coût total d'une solution est, en fait, proche du coût des gros changements.

Pour affirmer cela, il se base sur le fait que l'on ne peut pas avoir de solution satisfaisante sans prise en main par les utilisateurs (ce n'est pas le papa d'XP pour rien :)). De fait, notre solution doit être en production et utilisable le plus rapidement possible. Il ne reste alors que des changements qui constitueraient 99% des coût d'un projet (il avoue avoir pris ce chiffre au hasard parce qu'il sonnait bien).

Découpler les choses devient alors essentiel pour éviter les gros changements : si on peut faire des changements sur des sous-ensembles sans affecter le reste de la solution, c'est tout de suite plus simple !

Ces explications sur le couplage faites, il est temps de passer à la cohésion avec ce schéma :

L'élément E est cohésif quand les éléments qui le composent sont couplés. Ok, donc, la cohésion (qui est une chose que l'on recherche) a besoin de couplage (qui est quelque chose que l'on veut éviter) !

Ce n'est pas tout à fait ça : la cohésion est un remède au mauvais couplage. Il est compliqué de découpler en cherchant simplement à découpler mais il est beaucoup plus simple de le faire en ajoutant de la cohésion. En changeant simultanément des éléments qui doivent effectivement changer en même temps, on n’aura pas les problèmes que pose le couplage.

Kent donne alors un exemple qu'il a vu chez l’un de ses étudiants : cet étudiant devait faire un refactoring de deux lignes de code. Il a :

• Extrait une méthode contenant ces deux lignes ;
• Fait la modification ;
• Remis les lignes de code dans la méthode originelle.

Mr Beck dit qu'il a commencé par le charrier en expliquant qu'il aurait tout aussi bien pu faire directement cette petite modification dans la première méthode. Puis, après réflexion, il dit s'être rendu compte que ce qui avait été fait était tout à fait logique : son étudiant a ajouté de la cohésion et supprimé du couplage (avec le reste du traitement) en créant cette méthode. Il savait alors que ces modifications n'affecteraient que cet élément cohésif.

Après cette explication sur l'importance de l'ajout de cohésion dans nos solutions, Kent propose un verbe pour cette action : "Cohesivating". Puis, après quelques secondes d'une salle pensive, il avoue espérer une application de la lois de Cunningham.

Cette loi explique que, si on veut une réponse à une question sur internet, le meilleur moyen n'est pas de poser la question mais de donner une mauvaise réponse, on verra alors rapidement apparaître plein de bonnes réponses.

Mr Beck dit qu'il connaissait d'abord cette loi sous le nom "the rule of Mcdonald's" : Si vous voulez aller au restaurant mais que personne n'a de bonne idée, suggérez Mcdonald's. Vous allez immédiatement avoir des dizaines de bien meilleures alternatives !

Voilà qui termine ce second sujet sur la cohésion et le couplage. Même si nous connaissons bien ces problématiques, nous trouvons ici beaucoup de nouvelles pistes de réflexions qui vont très certainement nous aider dans un avenir proche !

Le retour du Waterfall

Après les deux premiers sujets il ne reste que quelques minutes mais il tient quand même à parler encore de deux choses, la première étant le retour du Waterfall : "Waterfall is back, it's stopped apologizing, and it needs to be killed with fire !" ("Le waterfall est de retour, il ne s'excuse même plus et il doit être tué par le feu !").

Comme on peut s'y attendre de la part d'un des fondateurs de l'agilité, il ne croit pas au Waterfall et nous présente alors ce processus de fabrication de solutions informatiques :

Les idées génèrent des comportements. Ces mêmes comportements génèrent de nouvelles idées dans une boucle vertueuse tant que les idées structurent les comportements (et non pas l'inverse).

Pour appuyer son point de vue sur les dysfonctionnements du Waterfall, il imite un partisan de cette approche : "I have a big spec, what do you have? A bunch of testcases? Pfff!" ("J'ai une grosse spécification, qu'est-ce que tu as ? Un paquet de tests ? Pfff !"). Venant d'un des plus importants contributeur à la popularisation du TDD, le message est vraiment fort !

Toujours pour appuyer le fait que le Waterfall ne peut pas fonctionner il dit : "People use the word <organically> as some kind of pejorative. This codebase grew <organically>. I mean what is the other option you have to grow something?" ("Les gens utilisent le mot <organique> comme quelque chose de péjoratif. Ce code grandit de manière <organique>. Je veux dire, quelles sont les autres manières de faire grandir quelque chose ?").

Cette nécessité de répondre aux changements pour faire grandir une solution est définitivement entérinée avec : "Software made by carbon life forms... may grow organically" ("Des logiciels faits par des organismes à base de carbone… peuvent grandir de manière organique").

Malgré les très nombreuses punchlines que comporte cette partie, on sent bien que cette question l'affecte profondément ! Il nous explique alors que la communauté DDD est bien placée pour lutter contre cette recrudescence de Waterfall puisque la capacité à répondre aux changements est un des grands apports du DDD.

Le DDD demande aussi l'implication des experts métier pendant tout le processus de fabrication d'une solution. Les personnes présentes dans la pièce sont naturellement conscientes des dysfonctionnements des approches ne prenant pas en compte les retours au fil de l'eau.

Le but de ce troisième sujet n'était probablement pas d'expliquer les dysfonctionnements du Waterfall (même si ça a été fait avec brio) mais plutôt de nous faire prendre conscience du rôle que nous avions à jouer dans l'endiguement de cette épidémie.

En ce qui nous concerne, on peut dire que le message est clairement passé ! Et oui, pour nos collègues, ça veut dire qu'on va être encore plus pénibles qu'actuellement avec la fausse agilité… Et on n’est même pas désolé !

Une pensée pour la fin

Son dernier sujet concerne les changements dans les solutions : "Carefully separate structural change from behavior change [...] Behavioural changes can be irreversible while structural ones not. Which is the best for you to start from?" ("Séparez avec attention les changements de comportements des changements de structures [...] Les changements de comportements peuvent être irréversibles alors que les changements structuraux ne le sont pas. Quel est le meilleur point de départ pour vous ?").

Il conclut alors avec une phrase qui a rapidement fait le tour du Web : "Make the Change Easy Then Make the Easy Changes" ("Rendez les changements simples puis faites les changements simples").

En fait, cette phrase a tellement marqué les esprits que les organisateurs ont fait imprimer des stickers dans la journée !

Ainsi se conclut cette keynote drôle, inspirante et touchante. Nous en sortons avec plein de réflexions naissantes directement sur le contenu abordé ou sur la manière de présenter un sujet. Merci, Monsieur Kent Beck !