Retour sur SC London 2019 – Jour 2

Les 3 et 4 octobre derniers j’ai eu la chance de participer à la conférence SC London 2019. Dans la première partie de cet article j’ai partagé avec vous mes découvertes, surprises et coups de cœur de la première journée de conférences. C’est parti pour le second jour !

Pour bien commencer cette dernière journée de conférence j’ai choisi de retourner au London Bridge Breakfast Club pour un bon petit-déjeuner car j’ai beaucoup apprécié le lieu et la gentillesse du personnel. Les pancakes étaient vraiment délicieux, ça ne gâche rien ! 😀

Feedback loops for software delivery

Pour cette première présentation de la journée, Gojko Adzic, inventeur de l’Impact Mapping et auteur de Specification by example, a décidé de nous parler de l’importance du Feedback.

Gojko commence par rappeler ce qu’est une boucle de Feedback et l’importance qu’elle revêt dans une démarche agile (« a loop without feedback is just running in circles! »). Il prend l’exemple du Blue-Green Deployment qui permet de faire des expériences, et de réagir si le résultat obtenu n’est pas à la hauteur du résultat espéré. Si le nombre de commandes chute brusquement après une mise en production, il est sans doute plus sage de revenir à la version précédente. Il est intéressant de noter qu’ici on parle bien de mesurer l’impact « business » !

Gojko pose la question suivante à l’assistance : « Est-ce que le TDD produit de bons designs ? ». Il nous indique ensuite que l’intérêt du TDD n’est pas tant de produire de bons designs que de nous éloigner de mauvais designs. TDD ne fait que fournir le cadre qui nous permet de prendre en compte le Feedback que les tests nous apportent. Ce sont les Actions que nous prenons ensuite qui peuvent nous conduire à améliorer nos designs.

Feedback without an action is not a loop! It’s bad news.

Gojko Adzic

Gojko insiste aussi sur le fait qu’il ne faut surtout pas lier le Feedback à une Récompense. En effet les individus chercheraient alors à optimiser les chances d’obtenir la récompense, au détriment de l’objectif collectif (« People are good at tailoring their behavior to things they are measured against »).

Pour obtenir un bon Feedback « mesurer la bonne chose, d’une bonne façon » est essentiel, mais que mesurer ? Comment ? Gojko nous propose plusieurs pistes :

• Utiliser des Tests A/B en production
• Surveiller les erreurs côté client avec des outils comme Sentry, TrackJS ou Rollbar
• Observer des utilisateurs interagir avec nos produits et discuter avec eux !

Gojko conclue sa présentation en nous invitant à faire évoluer notre façon de penser pour distinguer ce qui est « impossible » de ce qui est « jugé trop coûteux » mais qui pourrait nous aider à prendre de meilleures décisions. #BusinessValue

TDD with Petri nets

Aslak Hellesøy, l’inventeur de Cucumber, a quant à lui décidé de nous faire découvrir les réseaux de Petri et propose de nous montrer comment cet outil de modélisation, traditionnellement associé au Big-Design Up-Front, peut en fait être utilisé dans une démarche TDD. #noBPMN

Un réseau de Petri permet de représenter de manière très concise des processus complexes. Aslak prend d’abord l’exemple du jeu du Morpion (« Tic-Tac-Toe »). Une représentation de ce jeu très simple sous forme de machine à états nécessite entre 765 et 19 683 états selon la méthode de calcul choisie. Sa représentation sous forme de réseau de Petri (ci-dessous) ne nécessite qu’une quarantaine d’éléments.

Aslak nous montre ensuite comment modéliser un processus assez simple : l’utilisation d’une machine à rayons X dans une clinique. La clinique possède une salle d’attente et une salle d’examen. Un patient entre dans la salle d’examen après avoir attendu son tour dans la salle d’attente et sort de la clinique une fois l’examen terminé.

Nous découvrons alors le code du projet. Aslak ajoute un test et nous fait constater que notre premier modèle est trop simple : il ne prend pas en compte le fait que la salle d’examen ne devrait pas accepter plus d’un patient à la fois ! Il modifie alors le modèle et les tests pour tenir compte de cette contrainte, et relance les tests. Nous n’avons pas modifié le code, les tests échouent donc toujours, mais les exécuter a permis de mettre à jour la représentation du modèle sous forme de GIF animé ! 🤯

