Jeudi 17 et vendredi 18 mai 2018 avait lieu à Paris la conférence NewCrafts, et j'y ai participé pour la 2e année consécutive.

C'est une conférence en anglais, sur le thème du développement logiciel. L'organisation est impeccable, les intervenant(e)s varié(e)s, pointu(e)s, et inspirant(e)s.

Il y a plusieurs tracks en parallèle, plus des ateliers, et aussi les discussions dans les couloirs, et c'est donc parfois difficile de choisir vers où suivre ses pieds.

La première journée, j'ai assisté à pas mal de présentations, alors que la deuxième j'avais plutôt envie de pratiquer avec du code, et j'ai donc privilégié des ateliers. Et pendant ces deux jours, les différents moments de pause ont été l'occasion de nombreuses discussions enrichissantes avec les autres participants !

Voici quelques notes sur des choses qui m'ont intéressé, surpris, amusé, ou encore questionné pendant ces deux jours.

Fighting the Invisible Enemy (Paul Rayner)

Ce qui va à l'encontre du flow dans nos processus de développement de produits, ce sont les queues invisibles qui se forment : par exemple, une fonctionnalité est développée mais en attente d'être testée ou déployée.

Les queues sont des indicateurs avancés (leading indicators), contrairement au débit (throughput) ou au temps de cycle (cycle time). Il est donc important de prendre conscience de ces queues, de les rendre visibles, et surtout d'agir rapidement et de manière décisive quand elles commencent à grossir, avant que les conséquences ne se manifestent de manière plus problématique au niveau de l'ensemble du système.

