Blog Arolla

Interview de Cyrille Martraire, fondateur de la communauté Paris Software Craftsmanship

Cet article a été publié dans le magazine Programmez! du mois de septembre 2015.

On entend de plus en plus souvent parler du courant Software Craftsmanship, que l’on pourrait traduire « Artisanat Logiciel ». La communauté Paris Software Craftsmanship existe depuis déjà quatre années et compte à ce jour plus de 1000 membres. Rencontre avec son fondateur, Cyrille Martraire, développeur passionné depuis quinze ans et directeur technique de la société Arolla.

Cyrille, pouvez-vous nous expliquer d’où vient le mouvement du Software Craftsmanship et en quoi il consiste ?

A l’origine, « Software Craftsmanship » est le titre d’un livre écrit il y fort longtemps mais le courant a véritablement émergé à partir de 2009 quand Robert C. Martin, dit Uncle Bob, a décidé d’en faire son cheval de bataille. En tant que créateur des principes S.O.L.ID., UncleBob est une personnalité incontournable du monde logiciel, une des voix les plus écoutées.

Il a donc popularisé le Software Craftsmanship en réaction à une dérive dans les communautés liées  l’agilité : on est en 2008 tout le monde parle de Scrum et de méthodes agiles du point de vue de la gestion de projets : les post-its, les rituels tels que le stand up meeting, les itérations, le tracking de vélocité… mais sans jamais accorder beaucoup d’importance à la qualité du code produit. Uncle Bob s’insurge et propose alors de remettre l’accent sur les pratiques d’ingénierie logicielle et d’excellence technique: l’agilité est essentielle pour développer efficacement, mais si on néglige les pratiques de développement adéquates, l’agilité permet surtout de développer efficacement de la dette technique. Un de ses slogans est “Build the right thing, and build it right” (Il ne suffit pas de développer le bon outil, il faut aussi bien le développer).

Les quatre principes du Software Craftsmanship ont été rassemblés dans le manifeste du Software Craftsmanship, qui reprend et étend le manifeste agile :

http://manifesto.softwarecraftsmanship.org/

Ce qui est nouveau dans la vision d’Uncle Bob, c’est la dimension de professionnalisme. Il amène l’idée que le Software Craftsmanship consiste à mettre en œuvre toutes les pratiques connues pour être les meilleures chacune dans leur contexte, pour écrire et entretenir du code qui soit non seulement économique à produire mais aussi économique à faire vivre demain, après-demain, le mois prochain et même dans cinq ans. Il faut garder à l’esprit que le code que nous produisons aujourd’hui devra être relu, maintenu, corrigé, modifié pour évoluer.

Dans la rubrique professionnalisme du Software Craftsmanship, on trouve aussi l’attitude des développeurs face à leur management. Il est du devoir des développeurs de parfois dire non à certaines décisions lorsqu’elles s’opposent au professionnalisme. Par exemple, un Software Craftsman ou une Software Craftswoman ne peut faire l’impasse sur des tests unitaires même si on lui demande de le faire “pour aller plus vite”. Pour faire une analogie, si un électricien a besoin d’une demie journée de travail pour isoler une installation électrique, il ne viendra à personne l’idée de dire : « mettons juste du chatterton, ça coûtera moins cher », car désormais tout le monde a compris que cette pratique, si elle fait gagner du temps tout de suite, présente d’autres dangers dans un horizon de temps plus long. Pourtant, dans le développement logiciel, on rencontre couramment des situations où des personnes ayant la capacité de décider réclament ce type de bricolage.

Un autre exemple : on me demande d’estimer la durée d’une tâche, je réponds qu’il faut deux jours, mais on m’impose ensuite de le faire en seulement une journée : le professionnalisme façon Software Craftsmanship sera cette fois d’expliquer que ce n’est pas possible à moins de réduire le périmètre, car il n’est pas question de réduire la qualité, ce qui reviendrait à hypothéquer l’avenir du logiciel.

Il faut néanmoins préciser que le Software Craftsmanship a pour objectif premier de livrer de la valeur pour les commanditaires. Il ne s’agit en aucun cas d’une rébellion contre le management. Il s’agit au contraire de défendre l’intérêt de l’entreprise et du management dans la durée, même si cela peut parfois paraître en contradiction avec certains objectifs à court terme.

Enfin, la question de la transmission est très importante dans le Software Craftsmanship : il s’agit de développer sa compétence et son professionnalisme, mais aussi de les transmettre autour de nous. Nous sommes souvent accusés d’être élitistes, mais ce n’est absolument pas l’objectif.  Le but est au contraire de transmettre et diffuser, auprès des plus jeunes notamment, et bien sûr de donner envie à toutes et à tous de se mettre au code. Coder reste une discipline technique, certes, mais coder n’a jamais été une discipline aussi collective et aussi sociale qu’aujourd’hui. Tout le monde peut y trouver son compte, quels que soient sa sensibilité et son tempérament.

