Press "Enter" to skip to content

Lecture : “The Software Craftsman” par Sandro Mancuso

Un excellent ouvrage de référence sur le mouvement du Software Craftsmanship

Je viens de finir le livre The Software Craftsman par Sandro Mancuso. Le sous-titre est le suivant : Professionalism, Pragmatism, Pride.

Sous-titre : Professionalism, Pragmatism, Pride

Justement, le sous-titre de ce livre qui décrit les Artisans du Logiciel n’est pas anodin. Il résume assez bien l’approche prise dans ce livre pour parler du Software Craftsmanship : pas tant parler des pratiques techniques que de l’attitude et l’état d’esprit des Craftsmen. C’est justement ce qui en fait une excellente lecture ! Et ce, même si vous n’êtes pas développeur. D’ailleurs, le livre est plutôt fin et se lit assez rapidement.

TL;DR

En vidéo : c’est quoi le Software Craftsmanship ?

On m’a demandé de faire une présentation sur le sujet…

medium.com

  • Si vous êtes dev’ : franchement, lisez ce livre
  • Si vous êtes agent du changement (coach Agile…) : ce livre vous aidera à comprendre pourquoi une “transformation digitale” n’est pas qu’une question d’organisation, mais nécessite également une forte expertise technique . Expertise qu’il faudra aller chercher ailleurs si vous ne l’avez pas vous-même !
  • Si vous êtes manager ou chef de projet : ce livre vous aidera à mieux comprendre comment fonctionnent les (bons) développeurs, mais aussi comment vous devriez faire votre propre travail pour leur permettre d’être au top
  • Dans tous les cas, le livre se lit assez rapidement, et est rempli d’anecdotes ce qui le rend très agréable à lire

Le Software Craftsmanship

Ce livre m’a également réconcilié avec le nom du mouvement, que je n’ai jamais aimé : le Software Craftsmanship en anglais ou l’Artisanat Logiciel en français. Sandro l’explique assez bien, au final qu’on aime ou pas le nom du mouvement, c’est ce nom qui a pris et ce n’est pas ce qui importe, alors utilisons simplement le même terme que tout le monde.

Avant d’aller plus loin, vous vous demandez peut-être ce qu’est le Software Craftsmanship ? Si le terme vous est inconnu, je vous invite à consulter le Manifeste du mouvement, disponible également dans sa traduction en français.

Le Manifeste du Software Craftsmanship, version française

Ça ne vous parle pas ? Réfléchissez-y

Qu’on utilise ce nom ou pas, le thème du Software Craftsmanship est récurrent dans le monde du développement logiciel.

Ainsi j’ai envie de faire le lien entre le Software Craftsmanship et ma propre définition de ce qu’est un bon développeur. À savoir que le bon développeur, est bien plus qu’un codeur mais est également apte à construire un produit et à en assurer le niveau de qualité.

En simplifiant, le Craftsman c’est ça : c’est ce fameux super développeur qui code pour construire un produit, pérenne, fonctionnel, qui marche.

Le Craftsman c’est ce professionnel du logiciel, qui se garde à jour, qui partage avec la communauté, et surtout qui traite ses clients dans le but de leur rendre service.

Le bon développeur, plus qu’un codeur

Skillz = coding + tests + produit

medium.com

J’ai également envie de faire le lien entre le Software Craftsmanship et la présentation que j’ai faite à HumanTalks. Un des messages clefs de cette présentation, c’est que les développeurs ne doivent pas être dans la posture de simple exécutant, mais bien dans celle d’ingénieur. Des professionnels donc, qui conseillent leurs clients, et qui s’assurent d’eux-même de répondre aux attentes du client, d’un point de vue produit mais aussi d’une point de vue qualité.

Retour sur HumanTalks Paris Mars 2017

J’ai présenté un des talks !

medium.com

Citations cultes

Avant de faire le tour du livre chapitre par chapitre, j’ai envie d’en vous citer mes passages préférés, des passages que j’ai envie de qualifier de perles. Des phrases chocs, des moments magiques, propices à sortir de leur contexte.

Parfois, le passage me parle tellement que je ne peux m’empêcher de réagir. C’est pourquoi j’ai ajouté mon propre commentaire.

Si ces phrases sont des pépites, alors ce livre est une mine d’or !

A good developer is a developer who can write code that any other developer can understand.

Saying ‘no’ freed our minds to focus on different approaches and find other solutions to our problem.

Good managers are part of the team. They stay with the team during good and bad times. If everyone is committed to work extra hours, they should be there as well, even if just to buy the pizzas, give moral support, and crack a few jokes every now and again. The team feels better knowing that everyone is in the same boat, feeling the same pain or enjoying success.

Ah ! Je me souviens encore de ces soirées où les seuls encore sur le pont étaient les membres de l’équipe. Les managers, les chefs, étaient bien entendu partis depuis belle lurette. Partis en douce, pourrais-je même ajouter — même pas un mot un peu gêné au moment de partir, même pas un “allez les gars, vous allez y arriver, courage” et surtout pas de “merci.” C’est fou de se dire jusqu’où nous allions, par pur professionnalisme — envers une hiérarchie qui ne nous donnait rien en retour.

Clients very rarely understand the full impact of certain decisions on a software project, and it is our job to make them aware of it. It is our job to say no to our clients when they ask us for something we know is not going to work or that is not going to be done by a certain deadline.

It is easy to say that a piece of code is badly written. It is easy to complain or even laugh. But the question is: are you good enough to make it better?

Bad code is like a cancer, difficult to identify in the beginning, and hard to treat when it is finally discovered. And depending on when it was discovered, life can be prolonged but death is unavoidable.

Managers and Agile coaches have a very low chance of motivating developers because they are not close enough to them. […] I mean sharing a career, a passion. The best person to motivate a developer is another developer.

The problem is not the amount of unexpected changes in a software project; the problem is our inability to cope with them.

Introducing abstractions early, with no justification other than “we may need it in the future,” is what makes applications so complicated.

Quality is not expensive. The lack of skills is what makes well-crafted software expensive. TDD doesn’t slow developers down. Typing is not a bottleneck. Learning and mastering a new skill, practice, or technology is.

Un jour, je vous parlerai d’un autre livre intitulé Quality is Free. Ce n’est pas la qualité qui est chère en soi, mais c’est bien le défaut de qualité qui coûte cher. Le coût pour mettre en place la qualité est en fait bien moins élevé que celui de supporter une qualité à la marge.

Tour du livre

Faisons le tour du livre, dans l’ordre de ses chapitres.

Chapitres 1 à 3 : Qu’est-ce que le Software Craftsmanship ?

Le premier chapitre, Software Development in the Twenty-First Century, sert de belle introduction au livre en remettant dans son contexte le rôle du développeur par l’utilisation d’anecdotes très bien trouvées. Surtout, ces anecdotes sont un régal à lire tellement elles sont à la fois cocasses et criantes de vérité.

Le chapitre 2, Agile, fait le lien entre le Software Craftsmanship et le Manifeste Agile ainsi que sa mise en pratique : le Manifeste Agile ne suffit pas, il faut également être techniquement excellent. Or, les coaches Agile ne sont pas forcément aptes à gérer cet aspect selon leur passé, leur expérience et leurs compétences. D’où l’importance du Software Craftsmanship pour atteindre une excellence technique et réussir une transformation Agile !

Le chapitre 3, Software Craftsmanship, parle donc du mouvement du Software Craftsmanship, avec un petit topo de son historique. Au passage, Sandro nous explique bien que le nom du mouvement, dont on n’est pas forcément fan, est sans importance. Le Manifeste du Software Craftsmanship est bien entendu présenté et commenté. Un aspect fondamental du Software Craftsmanship est mis en avant : c’est une communauté qui partage, s’accompagne, s’entraide.

Chapitres 4 à 6 : Conseils pour les développeurs

Le chapitre 4, The Software Craftsmanship Attitude, explique qu’un développeur se doit de gérer sa carrière lui-même et d’avoir une attitude qui sert toujours son client ; même en tant qu’employé, le développeur a un client à servir : son employeur. Le développeur doit donc impérativement se garder à jour, et le chapitre fait le tour de tout un tas de moyens pour y arriver. Il doit également (beaucoup) s’entraîner, en permanence. Enfin il doit penser à socialiser via des conférences, groupes, meetups… Il est important de se connaître soi-même et de se créer des opportunités pour apprendre. Des conseils et des techniques sont dispensés pour réussir à se créer du temps.

Le chapitre 5, Heroes, Goodwill, and Professionalism, part à nouveau sur des anecdotes de haut vol, pour nous parler de projets qui finissent mal. La leçon à tirer ? Il fallait dire NON. Le chapitre explique l’importance de savoir dire non : c’est en fait un service rendu au client, c’est cela être professionnel. Des conseils sont donnés pour réussir à dire non, car il ne suffit pas de dire non : il faut également fournir des options, des alternatives.

Le chapitre 6, Working Software, nous explique la qualité est toujours attendue par le client. Même s’ils n’en parlent pas ou qu’ils la déscoppent pour aller plus vite ou moins cher : au fond d’eux, ils s’attendent toujours à quand même avoir un produit qui marche à la fin. À ceci s’ajoute le fait qu’une mauvaise qualité ralentira les développements et empêchera d’itérer vite et donc de répondre aux besoin clients : la mauvaise qualité n’est donc pas un choix possible, quoi qu’il arrive. Ainsi, le développeur n’a pas besoin de permission pour faire des tests unitaires. À nouveau, de belles anecdotes truffent le chapitre et servent d’argumentaires percutants.

Chapitre 7 : Mettre en place les bonnes pratiques de développement

Le chapitre 7, Technical Practices, fait le tour des bonnes pratiques techniques à ce jour, essentiellement tirées de XP (eXtreme Programming). Mais surtout, le chapitre donne les arguments rationnels pour justifier et convaincre de leur usage, en se focalisant sur la valeur que chacune d’elles apporte.

Si vous n’êtes pas familier avec ces pratiques, en voici la liste : tests automatisés, Test First,Test-Driven Development, Continuous Integration, Pair Programming, Refactoring. La fin du chapitre rappelle qu’il s’agit là des meilleures pratiques du moment : les Craftsmen sont ouverts et prêts à en adopter d’autres, si elles se révèlent meilleures.

Chapitre 8 : Gérer sa carrière

Le chapitre 8, The Long Road, explique que dans chaque poste ou mission, il faut rechercher trois choses : l’autonomie, la maîtrise et le but (en anglais : Autonomy, Mastery, Purpose). Si ces trois éléments ne sont pas là, il faut changer de poste sans hésiter. Il en découle qu’il est assez difficile de rester longtemps auprès du même employeur, car souvent pour rester on doit s’en éloigner et faire de la politique.

Chapitres 9 à 11 : Le recrutement

Le chapitre 9, Recruitment, se focalise sur le recrutement des Software Craftsmen. Bourré d’exemples de choses à faire et à ne pas faire, avec un focus particulier sur les descriptions de poste et sur comment filtrer les candidats avant l’entretien.

Le chapitre 10 et 11, Interviewing Software Craftsmen et Interview Anti-Patterns, se focalisent sur les entretiens d’embauche, respectivement sur comment les mener et quelles sont les choses à éviter. Le point de vue côté candidat est également abordé : ces entretiens servent aussi bien à l’entreprise ou au client pour jauger un candidat, qu’au candidat pour jauger une entreprise ou un client. C’est une véritable négociation, dans les deux sens.

Le chapitre 10 donne également beaucoup de conseils sur l’utilisation du pair-programming en entretien, ce qui semble être la logique-même pour le recrutement d’un développeur.

Chapitres 12 à 14 : Redonner la motivation à des développeurs

Le chapitre 12, The Cost of Low Morale, explique à quel point le moral des développeurs est essentiel. Avec des développeurs qui manquent de motivation, rien ne se passera. Il faut des développeurs passionnés.