Paul Rayner a utilisé des modèles de traffic routier (http://traffic-simulation.de) pour illustrer de manière très parlante les comportements non linéaires qui apparaissent à la moindre perturbation dès lors que le système fonctionne à un niveau de capacité élevé.

Il nous a aussi montré un outil sur lequel il travaille, et qui s'appelle tout simplement Flow. Celui-ci extrait les données temporelles depuis Pivotal Tracker / Jira / etc. pour visualiser le temps passé par chaque ticket dans chaque étape, et mieux identifier les temps d'attente.

Cette approche visuelle m'a fait penser à un autre outil du Lean, le diagramme de flux cumulé (cumulative flow diagram).

Fighting the Invisible Enemy - Paul Rayner (NewCrafts 2018) from Paul Rayner

Feature Branching is Evil (Thierry de Pauw)

Thierry nous raconte son expérience en tant que consultant avec deux projets assez différents.

La première équipe était peu expérimentée, et n'utilisait auparavant aucun système de gestion de versions. Pour rester simple, il les a aidé à adopter Subversion : seulement deux gestes à apprendre (checkout, et commit), et pas de branches. Il avait pensé ça comme une première étape, mais en fait ça marchait pas mal.

La deuxième équipe était constituée de développeurs expérimentés, qui avait choisi d'utiliser git et le mode de fonctionnement "git flow". Lorsqu'il leur a suggéré d'arrêter les branches à longue durée de vie, il s'est heurté à une forte incompréhension :

• mais les branches nous permettent de travailler chacun de notre côté sans être perturbé par les changements des autres !
• mais les branches nous permettent de jeter un refactoring s'il ne va nulle part !
• mais les branches nous permettent de contrôler la qualité de ce qu'on livre (via une revue de code pre-merge)
• mais les branches nous permettent de contrôler quelles fonctionnalités on livre (on ne merge que quand on veut livrer)

Dans sa présentation, Thierry a abordé :

• les inconvénients des branches à longue durée de vie :
  • elles retardent le feedback,
  • elles retardent l'intégration,
  • elles cachent le travail du reste de l'équipe et réduisent la communication,
  • elles découragent le refactoring,
  • elles créent du stock (au sens du Lean),
  • elles augmentent le risque,
  • elles créent du travail supplémentaire (brancher, rebaser, merger…),
• les avantages du trunk-based development :
  • commits plus fréquents sur master → builds plus fréquents → déploiements plus fréquents → time-to-market réduit → expérimentation plus facile
  • builds plus fréquents → les problèmes sont détectés plus tôt → la qualité est améliorée
• comment faire du trunk-based development :
  • l'application est toujours prête à être livrée sur la branche principale,
  • découper les gros changements en petits morceaux incrémentaux,
  • garder cachées les nouvelles fonctionnalités non terminées,
  • utiliser la technique "branch by abstraction" pour les gros refactorings,
  • utiliser les feature toggles (mais en dernier recours)
• comment remplacer la revue de code ?
  • le pair programming est une solution possible (revue de code continue pre-commit)
  • on peut aussi faire une revue de code post-commit
    • pre-merge : pull requests fréquentes sur des branches à durée de vie courte
    • post-merge : revue de code de tous les commits poussés sur master
• au delà des raisons invoquées explicitement, quels sont les peurs qui font qu'une équipe peut résister à l'adoption de ce modèle ?
  • les développeurs ne savent pas développer par petits incréments → c'est une compétence encore trop rare, qui doit s'acquérir
  • la base de code est trop couplée, et manque de tests → c'est difficile de changer quoi que ce soit sans craindre de casser quelque chose
  • les builds sont trop lents → 🐢

The Origins of Opera and the Future of Programming (Jessica Kerr)

Je regrette de ne pas avoir pu voir cette présentation. En attendant la vidéo, un article de blog est disponible qui en reprend la trame : https://the-composition.com/the-origins-of-opera-and-the-future-of-programming-bcdaf8fbe960

Endangered Species: Senior Craftsmen (Cyrille Dupuydauby)

Le goulot d'étranglement dans nos métiers, c'est l'apprentissage. Il n'y a pas beaucoup de développeurs qui ont 10 ans d'expérience, et encore moins qui en ont 20. Doit-on compter sur eux pour enseigner le métier aux nouveaux ? Seule une petite partie d'entre eux a envie de devenir prof, le reste préfère sans doute programmer. C'est tous ensemble, en tant que communauté, que nous devons être une organisation apprenante. Chacun, quel que soit le stade où il en est, peut aider les autres.

Slides : https://noti.st/dupdob/gX1kor/endangered-species-senior-crafters

How to take smart notes (Sönke Ahrens)

Les conseils pour prendre des notes sont généralement de les séparer (un cahier ou carnet par sujet / matière), de les relire dès que possible… Ce sont de mauvais conseils.

Les conseils sur comment écrire un article, un rapport, un mémoire, sont très linéaires : trouvez un sujet, puis faites des recherches, puis lisez et prenez des notes, puis faites un plan, puis rédigez… L'écriture y est une tâche parmi d'autres, et la vision est très top-down. Une meilleure approche est possible !

Pour Richard Feynman, la pensée est indissociable de l'écriture. Les notes ne sont pas une forme de stockage du résultat de notre pensée, elles sont notre pensée elle-même. L'esprit a besoin de cet échafaudage extérieur qu'est l'écriture.

Pendant sa carrière académique, Niklas Luhmann a écrit environ 600 publications, dont plus de 60 livres, sur des sujets comme la sociologie, le droit, la politique, les médias, la philosophie, l'art, l'amour… Son secret ? Sa boîte à notes (Zettelkasten).

90 000 notes accumulées. Ça semble beaucoup, mais ça fait seulement 6 par jour.

Son système est simple mais terriblement efficace :

• une idée par note ; une note sert à développer une idée
• chaque note a un identifiant noté en haut à gauche : 1, 2, 3… ( une note peut renvoyer à une autre par son identifiant noté à l'encre rouge dans le texte)
• il n'y a pas de classement hiérarchique, l'organisation est émergente : une note liée à une autre peut être insérée derrière elle dans la boîte, et recevoir un identifiant avec une branche (par exemple : 1a1) ; cela permet de retrouver des notes pertinentes à proximité, et de dérouler ainsi le fil plus tard

En insérant la rédaction de ces notes à ses activités quotidiennes de lecture, séminaires, etc. l'écriture n'est plus quelque chose de séparé que l'on fera juste avant la deadline, mais devient un travail progressif et incrémental. Les questions à creuser et les catégories émergent. Les idées s'enrichissent les unes les autres. Penser, relier et comprendre deviennent des actions concrètes.

Pour en savoir plus : http://takesmartnotes.com

Big corps as little panopticons. Agile coaches as colonial imperialists. (Romeu Moura)

Le panoptique est une architecture de prison imaginée à la fin du XVIIIe siècle par Jeremy Bentham, et analysée au XXe siècle par Michel Foucault dans son livre « Surveiller et punir ».

Ses caractéristiques clés sont que :

• les prisonniers sont toujours vus par les gardes et le savent ;
• les prisonniers ne voient pas les gardes ;
• les prisonniers ne se parlent pas entre eux.

Dans un premier temps, un prisonnier se comporte bien car il est observé. Mais dans un deuxième temps, il est conditionné à devenir son propre garde.

On peut comparer les entreprises à des panoptiques. Les managers veulent une complète visibilité sur ce que font leurs employés (reporting, etc), mais ne communiquent pas sur ce qu'ils font, et les équipes ne se parlent pas. Les équipes finissent par devenir leurs propres gardes, et s'interdisent de faire certaines choses : « ah mais non, ici on ne peut pas faire ça ».

En Amérique du Sud, les colons n'ont pas réussi à transformer les autochtones en esclaves. Ils avaient la mauvaise habitude de se laisser mourir. Ils devaient donc importer des esclaves venant d'Afrique. Jusqu'à ce que les missionnaires jésuites trouvent la combine : une fois convertis à la foi chrétienne, ils craignaient de mourir !

Les grandes entreprises déploient des armées de coachs pour effectuer leur "transformation agile". Il s'agit moins de transformer toute la structure (et certainement pas le haut de la pyramide), que d'imposer un changement à certains

Pour Romeu, tous ces coaches agiles sont des jésuites. Qu'ils croient ou non aux valeurs de l'agilité, ils sont envoyés pour changer la culture de « ces gens là bas ». Ils sont instrumentalisés.

Alors que faire ? Comprendre le système. Lire « Thinking in systems ». Lire Foucault (c'est dur). Regarder la présentation de Jessica ou lire son article.

Chacun d'entre nous a plus de pouvoir qu'il ne croit. Nous sommes conditionnés à penser le contraire. Nous vivons dans une peur artificielle d'agir différemment. Nous surestimons le pouvoir de notre hiérarchie. On les croit malveillants, mais ils sont dans la même situation, à un niveau différent. Et à tous les niveaux, les gens aimeraient que les choses changent. Restez indignés !

What is programming anyway? (Felienne Hermans)

On emploie souvent des métaphores pour expliquer ce qu'est la programmation. Dire que programmer c'est comme les maths, ça peut avoir un effet négatif. Felienne suggère de dire plutôt que programmer c'est comme écrire. Tout le monde peut écrire, et l'écriture a des usages variés : fiction, poésie, calligraphie, pétition, dissertation, liste de courses…

Cette présentation m'a aussi fait réaliser qu'Excel est un langage de programmation fonctionnelle, et que c'était sans doute le meilleur langage de programmation, car des millions de gens l'utilisent sans le savoir… Imaginez vous programmer en Java sans faire exprès !

Atelier: 50 shades of FizzBuzz

L'atelier visait à prendre un problème simple (FizzBuzz) et à explorer différentes manières de l'implémenter, en se donnant des contraintes.

Par exemple, on a commencé en mode zombie pair programming : le co-pilote pouvait faire des gestes mais ne pouvait pas parler, seulement grogner ou dire « brains ! ».

On a ensuite enrichi les spécifications et vu comment le code évoluait.

J'ai profité d'une partie de l'atelier pour explorer comment utiliser le property-based testing pour exprimer les tests.

J'ai mis mes différentes versions sur GitHub : https://github.com/ronnix/50-shades-of-fizzbuzz

Atelier: Evolutionary Design

L'atelier visait à expérimenter l'evolutionary design.

La première activité a consisté à implémenter, en groupes de 4-5 personnes, une nouvelle méthode sur une base de code existante (cool, c'était en Python !), en mode outside-in TDD. Ç'a été une expérience à la fois intéressante et pénible pour moi, car je pense plutôt être de l'école classique du TDD, et faire les choses en mode London school allait un peu contre mon penchant naturel…

La deuxième activité a consisté, toujours en groupes, à prendre une base de code développée par un autre groupe lors d'un précédent atelier où ils avaient plus de temps, et à l'améliorer avec des refactorings.

Dojo tournant en continu

Pendant toute la durée de la conférence, un dojo de programmation a eu lieu en continu, où chacun pouvait venir participer au développement d'un jeu de la vie, en mode mob programming.

Je n'y ai participé que quelques minutes, mais c'était très drôle de voir apparaître en accéléré les problèmes que l'on voit en entreprise sur des projets plus longs sur lesquels il y a du turn over. Le code devient très vite du code legacy, l'intention initiale est vite perdue, les connaissances se transmettent mal, les nouveaux venus veulent aller dans une direction qui a déjà été essayée sans succès par les précédents, mais ils ne le savent pas…

Pauses, couloirs et soirée du jeudi

Les meilleures sessions, ce sont toujours les rencontres et les discussions avec les autres participants. J'ai été heureux de recroiser des gens que je ne vois pas souvent, et d'en rencontrer de nouveaux que j'aurai plaisir à revoir l'an prochain !