Vous parlez beaucoup de pratiques. Quelles sont celles qu’on peut rattacher au Software Craftsmanship ?

Les pratiques ne sont pas fixes puisque l’idée est de sélectionner les pratiques les plus à jour et les mieux adaptées au contexte. On évite de parler de « meilleures » pratiques, mais plutôt des pratiques les meilleures dans un contexte donné à un instant donné. Aujourd’hui par exemple, Test Driven Development (TDD, le développement dirigé par les tests) est une pratique qui est la plupart du temps celle qui va amener le plus de qualité quand on écrit du logiciel, mais ce n’est pas la seule. Le style de programmation fonctionnelle (FP), les systèmes de types de plus en plus sophistiqués apportent aussi des avantages. Il faut utiliser les meilleurs outils possibles dans notre contexte.

Lorsque la difficulté n’est pas tant de construire le logiciel que de savoir ce qu’on veut, BDD (Behaviour Driven Development) est une pratique qui professionnalise les recueils de besoin et les rend très efficaces en détectant très tôt d’éventuels problèmes en utilisant au mieux les conversations au travers d’exemples concrets.

D’autres pratiques documentées dans la littérature et qu’on rassemble souvent sous le nom de pratiques de testing et de refactoring legacy (code hérité en français) sont à rapprocher du Software Craftsmanship. L’univers des pratiques est très vaste, on y inclut aussi souvent DDD (Domain Driven Design), les patterns d’architecture, le design émergent, l’architecture flexible, ainsi que les hashtags Twitter comme #NoEstimates ou #NoProject. Ces mots-clés polémiques invitent à réfléchir et à reconsidérer certaines pratiques établies qui ne sont plus forcément pertinentes aujourd’hui dans un univers où nos langages sont plus productifs et où on doit produire de plus en plus vite des logiciels toujours plus ambitieux.

Pourquoi fonder une communauté Software Craftsmanship ? Quels sont les apports pour les développeurs qui en sont membres ? Que vont-ils y chercher ?

Depuis la création du Paris Jug (Java User Group) en 2008 sous l’impulsion d’Antonio Goncalves, il y eu beaucoup de User Groups qui étaient pour la plupart centrés sur les technologies, Java, .Net, Ruby, JavaScript, ou des frameworks tels que MongoDB ou Neo4J. Il existait bien aussi quelques petits groupes de codage depuis très longtemps, mais ils restaient plutôt confidentiels. Il n’y avait pas de communauté agnostique aux technologies pour permettre aux professionnels de se rencontrer pour discuter des pratiques, apprendre à s’améliorer dans sa façon de coder, de réfléchir aux questions de design, de pratiquer le TDD, ou de prendre du recul sur la façon d’utiliser au mieux les technologies, nouvelles ou non.

Je connaissais par Twitter la communauté Software Craftsmanship de Londres, créée par Sandro Mancuso. Puis, toujours par la magie de Twitter, à l’occasion de la première non-conférence SoCraTes (Software CRAftsmanship and TESting) en Allemagne, j’ai pu entrer en relation avec Sandro qui m’a donné de nombreux conseils pour créer une communauté à Paris. Il est même venu en personne pour faire la keynote de lancement de la communauté parisienne, avec Arolla comme premier sponsor. C’était une prise de risque, mais dès la première soirée on a compris que cette communauté répondait à des attentes fortes. Au fil des rencontres, mois après mois et années après années, un grand nombre de développeurs parisiens ont fait connaissance et ont pu échanger sur des sujets tels que comment tester du code legacy, comment convaincre ses collègues d’essayer TDD ou de se mettre au pair programming, comment expliquer à mon manager, etc.

Que fait-on pendant les rencontres de la communauté ?

Le format de base est la table ronde. En début de soirée, les participants qui le souhaitent proposent des sujets, puis on se sépare en un, deux ou trois groupes pour discuter de ces sujets. En général, c’est une simple discussion, parfois on met du code à l’écran. Chacun repart en ayant appris, compris quelque chose ou partagé un retour d’expérience utile à d’autres. C’est l’opportunité de faire le tour de l’état de l’art sur des sujets variés, de façon rapide, efficace, et surtout sympathique. Et comme, à chaque fois il y a en plus à boire et à manger, on ne perd pas son temps !

La communauté a désormais quatre ans, est-ce qu’on peut dire que c’est un succès ?

C’est un franc succès ! La communauté parisienne est forte de plus de 1000 membres, c’est une preuve d’intérêt. Le format initial accueillait 25 personnes, aujourd’hui c’est en général plus du double. J’ai été rejoint par Stéphane Basnier qui organise la plupart des rencontres cette année. Les entreprises qui désirent devenir sponsors aussi sont plus nombreuses, avec parfois des sociétés assez éloignées du Software Craftsmanship, ce qui montre que le mouvement devient populaire. L’initiative a fait des petits à Lyon ou à Marseille par exemple, mais également au sein d’une grande banque française une communauté Software Craftsmanship interne s’est créé, qui se rassemble tous les mois.