J’ai trouvé cette approche particulièrement intéressante, c’était la première fois que je la découvrais. Aslak nous a dit s’être inspiré du livre Living documentation: a low effort approach to documentation, always-up-to-date, inspired by Domain-Driven-Design de Cyrille Martraire.

What has Machine Learning got to do with it?

Frances Buontempo s’intéresse à la question de savoir s’il existe un lien entre Software Craftsmanship et Machine Learning.

Frances commence par rappeler les origines du Machine Learning. Le terme a été inventé en 1959 par Arthur Samuel et désigne initialement le fait d’apprendre à des machines à jouer dans le but de développer des tactiques adaptées à la résolution de problèmes plus généraux. On retrouve déjà les notions de fonction d’évaluation et d’itération qui sont toujours utilisées de nos jours !

Frances souligne ensuite que si nous associons aujourd’hui très souvent Big Data et Machine Learning, ce dernier n’a pas toujours besoin de s’appuyer sur d’énormes échantillons de données. Elle nous invite à réfléchir aux données à partir desquelles nous pourrions apprendre du code sur lequel nous travaillons et cite l’excellent Your code as a Crime Scene d’Adam Tornhill qui permet de tirer une mine d’informations de votre historique Git ou SVN. #code-maat

Frances nous questionne alors sur ce qu’implique la notion même d’apprentissage et sur la capacité des machines à réellement « apprendre ». Elle évoque ensuite un futur possible où les machines pourront devenir créatrices de musique, d’articles de journaux et, pourquoi pas, de code ?

Frances a décidé de mettre cette théorie à l’épreuve. Vous connaissez probablement le kata FizzBuzz, parfois utilisé lors d’entretiens de recrutement. Il s’agit d’un exercice très simple où le candidat doit développer un programme qui affiche différents résultats en fonction du nombre qui lui est passé en paramètre. La difficulté réside ici dans le fait que le « candidat » est une machine !

Après plusieurs jours de calculs, la machine a effectivement produit un programme capable de répondre à l’énoncé. Frances nous a brièvement montré le code généré et le moins que l’on puisse dire c’est que le résultat est difficilement intelligible et ne reflète absolument pas la simplicité du problème ! 😱 Ce n’est toutefois pas surprenant dans la mesure où la machine s’est contentée de répondre au besoin exprimé par les tests ; on ne lui a jamais décrit ce qu’est un code maintenable et aucun test ne portait sur cet aspect.

Pour Frances, il est primordial que des êtres humains soient impliqués dans l’apprentissage des machines et puissent les guider. Grâce à des techniques comme le Mutation Testing, le Property-Based Testing ou le Fuzzing la machine peut également nous aider à améliorer notre code. C’est finalement ce qui rapproche Machine Learning et Software Craftsmanship : expérimenter, recueillir du Feedback, apprendre de ses erreurs et itérer !

Balancing forces in Software Design

Mashooq Badar, co-fondateur de Codurance et pilier de la communauté londonienne, nous a proposé de nous intéresser aux différentes forces qui interviennent lors du développement d’un logiciel.

Sa présentation a été inspirée par le livre Notes on the synthesis of the form de Christopher Alexander, paru en 1964 et qui traitait d’architecture, de design, mais pas de logiciel. Le sujet de l’équilibre des forces lors de la conception n’est donc pas nouveau, mais il reste diablement intéressant !

Mashooq nous propose de nous intéresser davantage au Problème que nous cherchons à résoudre qu’aux Solutions que nous pouvons imaginer. C’est en effet du Problème que vient la complexité essentielle. C’est cette complexité essentielle que nos Solutions, devront adresser. Et elles devraient le faire en n’introduisant que le minimum de complexité accidentelle, qui n’a pas de lien avec le Problème car elle n’est liée qu’aux outils que nous choisissons.

Mashooq nous invite à analyser nos Problèmes, à les découper, à identifier et isoler les différentes forces qui tirailleront nos designs, de sorte à pouvoir les adresser. Pour ce faire, il commence par prendre un exemple simple : la conception d’une bouilloire électrique. Il applique ensuite la même démarche à un site marchand.

J’ai beaucoup apprécié l’accent mis sur l’analyse, la nécessité de comprendre le Problème de manière holistique, d’identifier les compromis qui doivent être faits, les raisons qui ont conduit à prendre telle ou telle décision. #ProblemAnalysis

Panel discussion: Bridging the gap between Business & I.T.

