Lancement du Paris Software Craftsmanship Community

Le craftsmanship s’étend en Europe ! Après la création en août 2010 de la London Software Craftsmanship Community (LSCC), puis celle en Allemagne en septembre 2011, la branche parisienne a tenu sa première session ce jeudi 20 octobre.

En 3 semaines, 99 inscrits sur Meetup ! On peut déjà suivre l’activité sur Twitter. A cette première session, beaucoup de développeurs Java, quelques rubyistes et bientôt plus de développeurs .Net, car cette communauté s’adresse bien sûr à tous les langages.

Au programme, une proposition de la vision pour cette communauté puis une présentation renversante d’un invité surprise venu de Londres.

Bienvenue au PSCC

Cyrille Martaire l’organisateur de cette première session pense qu’il existe un fossé entre les user groups techniques (Java, Ruby, Scala, …) et les user groups moins techniques (Scrum, Lean, …). Où sont les groupes autour du TDD, du Clean Code, de la feature injection, du refactoring, des legacy challenges, etc. ? Il est vrai qu’il existe des groupes tels que les Duchess qui amènent cet esprit de communauté ou encore des événements comme les codes retreats et coding dojos qui mettent l’accent sur la technique plutôt que sur la technologie.

Cependant, pour Cyrille l’idée est de rassembler une communauté — donc sans pouvoir central — où chacun pourrait intervenir à tout niveau, pour expérimenter, pratiquer, mentorer, échanger et réfléchir à l’importance et à la diffusion de nos pratiques dans l’industrie. Lors de ces sessions, il n’y aurait pas de réponses toutes faites mais plutôt des solutions à penser ensemble. Les sessions pourraient s’organiser par exemple autour de round table discussions, de hands-on, de guest talks ou lightning talks et couvriraient des sujets aussi divers que notre future carrière en tant que codeurs ou tout simplement comment découpler son code.

Invité surprise

Ensuite nous avons assisté à une présentation sur le software craftsmanship de très haute qualité et pleine de vécu. Venu tout droit de Londres, le co-fondateur de la communauté londonienne du software craftsmanship, Sandro Mancuso, a touché et inspiré son audience.

Au quotidien, Sandro est consultant dans le système bancaire de la City, où depuis longtemps d’ailleurs les développeurs agiles pratiquant le TDD sont très recherchés. Le rôle de Sandro est de pair-programmer avec les développeurs de son plateau et ainsi de diffuser les pratiques et donc les bons réflexes du craftsman. Un rêve apparemment pour lui de pouvoir coder et de partager entre développeurs toute la journée. 

La transformation agile

Sandro nous rappelle que la transformation agile a commencé il y a maintenant 10 ans et que nous avons passé la plupart de ces 10 années à nous concentrer sur les personnes, leurs interactions, le team building, l’écosystème et que cela a pris le dessus sur les pratiques techniques.

Aujourd’hui malgré cette transformation agile nous avons toujours des bogues, des problèmes d’intégration et des urgences en production. C’est ce que Sandro appelle l’agile hangover. Il rappelle non seulement que les processus sont importants, mais que le produit lui même est finalement central. L’exemple de Toyota vient à l’esprit : des processus leans et bien rodés, mais voudriez-vous rouler dans une Toyota qui sortirait de la chaîne pleine de défauts?

Notre notion du temps

La plupart du temps semble-t-il, nous sommes sous pression et nous voulons pourtant avancer et finaliser nos développements. Que choisissons-nous alors ? Nous prenons des raccourcis. Nous avons, dit-il, une notion du temps erronée. Nous dépensons beaucoup d’énergie dans des cycles de déploiements d’artifacts contenant du code déjà bogué ou en essayant d’expliquer du code hérité lorsque nous savons qu’une pratique comme le TDD permet d’approcher le code légué, offre une boucle de feedback extrêmement rapide et réduit de façon drastique le nombre de bogues en production.

Souvent, nous oublions que des pratiques comme le test, le refactoring et le cleaning font partie intégrante de notre programmation quotidienne et que lorsque nous nous efforçons dans nos sprints à créer en parallèle de notre user story des tâches ou sous-tâches dédiées aux unit testing, refactoring, cleaning, code reviewing, en réalité nous ne faisons — en plus de dépenser de l’énergie inutilement dans Jira — que donner l’opportunité à notre product owner de les écarter, dé-prioriser, de les oublier ou pire de pouvoir les supprimer.

Pratiquer et convaincre

Nous sommes les seuls responsables en tant que codeurs pour garder notre système propre et testable. Et pour cela les moyens existent déjà. Ne serait-ce que les pratiques de l’extreme programming. Lors de cette séance, Sandro nous montre que ces pratiques sont indépendantes du contexte et donc implémentables dans 99% des situations. Il est possible alors de produire du code propre, testable et découplé. Le pair programming par exemple vous donne un retour instantané sur votre nommage (classes, méthodes, variables) et votre design (découplage, granularité, responsabilité, complexité).

Sandro insiste sur le fait que si l’on veut convaincre avec le craftsmanship, il ne faut pas débattre autour des pratiques mais plutôt montrer ce qu’elles apportent. Si votre manager ne comprend pas l’intérêt du collective code ownership ne lui expliquez pas comment cela fonctionne mais plutôt ce que cela va lui apporter. Il en va de même pour l’intégration continue.

Sandro a aussi beaucoup parlé de nos carrières et de l’importance de la pratique. Il dit faire 20 heures de pratique par semaine mais avoue que cela fait beaucoup et que tout le monde n’a pas la chance de pouvoir pratiquer autant. Chez notre employeur, il nous propose de voir tout code legacy non pas comme un poids mais comme un challenge. Un puzzle gigantesque à résoudre. Dans ce gigantesque puzzle, explique t-il, essayons de dégager d’abord les 4 coins, d’assembler par couleurs, de détecter des patterns, et de résoudre les problèmes petit à petit.

Finalement le craft c’est quoi

Le craftsmanship, c’est donc nous : développeurs, programmeurs, codeurs. Nous ne sommes pas de simples employés mais des professionnels exerçant un métier que beaucoup devraient nous envier. C’est aussi cette alliance productive que nous devons avoir avec nos clients et entreprises. Et c’est aussi une responsabilité, surtout dans la transmission du savoir et la préparation des générations futures.

Le software craftsmanship n’est pas une église et n’essaie pas de convertir mais plutôt de montrer par l’exemple. Ce n’est pas du beautiful code en veux-tu en voilà mais plutôt une façon continuelle d’ajouter de la valeur au produit.

Comme le résume Sandro : « Software craftsmanship is all about putting responsibility, professionalism, pragmatism and pride back into software development. » 

Bien sûr, ajoute Sandro, le craft n’est pas suffisant pour assurer le succès d’un produit, mais le manquement du craft pourrait bien être la principale cause de son échec. Et n’oublions pas que l’agilité et le software craftsmanship se complètent : les processus agiles nécessiteront toujours une excellence technique et une attitude professionnelle. 

Alors merci encore à Sandro et à Cyrille et souhaitons beaucoup de participations et une longue vie au PSCC.