Les sujets Software Craftsmanship sont présents aujourd’hui dans la plupart des conférences, la notion d’excellence technique revient sur le devant de la scène et c’est très bien. Beaucoup d’entreprises se mettent au Software Craftsmanship et font appel à des développeurs actifs, en particulier de notre communauté, pour relayer en interne leur envie et leur volonté de re-dynamiser la compétence technique. Scrum ne suffit pas, en revanche avec Scrum et le Software Craftsmanship, les deux bien compris, vous avez la capacité à livrer de la valeur rapidement, loin du bricolage et de l’amateurisme qu’on rencontre encore trop souvent.

Est-ce que la communauté a de l’avenir ?

Oui et non. Elle a de l’avenir en popularité bien sûr car c’est un thème porteur. Le nombre de membres va toujours augmenter, les entreprises vont s’y mettre les unes après les autres, et comme toute initiative victime de son succès, on va assister à de la récupération, avec des acteurs moins sincères qui vont s’approprier les termes pour des raisons commerciales, jusqu’à ce que le terme perde de son sens. Sur le fond, ces acteurs vont continuer à populariser les idées, mais ce sera regrettable pour les entreprises qui seront parfois déçues, un peu comme dans l’agilité où les coachs agiles ne se valent pas tous. Il faudra de plus en plus faire preuve de discernement dans le casting des intervenants qui se réclament du Software Craftsmanship.

De quels autres mouvements et communautés la communauté Software Craftsmanship est-elle proche ?

La communauté la plus proche, et de très loin, est « eXtreme Programmers Paris », car l’eXtreme Programming est la méthode agile qui a toujours fait du Software Craftsmanship avant même que le nom existe. Ce groupe se réunit de façon intermittente.

Ensuite il ne pas oublier de mentionner le Coding Dojo historique initié notamment par Laurent Bossavit. Eux aussi ont anticipé le Software Craftsmanship, avec les mains dans le code. A Paris il y a aussi le groupe des Duchess, qui sont à l’origine un groupe de développeuses qui souhaitent valoriser la place des femmes dans le développement. Les Duchess ont été longtemps parmi les rares à proposer des ateliers hands-on qu’elles appellent les marmites. Elles sont très proches du Software Craftsmanship, des questions de code jusqu’aux questions d’attitude dans notre métier. J’ai déjà cité le Paris Jug, mais j’ai oublié le groupe Alt.Net. Aujourd’hui la communauté Alt.Net Paris est très versée dans le Software Craftsmanship et le DDD, on croise souvent les même développeurs et développeuses dans les communautés DDD, F# et Software Craftsmanship.

Qu’est-ce que le Software Craftsmanship vous a apporté ?

A titre personnel, la communauté Paris Software Craftsmanship m’a ouvert des portes, notamment pour aller parler du sujet dans des grandes entreprises par exemple, c’est un aspect qui m’a surpris mais qui a été très bénéfique pour promouvoir nos points de vue.

Craftsmanship, artisanat… Y a-t-il un rapport avec le compagnonnage ?

C’est évident qu’on retrouve certaines valeurs du compagnonnage dans le Software Craftsmanship : excellence, transmission, parrainage, apprentissage. La communauté parisienne aurait pu s’appeler « Artisanat du Code » ou « Compagnonnage du Code », mais ces traductions ne sont en fait pas appropriées. Dans le compagnonnage, pour des raisons historiques, comme la persécution, on retrouve une culture du secret et du rituel d’initiation qui ne nous correspond pas. En revanche, on retrouve par exemple la recherche de l’excellence, faire ses preuves, apprendre son métier avec un mentor. Dans ce qu’on appelle un « Craftsman Swap », deux développeurs vont échanger leur place et leur poste, pendant une semaine, dans deux entreprises différentes et même parfois concurrentes, pour apprendre au contact de ses pairs dans un autre environnement. Ce n’est pas sans rappeler le tour de France des compagnons !

Par contre le côté corporatiste, les traditions et les rites de passages n’existent pas dans le Software Craftsmanship. Mais nous retrouvons une base commune sur l’excellence, l’apprentissage et l’amour du travail bien fait.

Et pour aller plus loin…

A lire sur le sujet, le livre « Apprenticeship Patterns » de Dave Hoover, à la genèse du mouvement.

Le livre de base sur le Software Craftsmanship est bien sûr le livre d’Uncle Bob,  « The Clean Coder ». « Clean Code », un autre livre d’Uncle Bob, est un classique du Software Craftsmanship, mais « The Clean Coder » est un livre plus court, plus léger et d’une lecture fort agréable.

Et le dernier en date, un très bon livre, très intéressant, et très personnel, de Sandro Mancuso, sur sa démarche personnelle de Software Craftsman, avec plein de bons conseils, notamment comment recruter un Software Craftsman, comment faire des code reviews, etc. : « The Software Craftsman ».

1 comment for “Interview de Cyrille Martraire, fondateur de la communauté Paris Software Craftsmanship

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *