Retour sur #NCrafts 2017

La conférence NCrafts 2017 s’est déroulée durant les 18 et 19 mai à Paris. Une conférence cette année sur le thème Humble Programmers.

Cette conférence, dont la première édition eu lieu en 2014, cherche à mettre l’accent sur le mouvement du software craftsmanship et le métier de développeur. NCrafts se veut agnostique à la fois vis-à-vis des technologies, des pratiques et des langages. Apparaissent alors en guest stars les sujets sur l’agilité, le domain driven design (DDD), la programmation fonctionnelle et la programmation objet, ainsi que de potentiels nouveaux concepts et des réflexions sur la vie de développeur. En terme de langage pour les présentations techniques, la majorité des talks autour du code était basée F#, mais il y avait aussi du C#, Scala, Haskell, Java, Swift, JavaScript, Go et bien d’autres encore.

Je vous propose de vous raconter cette expérience et de vous partager quelques réflexions personnelles sur les keynotes de NCrafts 2017, dont j’ai apprécié la qualité.

Talk de bienvenue

Rui Carvalho, le principal organisateur de la conférence, a commencé par nous parler de concepts de développement de bon sens et paraissant telle une redite, pour peu qu’on ait une certaine habitude des pratiques agiles. Toutefois, le point de vue présenté semblait légèrement différent des discours habituels sur ce thème.

Puis Rui sort un manifeste nommé The Humble Programmer Manifesto : un manifeste de plus ?!

Il ne s’agissait aucunement d’un énième manifeste. Rui indique que tout le discours qu’il vient de présenter avait déjà été énoncé en 1972 par Edsger W. Dijkstra. Plus exactement, il s’agit du discours qu’il a prononcé lors de la remise de son prix Turing ; discours intitulé The Humble Programmer (EWD 340).

Par cette démonstration, Rui a tenté de faire comprendre que le monde du développement a besoin de connaître son histoire pour s’améliorer et s’épanouir davantage. Une partie des problèmes de nos jours peuvent être résolus grâce à des solutions plus anciennes que nous.

L’informatique est un domaine récent et son histoire est bien souvent mal connue surtout par ceux qui le pratiquent. Ces constats sont encore plus creux dans le cadre du développement logiciel. Mais quel intérêt aurions-nous à étudier notre passé ? Nombre de conseils venant de développeurs d’expérience aujourd’hui ont déjà été prononcés dans les années 60, 70 par ces pionniers de l’informatique que sont Dijkstra et ses nombreuses correspondances, Knuth et son oeuvre intitulé The Art of Computer Programming (TAOCP) ou Backus et son plaidoyer pour un style de programmation alternatif décrit dans Can Programming be Liberated from the von Neumann Style?. Et il s’agit bien de conseils, d’autant que ces personnes ont forgé la perception que nous avons actuellement du développement logiciel. Ces pionniers ont trouvé les mots qui nous manquent parfois pour décrire les problèmes que nous rencontrons régulièrement et ont imaginé des solutions pour les résoudre. De ces époques reculées, nous avons beaucoup à apprendre. Comme le disait le philosophe américain George Santayana : Those who cannot remember the past are condemned to repeat it.

Le talk d’introduction de Rui était court, mais c’est celui qui m’a probablement le plus intéressé, tant le sujet m’a passionné par le passé et me passionne toujours autant actuellement.

Les slides sont disponibles sur slideshare.

What Ever Happened to Being eXtreme? (Rachel Davies)

Rachel Davies est revenue sur une méthode plus connue pour ses pratiques de développement que son approche du management : l’eXtreme Programming ou XP. Car, comme je le rappelle assez souvent autour de moi, il ne faut oublier que l’XP couvre un périmètre plus large que Scrum. Rachel rappelle que cette méthode, née dans les années 90 avant le manifeste agile, a pour objectif de livrer de la valeur aussi vite que possible en vue d’optimiser le feedback à l’équipe de développement. Pour cela, l’équipe projet doit être capable de prendre des risques et pour cela elle a besoin de courage ; le courage étant l’une des plus importante valeur de l’XP.

Pour Rachel, l’XP est une méthode qui doit continuer à évoluer. Aussi, elle nous a donné une énumération de ce qu’est l’XP de nos jours, de part sa propre expérience. Voici quelques points parmis ceux qu’elle a remonté :

• Le mob programming pour remplacer le pair programming. Le pair programming incorpore selon elle encore trop de risque d’effet tunnel. On peut le pallier avec une rotation des pairs, mais elle finit par perdre de son efficacité. Le mob programming consiste à faire travailler toute l’équipe de développement sur la même fonctionnalité autour d’une seule machine de développement (mais avec un vidéo-projecteur à la place de l’écran). Cette approche offre plus de flexibilité. Elle réduit d’autant plus l’effet tunnel au sein de l’équipe et favorise le partage de la connaissance sur un projet (collective ownership).
• Pas de branche mais des tokens de déploiement. On voit de plus en plus de projets où GitFlow et ses multiples branches (dont les feature branches) sont rejetés. Sur ces projets, il n’y a plus qu’une seule branche et la livraison se fait au commit près ou au token près. Cette approche permet d’avoir une mise en production quotidienne. Néanmoins, elle ne fonctionne que si les intervenants sont colocalisés.
• Rencontre entre tous les acteurs concernés par le projet (du développeur à l’utilisateur) pour un meilleur partage de la vision.
• Backlog d’innovation cross-product géré par les développeurs afin d’améliorer la livraison de valeur.
• Story time : estimation des user stories quand elles sont prêtes, plutôt que des réunions d’estimation à période fixe. Le story time permet de diminuer le temps passé dans les réunions d’estimation et s’avère être moins contraignant.
• Un jour par semaine aux développeurs pour apprendre une nouvelle technologie (c’est un thème qui est souvent revenu au cours de NCrafts 2017). Cela permet de rester à l’écoute des innovations et d’être prêt à l’intégrer si le besoin est exprimé.
• Changement d’équipe pour les développeurs qui le souhaitent, tous les 3 mois. L’idée est d’apporter pour les projets un regard nouveau et éviter d’autant plus l’enlisement. Quant au développeur, cela lui donne la possibilité de briser la monotonie et de satisfaire son épanouissement.

L’ensemble des pratiques proposées par Rachel est particulièrement tentant. Elles montrent notamment que l’agilité reste un sujet ouvert et qui doit sans cesse évoluer pour aller toujours vers plus d’efficacité. Par contre, je ne peux m’empêcher de penser que les pratiques présentées ne fonctionnent qu’avec des équipes capables de s’adapter et de s’épanouir dans un environnement ouvert. Ce qui fut effectivement le cas pour Rachel.

Well-rounded architect (Patrick Kua)

Dans cette keynote, Patrick Kua de ThoughtWorks est venu partager avec nous sa vision de la notion d’architecte. D’entrée de jeu, Patrick indique que pour lui architecte est un rôle. Il peut très bien ne pas exister. Il peut aussi être joué par un ou plusieurs développeurs, mais pas n’importe lesquels non plus : il faut une certaine expérience et appétence sur ce sujet.

Là-dessus, Patrick pose la question de la relation entre architecte et architecture. Pour lui, le but de l’architecture est de réduire le coût du changement. L’architecte est responsable ou référent de l’architecture et de la “nourrir”. Par contre, il n’en est pas le propriétaire. L’architecture appartient à l’équipe. Et l’architecte ne prend pas non plus seul les décisions dessus. Pour cela il doit consulter l’équipe.

Patrick propose un radar à 6 axes sur lesquels évaluer la capacité d’une personne à endosser le rôle d’architecte :