Les chapitres 13 et 14, Culture of Learning et Driving Technical Changes, proposent de redonner la passion à des développeurs qui l’ont perdu. Comment ? En mettant en place une véritable culture de l’apprentissage. Les chapitres donnent beaucoup de trucs et de techniques pour l’insuffler et démarrer le mouvement.

Le chapitre 14 se focalise particulièrement sur comment convaincre les personnes, en fonction de leur typologie de caractère. Le tout truffé, comme toujours, d’anecdotes jouissives à lire et tellement criantes de vérité.

Chapitre 15 : Le logiciel n’est qu’un outil

Le chapitre 15, Pragmatic Craftsmanship, fait le tour des pratiques communément admises dans le développement logiciel qui en fait desservent le client, comme la traditionnelle architecture logicielle construite en amont et qui essaie de tout prévoir, le Big Design Up Front. Le développeur se doit de se rappeler que le logiciel n’est pas la finalité, c’est un outil pour construire un produit ou atteindre un besoin métier ! L’architecture logicielle se doit donc d’aller au plus simple.

Plus globalement, le pragmatisme est au cœur et à la base du mouvement et de sa philosophie.

Chapitre 16 : Développeur est une carrière à part entière

Le chapitre 16, A Career as a Software Craftsman, décrit que Craftsman c’est une carrière à part entière. Être un développeur de premier ordre, cela demande toute une vie. Devenir un meilleur développeur, c’est un vrai choix de carrière, à opposer à un changement de carrière en devenant par exemple manager, architecte ou chef de projet.

Conclusion sur le livre

Je vais revenir à nouveau sur le sous-titre :

Professionalism, Pragmatism, Pride

Professionalism : le Craftsman fait preuve de beaucoup de professionnalisme, fait en sorte d’avant tout répondre au besoin du client. Également, comme tout professionnel, il va s’assurer de rester à jour mais aussi de partager.

Pragmatism : le développement logiciel est une activité complexe. Inutile donc d’en rajouter, il faut au contraire favoriser la simplicité et être pragmatique dans toutes ses décisions. Le Craftsman est là pour répondre à un besoin du client, pas pour se faire plaisir.

Pride : le développement logiciel est avant tout une question de passion. La fierté que pourra retirer le Craftsman de son travail est donc une composante essentielle. C’est ce qui va le pousser à toujours s’améliorer, à partager, mais aussi à donner son maximum pour répondre au besoin du client.

Conclusion personnelle

À titre personnel, je retire plusieurs choses de la lecture de ce livre.

Tout d’abord, et comme je l’ai dit en introduction, cela m’a réconcilié avec le nom du mouvement. Je n’ai plus de scrupule à parler de Software Craftsmanship quand j’évoque ces développeurs qui maîtrisent le TDD et qui ne perdent jamais de vue la vision produit.

Ensuite ce livre m’apporte divers outils qui me sont et seront utiles dans mon quotidien de facilitateur, par exemple :

  • Comment convaincre de l’intérêt des bonnes pratiques de développement
  • Comment parler à des développeurs
  • Comment aborder l’Agilité et une transformation Agile en prenant en compte les problématiques techniques

Enfin cette lecture me conforte dans l’idée que je dois avoir les mains dans le code si je veux continuer de tenir une casquette de coach technique. J’en suis plus sûr que jamais : je n’aurai plus la légitimité nécessaire pour expliquer à des développeurs comment faire leur travail, si je ne suis pas développeur moi-même. Un choix de carrière s’impose donc…

À propos de Jean-Pierre Lambert

Avant, j’étais un ingénieur logiciel. Mais peut-être pas le genre que vous imaginez ; les outils et les belles architectures logicielles me laissaient de marbre. Non, mon truc, c’était plutôt la qualité, la valeur produit, les process et les relations humaines.

Du coup, maintenant, j’aide les équipes en tant que Facilitateur Test et en tant que Scrum Master. Ce n’est pas plus mal !

J’espère vous revoir très bientôt sur ce blog pour la suite de mes aventures…

Laisser un commentaire

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

Top