Lors de cette discussion ouverte les différents speakers de la journée se sont intéressés au fossé qui sépare souvent Développeurs et personnes du Métier. Les échanges étaient très intéressants.

Les suggestions des speakers n’auront dans l’ensemble rien de surprenant pour les personnes les plus rodées à l’Agilité mais elles restent pleines de bon sens :

• Créer de la collaboration
• Se concentrer sur les résultats #outcome
• Éliminer les incompréhensions

Une anecdote au sujet de la compréhension du besoin m’a particulièrement marquée : une société de publicité en ligne avait démarré une longue et coûteuse refonte de son système d’information, car elle voulait pouvoir mesurer l’impact des espaces publicitaires « en temps réel ». En questionnant les utilisateurs, il s’est avéré que le système existant ne leur convenait pas car il ne permettait de mesurer cet impact que tous les mois alors qu’ils souhaitaient faire des analyses « en temps réel ». On leur a donc proposé de réduire cet intervalle à deux semaines, puis une semaine, mais cela n’était toujours pas assez précis. On a enfin proposé de réduire l’intervalle à une journée et l’utilisateur présent s’est alors exclamé : « c’est exactement ce que je veux, une journée, c’est du temps réel ! ». 🤯 La société a alors pu arrêter le coûteux projet de refonte et il lui a suffi de changer la configuration du système en place pour déclencher les analyses existantes tous les jours plutôt que tous les mois.

Si l’anecdote ci-dessus insiste sur notre responsabilité de comprendre la finalité du travail demandé et pas seulement de proposer des solutions technico-techniques, j’ai également beaucoup apprécié l’idée de ne pas s’interdire de faire certaines choses au seul motif d’un coût élevé : « The fact that it is difficult (expensive) shouldn’t disqualify it ».

Lors de l’échange, un des participants a mentionné un talk de Dan North & Martin Fowler qui permet d’aller plus loin : The yawning crevasse of doom. N’hésitez pas à y jeter un œil, c’est très intéressant.

Microservices: sharing is caring

Rachel Davies nous a présenté TES, la société pour laquelle elle travaille, et plus particulièrement les choix d’organisation et d’architecture qui leur permettent de remplir leur mission : fournir des services autour de l’Éducation.

Voici ce que je retiens de sa présentation :

• Le Télétravail est la règle chez TES, pas l’exception. Cela fonctionne car les personnes sont organisées en petites équipes (3 personnes) et que TES privilégie les modes de communication ouverts comme les channels Slack.
• Les micro-services de TES utilisent une stack technique homogène: NodeJS, React, REST & RabbitMQ
• Chez TES il n’y a pas de Business Analysts ni de Testeurs ! Comprendre le besoin et tester l’application sont la responsabilité des Développeurs
• Chez TES le leadership est distribué, il n’y a pas de « Chefs de Projet » mais des « Parents de Projet »
• TES suit un processus de développement léger et agile #noestimates
• On parle beaucoup aujourd’hui de « User eXperience » ou UX, TES s’intéresse également à la DX ou « Developer eXperience», notamment par l’importance accordée au fait d’aider les autres et la mise en place de Mentoring entre collègues, mais aussi des outils comme une bibliothèque de styles et composants prêts à utiliser.

Software contracts or: How I learned to stop worrying and love releasing

Dans les applications que nous développons, il est fréquent d’avoir recours à des bouchons, aussi appelés mocks, pour pouvoir tester nos composants de manière indépendante de leurs dépendances. Les équipes en charge de ces tests de collaboration sont très souvent différentes de celles en charge des composants dont nous dépendons réellement et doivent faire des hypothèses sur leur fonctionnement, la plus répandue étant qu’ils se comportent de manière identique aux bouchons. Les contrats d’interface évoluant dans le temps, ce n’est malheureusement pas toujours le cas : ce qui était vrai à un instant t, ne l’est plus nécessairement à l’instant t+1. Seb Rose, a décidé de nous parler de Contract Tests, et de la façon dont ils peuvent nous aider à adresser cette problématique.

Un contract test vise à rendre explicites les hypothèses que nous prenons vis-à-vis de nos dépendances, en considérant par exemple les plages de valeur autorisées, le comportement en cas d’erreur, etc. En pratique cela se manifeste par une classe abstraite qui documentera le Contrat d’interface sous forme de tests et deux implémentations de cette classe : l’une teste le composant réel, l’autre le bouchon. Nous sommes alors en mesure de détecter des décalages entre les deux implémentations.