• il doit être un bon leader technique et être capable d’orienter les participants d’un projet dans la même direction,
• il doit être développeur, afin de mieux comprendre les difficultés rencontrées par les autres développeurs, ainsi que d’être plus à l’écoute des solutions proposées par ceux-ci,
• il doit avoir une bonne perception de l’écosystème qui entoure l’application issue du projet,
• il doit au moins penser comme un entrepreneur, se poser des questions sur les bénéfices que vont engager les décisions sur un projet et favoriser une approche fail fast (learn fast ?),
• il doit mettre au point une stratégie sur les technologies, en demandant d’essayer de nouveaux produits et en produisant des rapports sur ces expérimentations (en produisant par exemple l’équivalent d’un TechRadar à la ThoughtWorks),
• il doit enfin être un communicant efficace et être capable d’adapter son discours à des personnes techniques et non-techniques.

Patrick a donné par la suite un ensemble de motifs sur la base de son radar pour montrer des profils types d’architectes qui peuvent poser problème et en mettant en valeur ce qui peut manquer comme compétence dans chacun des cas.

Ce talk m’a intéressé parce que j’interviens personnellement en tant qu’architecte sur des missions. Je me pose souvent la question de comment un architecte peut avoir un rôle de facilitateur technique, sans tomber dans l’image du bullshitect (merci à Alexandre Victoor pour le jeu de mot ^^) spécialiste des slides. Il y avait dans ce talk une vision de ce rôle intéressante à creuser et à développer.

Readable in a New Language (Laura Savino)

Laura Savino est développeur iOS. Elle nous a proposé dans cette keynote de faire un parallèle entre sa découverte de Swift, le langage développé par Apple, et la découverte de langues étrangères ; Laura ayant enseigné des langues étrangères.

Le langage informatique, tout comme le langage naturel, vient avec un certain nombre de nuances, de subtilités et de stéréotypes. Pour l’un, il y a l’accent et la culture locale qui influent sur la langue de base. Pour l’autre, il y a l’adoption de patterns et de frameworks qui dépendent de la communauté fréquentée. La traduction directe peut se faire, mais elle donnera des résultats inattendus : la simple traduction mot à mot de “thank you” peut se transformer de manière inattendue en l’équivalent “Whoaaaaa (gracefully)!” dans d’autres langues. De même, dans les langages informatiques, la simple tentative de reproduire les patterns habituels d’un langage dans un autre montrera surtout que vous manquez d’expérience dans le langage cible.

Suite à ce constat, Laura pose la question de ce qu’est le code lisible ? La notion de lisibilité dépend de celui qui lit. Car si une chose est sûre, c’est que nous ne sommes absolument pas d’accord sur ce qu’est un code lisible ; et il est faux de croire que les commentaires aident. Le principe étant que la lecture du code ne doit pas se transformer en séance de décryptage, qui implique de rester d’autant plus concentré, d’avoir suffisamment d’énergie et de s’isoler. Un code lisible doit être un code que vous êtes capable de lire rapidement et correctement. Ainsi lorsque vous écrivez du code, vous devez penser à minimiser l’effort que fourniront vos collègues lorsqu’ils vous reliront.

Comment produire un code lisible selon Laura ?

• Éviter certains idiomes, tout comme vous éviteriez l’argot avec des personnes qui n’ont pas votre culture. Par exemple, tout le monde ne comprend pas cette phrase d’argot : “Il se vissa le bada sur la calebasse et mit les adjas sans moufter…”, qui veut dire “Il mit son chapeau sur sa tête et partit sans dire un mot…”.
• N’hésitez pas à introduire des variables pour clarifier le contexte, par exemple dans le cas de one-lines (i.e. le fait d’écrire un traitement avec un chaînage de méthodes). Comparez

Map<String, Integer> occurrences = Files.lines(Paths.get(filename))     .collect(Stream.collector())     .flatMap(line -> separators.splitAsStream(line).collect(Stream.collector()))     .map(String::toLowerCase)     .groupBy(word -> word)     .mapValues(Stream::size)

Et