En matière de contrat d’interface deux manières différentes de travailler existent : soit le Producteur spécifie le contrat (Producer-driven contracts), soit les Consommateurs le font (Consumer-driven contracts). Seb choisit de consacrer le reste de la présentation à l’approche Consumer-Driven en s’appuyant sur l’outil Pact et plus particulièrement Pact-Broker. #consumer-driven-contracts

Pact est un outil qui permet d’exprimer un contrat ou « pacte » entre Producteurs et Consommateurs mais aussi et surtout les moyens de vérifier que chaque partie adhère au contrat indépendamment l’une de l’autre : à chaque version, les Consommateurs publient des exemples représentatifs de l’utilisation qu’ils font du composant dans Pact-Broker ; tandis que les Producteurs vont y récupérer ces exemples et les utiliser pour valider leur implémentation. Il est alors possible d’utiliser la fonctionnalité can-i-deploy de Pact pour connaître la matrice de compatibilité entre versions et savoir immédiatement s’il est possible de déployer sans problème ! 🤯

Socio-Technical Practice as Craft

Michael Feathers, a conclu ces deux jours de conférence en nous invitant à nous intéresser aux aspects sociaux du développement logiciel et à leur relation avec le code que nous produisons.

Michael part d’un exemple de problème de coordination entre équipes qu’il a rencontré chez un client et en profite pour introduire la loi de Conway : « les organisations produisent des systèmes dont la structure reflète leurs propres schémas de communication ». Il nous invite alors à nous intéresser à la dynamique des relations en cause dans son exemple plutôt que de chercher une solution au problème.

Il poursuit en évoquant les effets d’échelle (« Galileo’s Scaling Law ») : le volume d’un objet croît plus vite (O(n²)) que sa surface (O(n³)). Passé un certain seuil, certaines structures ne sont plus appropriées et doivent s’adapter. En termes de code, plus la taille d’un composant augmente et plus la probabilité que ce dernier respecte le principe de responsabilité unique diminue rapidement. En termes sociaux, une organisation qui fonctionne pour une équipe de 5 personnes ne sera peut-être pas appropriée pour une équipe de 50 personnes et sans doute encore moins pour une équipe de 500 personnes.

Un Système résulte toujours de la rencontre entre des Personnes, des Outils et du Code. Il est intéressant d’étudier l’impact avant d’introduire de nouveaux éléments sur ces axes : que se passerait-il si on ajoutait 20 nouvelles Personnes ? 20 nouveaux Outils ? 200 000 nouvelles lignes de Code ? Michael nous invite à prendre conscience des conséquences des choix que nous faisons, en termes de forces en présence, d’interactions entre les différents acteurs, humains ou non. Il évoque Bruno Latour et le modèle Acteur-Réseau – qui ne fait pas non plus la distinction entre personnes et objets – et étend le postulat de Frederick Brooks : non seulement « ajouter des personnes à un projet en retard aggrave le retard » mais peut-être n’est-ce pas uniquement vrai pour les Personnes.

Michael nous invite même à aller plus loin – à contre-courant des pratiques actuelles de passage à l’échelle – et à tenter de passer à l’échelle inférieure (« scaling down ») : il évoque l’article Powers of Two qui explique l’intérêt d’équipes composée d’exactement deux développeurs ! #PairProgramming

Enfin, Michael conclue sa présentation – et la conférence – en nous présentant ce qu’il appelle un « Book of Form ». C’est un travail en cours dans lequel il tente de définir des patterns récurrents de structure ou de comportement qui sont transposables dans différents contextes, qu’ils soient physiques, sociologiques, ou logiciels. Comme tout pattern, ils sont nommés, mais Michael a fait le choix d’inventer leurs noms plutôt que de reprendre des termes existants. Vous pouvez ainsi chercher : Exot, Endot, Duon, Odon, Tojon, Parzo, Neaq… J’ai trouvé cette démarche extrêmement intéressante et j’ai hâte de lire ses prochains billets sur le sujet.

J’ai vraiment beaucoup apprécié cette conférence. J’en suis sorti fatigué par le voyage et les journées très soutenues mais grandi : j’ai énormément appris. Je m’attendais à ce que mon séjour soit riche en découvertes, mais pas à ce point ! Vivement la prochaine ! 🤩