Stream lines =    Files.lines(Paths.get(filename)).collect(Stream.collector())Stream words =    lines.flatMap(line -> separators.splitAsStream(line).collect(Stream.collector())).map(String::toLowerCase)Map<String, Integer> occurrences =    words.groupBy(word -> word).mapValues(Stream::size)

• Introduisez les “régionalismes” en douceur.
• Utiliser la répétition de motifs visuels : a priori, des fragments de code qui se ressemblent ont une signification proche.

Quelques pistes pour tester que votre code est lisible.

• Squint test (plisser les yeux) : prenez du recul, plissez les yeux et regardez globalement ce que donne votre code, en détectant des motifs en terme de forme globale.
• Mettez en correspondance votre code avec des anti-patterns connus. Par exemple : l’action à distance, yo-yo problem, object orgy… Une liste assez complète se trouve sur WikiWikiWeb.

Le principe est avant tout que vous soyez prévisible lorsque vous écrivez du code.

Optimised for what? (Alberto Brandolini)

Dans ce talk, Alberto revient, non sans humour, sur les problèmes rencontrés en développement logiciel et sur les potentiels points d’amélioration, en analysant les méthodes Waterfall d’une part, ainsi que la méthode agile et ses diverses interprétations.

La méthode Waterfall part bien entendu d’une bonne intention, mais se transforme en une méthode optimisée pour repousser les mauvaises nouvelles. Quant à l’agilité, tout du moins la perception qui ressort sur beaucoup de projets, elle semble être optimisée pour la prédictibilité et réduite à cet aspect dans la plupart des projets.

Dans les projets, Alberto fait remarquer que le principal goulet d’étranglement est l’apprentissage. Ici apprentissage est à prendre au sens large : Alberto parle aussi bien du fait d’acquérir une nouvelle pratique que de comprendre un projet et son contexte. Malheureusement, l’apprentissage n’est pas livrable, n’est pas visible et est fragile (nous ne sommes pas payés pour apprendre). Mais l’apprentissage est un investissement et c’est ce qui nous fait avancer. D’une manière ou d’une autre, l’apprentissage est inévitable. Et le logiciel fonctionnel en est l’effet de bord.

Là-dessus Alberto nous fait remarquer les points suivants :

• L’ennui est le pire ennemi de l’apprentissage. Mais l’inverse est vrai aussi : l’apprentissage est le pire ennemi de l’ennui.
• L’apprentissage nécessite de faire des erreurs. Il faut donc mettre en place un environnement où l’échec est permis pour le pratiquer.
• Le plus souvent, les nouvelles idées apparaissent de manière inattendue et en dehors du travail. C’est pourquoi il est important d’avoir un jour spécial libre et dédié à l’apprentissage.
• Réinventer la roue est une nécessité (mais pas en prod, bien sûr). Cela permet de mieux comprendre et maîtriser les mécanismes de ce qui est mis en place ou de ce qu’on souhaite mettre en place.

Lorsque nous travaillons sur un projet, nous avons besoin de sentir que nous avons bien travaillé. Pour cela, il faut un objectif. Et la meilleure façon d’y arriver est de rencontrer l’utilisateur de l’application que nous construisons. Cela aussi fait parti de l’apprentissage !

Conclusions

NCrafts c’est aussi des talks, des workshops et des open spaces. Il y a aussi une journée de formation la veille de l’événement et une soirée ouverte à tous les participants. En à-côté, on peut apprécier la qualité des repas en self-service, loin du sandwich que nous propose certains services ferroviaires.

NCrafts 2017 fut une session où dans l’ensemble je me suis régalé et où surtout j’ai appris. Je me donne rendez-vous l’année prochaine les 17 et 18 mai 2018 pour la nouvelle session (les sessions suivantes sont effectivement annoncées un an à l’avance). Entre temps, une session NCrafts aura lieu le 7 décembre 2017 à Bordeaux.

Les différentes vidéos ainsi que celles des années précédentes sont disponibles sur le site : http://videos.ncrafts.io/.