Licence CC BY-SA

Qu'est-ce que le Software Craftsmanship ?

Une question de fierté

Il y a quelques années, @SpaceFox a publié dans cette tribune un billet à propos du célèbre texte Software Disenchantment. Dans les commentaires de ce billet, une notion particulière a retenu mon attention : celle de Software Craftsmanship. Je me rappelle à l’époque avoir cherché rapidement des ressources pour comprendre ce mouvement, mais n’avoir pas creusé beaucoup plus loin que la Page Wikipedia.

Depuis quelques mois, je traverse une période de grande sérénité professionnelle. En effet, j’ai fini de rembourser ma dette technique1 : mon code est testé avec un coverage important, ses tests tournent dans une CI qui automatise sa publication, il est déployé au moyen de commandes simplissimes (en deux mots: make deploy), et il est entièrement observable au moyen de métriques et de logs que je peux exploiter avec une facilité enfantine dans Grafana. Tout est sous contrôle.

Pour améliorer encore le système sur lequel je travaille, je dois maintenant descendre beaucoup plus profond que cela : je dois améliorer la façon dont je travaille dessus, de manière à ne plus avoir besoin de contracter à nouveau une dette technique, et produire à l’avenir le meilleur travail dont je suis capable en livrant le plus efficacement possible les fonctionnalités dont mes utilisateurs ont besoin. C’est dans cet état d’esprit que j’ai entrepris d’étudier une poignée de livres liés au Software Craftsmanship.

Ces lectures m’ont permis de revivre toutes les expériences que j’ai vécues dans ma carrière avec un œil nouveau, et d’en tirer de nombreux enseignements pour aborder les années qu’il me reste à exercer ce métier.

Dans ce billet, je vais résumer et partager avec vous quelques concepts importants que mes réflexions m’ont amené à revoir.

  1. Je vois déjà des sourcils se lever. Sachez que ce n’est pas un exploit. Le projet sur lequel je travaille est un projet "green field", démarré depuis 0 il y a un an et demi. Ce n’est pas tant le fait que j’ai réussi à la rembourser entièrement, que le fait que cette dette ait existé qui devrait retenir votre attention.↩

Que signifie « craftsmanship » ?

Le « Craftsman » de Richard Sennett

La notion de craftsmanship sur laquelle ce billet repose est celle de Richard Sennett dans son livre The Craftsman, et celle-ci est particulièrement large : c’est le fait de considérer le travail bien fait comme une fin en soi. D’aucuns seraient tentés de traduire le terme en français, en partant du principe qu’un craft est un artisanat. Ce serait faire fausse route ici.

Si vous tenez vraiment à traduire le terme craftsmanship, alors le mot le plus proche que j’aie à vous proposer dans notre langue, c’est professionalisme. Mais ce n’est pas tout à fait ça non plus.

Le Craftsman de Richard Sennet désigne aussi bien :

  • le maître ébéniste qui enseigne le métier à ses apprentis dans son atelier,
  • la technicienne de laboratoire qui fait le choix de rester tard le soir pour disséquer des cobayes qui n’auraient pas dû décéder et comprendre si c’est la procédure qui est mauvaise ou si elle a été mal appliquée, alors qu’elle pourrait se contenter du rapport qu’elle a déjà envoyé à sa hiérarchie,
  • la violoniste qui répète ses gammes encore et encore, heure après heure, jour après jour, année après année, afin de faire pénétrer et garder dans ses mains la justesse du ton et la finesse du jeu que l’on attend d’elle,
  • les développeurs d’un projet Open Source comme le noyau Linux, qui échangent, affûtent leurs compétences et leurs pratiques en partageant leurs découvertes avec une communauté dont le travail collectif garantit une qualité logicielle avec laquelle peu d’entreprises peuvent rivaliser.

Il ne s’agit donc pas que des métiers manuels ou artisanaux. Richard Sennett parle aussi bien dans son livre des exemples que je viens de donner que des docteurs et des infirmières, des architectes et des urbanistes, des ingénieurs, des cuisinières, des souffleuses de verre, des briquetiers ou des forgerons. À son sens, l’éducation des enfants est également un craft.

Le livre s’attarde entre autres sur :

  • l’attitude de ces professionnels et leur fonction sociale,
  • leur relation avec leur atelier (ou plus généralement leur lieu de travail) au travers de l’histoire,
  • l’entraînement, la spécialisation, le fonctionnement de leurs "mains",
  • les écueils du perfectionnisme,

Il défend sur la question un point de vue matérialiste et pragmatique.

Tout peut se déduire logiquement de cette idée centrale : le travail bien fait est une fin en soi.

Ce n’est "qu’un" mot

Ce n’est qu’une idée. Une définition particulière du professionalisme. Ce n’est pas un culte. C’est juste une opinion.

Mais c’est une opinion que je partage.

Passion et discipline

Il y a vingt ans, alors que je traversais une tempête d’incertitudes à propos de mes études et mon avenir professionnel, mon père m’a sorti cet aphorisme :

« Pour faire ce que tu aimes, tu dois aimer ce que tu fais. »

Cette phrase m’a très longtemps hanté. J’ai toujours senti qu’elle énonçait une vérité bien plus profonde que ne le suggère sa formulation triviale. Mon père était cardiologue et il exerçait son métier en véritable craftsman. Il se tenait à jour de l’avancée des recherches, participait à des congrès, prenait souvent du temps jusque tard le soir pour rédiger sa correspondance avec ses consœurs et confrères, et avait à cœur d’agir, à tout instant, en professionnel dans l’intérêt de ses patients. Il suffisait que l’on déclare à table "j’ai comme un point de côté depuis hier soir" pour voir immédiatement son regard changer : c’était le père de famille qui switchait en mode médecin. En bref, mon père était quelqu’un de passionné par son métier, et cette phrase venant de lui n’avait rien d’anodin.

De loin, cette phrase fait écho à une notion plutôt à la mode en psychologie du travail : le sens au travail. En résumé, on ne peut s’épanouir au travail qu’à partir du moment où celui-ci a un sens pour nous. Sans trop entrer dans le détail de cette notion complexe en psychologie, cela signifie notamment que notre travail est aligné avec nos intérêts et nos valeurs professionnels. Et c’est bien naturel : pour s’infliger ce travail quotidiennement pendant la plupart de la journée, la plupart de la semaine, la plupart de notre vie, il est indispensable qu’il ait pour nous un sens qui dépasse la seule compensation financière. Si certains éléments (une relation toxique avec un collaborateur, des spécifications ou des normes complètement débiles, des processus qui accaparent tout notre temps, le manque de pouvoir pour arranger les choses…) viennent à se dresser entre nous et notre vision d’un travail utile et bien fait, alors celui-ci perd son sens et peut devenir une source de souffrances.

Dans le cas du craftsmanship, cela va encore plus loin que le sens du travail : notre métier est bien plus qu’un travail ; c’est une passion. Lorsque l’on est passionné par le développement, on ne compte pas les heures à faire de la veille : ça nous intéresse à la base, que l’on soit au bureau ou non, de découvrir des nouvelles techniques et technologies, de partager avec diverses communautés, d’améliorer nos pratiques. On se préoccupe et on en prend soin de notre code, car il y va de notre réputation, et parce qu’à nos yeux les problèmes que nous résolvons sont passionnants. Ce métier coule dans nos veines.

Cependant, être passionné est une condition nécessaire, mais pas suffisante pour se comporter en craftsman, car le travail bien fait exige que notre passion soit canalisée par une discipline tout aussi grande. Cette discipline, on l’exhibe notamment lorsque l’on s’entraîne en codant sur des projets-jouets pour nous former à une nouvelle stack ou de nouveaux outils, lorsque l’on ne fait pas l’impasse sur la qualité de notre code ni sur ses tests malgré la pression et le stress, ou encore, lorsque l’on ne joue pas au héros en revoyant nos estimations à la baisse pour éviter un conflit avec notre manager, mais que l’on négocie avec lui des solutions alternatives pour livrer le meilleur travail possible à nos clients, à la date voulue.

Cette discipline, c’est celle qui nous impose également de chercher un équilibre sain entre travail et vie privée, sans lequel on ne peut pas rester performant sur le long terme.

Si passion et discipline sont nécessaires, c’est parce qu’ils se complètent : la passion sans discipline résulte en un travail d’amateur auquel on ne peut pas se fier, mais la discipline nécessaire à devenir un excellent professionnel ne peut être atteinte que du moment que nous sommes passionné pour ce que l’on fait. Nous exerçons un travail hautement qualifié : pour acquérir nos compétences, il faut les vouloir ! Pour écrire du code toute sa carrière, il faut aimer ça.

Ramené à l’aphorisme de mon père : pour « faire ce que l’on aime », un travail dont on tire du sens et de la fierté, on doit « aimer ce que l’on fait », en nourrissant pour notre métier une passion telle qu’elle contrebalance le temps et les efforts que l’on concède à l’affûtage de notre discipline professionnelle.

Ce sont essentiellement cette passion et cette discipline que nous transmettons aux jeunes professionnels qu’il nous est donné d’encadrer et de former pendant notre carrière.

Pragmatisme

Le pragmatisme dont il est question ici s’oppose aux deux principaux écueils qui font obstacle au travail bien fait : le dogmatisme d’une part, et l'obsession perfectionniste d’autre part.

Le dogmatisme, c’est le fait de camper sur des vérités que l’on ne remet jamais en question, et que l’on considère comme absolues, à la manière de dogmes religieux ou idéologiques. Chez nous, développeurs, il se révèle au travers de phrases comme :

  • Tout nouveau système doit être architecturé en microservices et pas autrement,
  • Les variables globales, c’est le mal,
  • [C#/Java/Go/Python/C++/Rust/…] est un bien meilleur langage que [C#/Java/Go/Python/C++/Rust/…],
  • Si tu ne fais pas de [TDD/pair programming/…], alors tu ne peux pas faire du bon travail.

Le danger, ici, n’est pas tellement de penser "des choses fausses".

Le danger, c’est de les penser pour les "mauvaises raisons".

Le pragmatisme nous impose de raisonner dans un contexte, en ayant l’esprit assez ouvert pour remettre en question nos croyances établies, de manière à ce que lorsque nous nous retrouvons face à une manière de faire objectivement meilleure que la nôtre, nous soyons en mesure de l’adopter. Aussi, si le mouvement du software craftsmanship promeut à l’heure actuelle les pratiques de la méthodologie XP (pair programming, TDD, simple design, …) c’est parce qu’à l’heure actuelle, la majorité des personnes qui s’identifient avec ce mouvement ne demandent qu’à faire mieux qu’avec ces pratiques dont ils font la promotion : si demain on nous montre une façon plus efficace d’écrire du code fiable que le TDD sur un projet donné, alors l’attitude professionnelle est de s’y essayer et d’être en mesure de l’adopter sur le projet si c’est utile.

L'obsession perfectionniste, de son côté, est plus traître. On peut facilement la confondre avec la passion, ou le goût du travail bien fait.

On est perfectionniste quand on ne sait pas quand il faut s’arrêter.

Ou quand on refuse de travailler avec du code legacy, parce qu’on n’a pas envie d’être tentés de le récrire entièrement : c’est perdre de vue l’intérêt de nos clients car la quantité d’effort que l’on dépenserait à récrire ce code qui existe déjà, pour ne rien faire de plus ni de mieux, n’est pas justifiable du point de vue de l’utilisateur. Comme le dit un dicton célèbre : le mieux est l’ennemi du bien.

L’une des façons dont le pragmatisme et la discipline s’opposent au perfectionnisme dans notre métier est par exemple la règle du boy scout : « il faut toujours laisser le code un peu plus propre qu’on ne l’a trouvé »1. Cela s’applique particulièrement au code legacy : si cette masse de code est moche et pas testée, plutôt que de la reconcevoir entièrement à partir de zéro, notre challenge est déjà d’extraire la partie du code avec laquelle nous avons besoin d’interagir dans l’immédiat pour la couvrir de tests et la refactoriser, comme une partie intégrante du ticket sur lequel nous travaillons. C’est peu, mais c’est déjà quelque chose, et faire quelque chose qui va dans le bon sens est toujours mieux que ne rien faire du tout, car ces petites touches d’amélioration s’accumulent avec le temps. Les chances que ce code ne soit pas testé car il n’a pas été écrit pour être testable sont relativement élevées, mais est-ce vraiment pour nous laisser vaincre d’avance par ce genre de défis que nous faisons ce boulot ?

  1. Chez les scouts la vraie règle est « il faut toujours laisser le camp un peu plus propre qu’on ne l’a trouvé ». Et cela fait écho au discours d’adieu de Baden-Powell : « puissiez-vous laisser le monde un peu meilleur que vous ne l’avez trouvé ».↩

Se regarder dans le miroir

Many Agile projects are now, steadily and iteratively, producing crap code.

Sandro Mancuso2

Aucun développeur ne se lève le matin en se disant : « Quelle belle journée pour écrire plein de bugs et saloper mon projet ! ». Aucun manager ne se lève non plus le matin en se disant : « Quelle belle journée pour emmerder le monde et reprocher à mon équipe de ne pas avoir réussi l’impossible ! ». Et pourtant, les développeurs qui écrivent des bugs, les projets qui finissent salopés, les managers qui emmerdent le monde et qui demandent l’impossible à leurs équipes, il suffit de taper dans le premier arbre venu pour en être recouvert !

Cette situation est absolument regrettable. Pour espérer la changer, il nous faut la comprendre, et c’est une situation complexe. Si les projets finissent salopés, ce n’est pas uniquement la faute des développeurs, ni uniquement celle de leur hiérarchie. Les responsabilités sont partagées, et il importe que tout le monde prenne le temps de réaliser un examen approfondi dans le miroir. Ce n’est que de cette manière que chacun peut se mettre à assumer ses responsabilités et contribuer à relever la barre.

Au minimum, il importe que nous autres, développeurs, réalisions cet examen de conscience, afin de cesser de gesticuler comme des amateurs, et garder en tout temps la satisfaction et l’assurance de nous être comportés en professionnels irréprochables, même si cela veut dire mettre fin à une collaboration, ou encore plus extrême, de tenir face à un employeur qui nous menace de nous licencier1. De toute façon, pour paraphraser Sandro Mancuso2, dans le contexte économique actuel, « seuls les mauvais développeurs ont peur pour leur job ».

Sommes-nous traités comme des professionnels ?

Imaginons que vous soyez admis aux urgences suite à un accident. Disons, juste pour l’exemple, que vous vous êtes fait une entaille profonde qui nécessite quelques points de suture. Est-ce que cela vous viendrait à l’esprit de d’ordonner aux infirmières d’arrêter de se laver les mains pour vous recoudre le plus vite possible ? Est-ce que vous ne trouveriez pas ça encore plus dingue si c’était le médecin urgentiste, plutôt que vous, qui demandait aux infirmières d’arrêter de perdre du temps et de se dispenser de stériliser votre blessure ?

Ou encore imaginons que vous fassiez construire une maison. Est-ce que vous trouveriez normal de marchander le bout de gras avec le conducteur de chantier pour qu’il réduise son estimation des délais en sautant le temps de séchage de la dalle de béton qui constitue les fondations ?

Non, bien sûr, personne ne ferait ça : les infirmières, les médecins, les conducteurs de travaux et les artisans qui construisent nos maisons sont des professionnels. Ils connaissent leur métier mieux que quiconque, et ce n’est certainement pas à nous de leur dire comment faire leur travail.

En tout cas ma mère était infirmière, et personne ne lui parlait sur ce ton.

Comment expliquer, dans ce cas, que j’aie déjà eu un manager qui m’a demandé, un nombre incalculable de fois :

  • De ne pas perdre de temps à "faire propre et refactoriser" parce que c’est "pour la semaine prochaine, pas dans un mois" ?
  • De ré-estimer une tâche en excluant l’écriture des tests ?3
  • De "faire au plus vite", comme si je ne faisais pas déjà de mon mieux d’ordinaire pour livrer le plus tôt possible ?

Comment expliquer que j’aie eu un N+2 qui s’enorgueillissait d’être "un pragmatique dans l’âme", et qui se mêlait des outils dont se servent les développeurs ("ok je veux bien que vous utilisiez gitlab à condition que toutes les équipes l’utilisent"), et qui nous interdisait ouvertement de pratiquer le TDD ou le pair programming ?

Tout cela porte un nom : c’est du micro-management, et si cela ne devait signifier qu’une seule chose, ce serait que nos supérieurs ne nous traitent pas comme des professionnels.

  • Un manager ou un client n’a pas à imposer leurs outils de travail à des développeurs. Ce sont nos outils. C’est nous que ça concerne. C’est à nous d’utiliser ceux grâce auxquels nous sommes les plus efficaces.
  • Un manager ou un client n’a pas à imposer ni interdire à des développeurs d’adopter une pratique ou une autre : cela ne le regarde pas, ce sont les développeurs qui font le boulot. Nous sommes responsables de nos pratiques. C’est à nous de choisir celles qui nous permettent de bien faire notre boulot.
  • Un manager ou un client n’a pas à imposer à ses développeurs de court-circuiter les tests qui garantissent la qualité du logiciel : c’est notre responsabilité, pas la sienne, et c’est un manque de professionnalisme vis-à-vis de notre équipe, parce que quand le logiciel pétera en production4, ce sera à nous d’assumer en écrivant quand même, mais cette fois dans l’urgence, les tests sur lesquels il nous avait demandé de faire l’impasse. Ce sont ceux qui assument quand ça foire qui sont responsables.

Un professionnel ne se plie jamais à ce genre de caprices. Le contraire serait aussi irresponsable de sa part qu’il serait criminel pour un médecin d’accepter de ne pas se laver les mains entre deux patients. La qualité logicielle, en dépit de ce que peuvent nous dire certains managers peu scrupuleux, n’est pas une option : elle est systématiquement attendue, coûte que coûte, par les utilisateurs. Un manager qui exige cela de nous est en train de tirer une balle dans le pied de toute la boîte, et nous avons le devoir de ne pas le laisser nous nuire collectivement : ni à nos clients/utilisateurs, ni à nous, ni à lui.

Dans une telle situation, il n’y a qu’une seule chose à faire : ne pas céder. Rester fidèles à notre discipline, et faire comprendre à notre manager qu’il dépasse une limite et que ses demandes ne sont ni raisonnables, ni acceptables. En d’autres termes, lui faire comprendre que ce qu’il demande n’arrivera jamais, et lui proposer soit de repousser ses deadlines, soit de négocier ensemble, avec le client, un scope réaliste. Ou encore, lui répondre un non ferme et définitif, puis chercher avec lui des alternatives. Nous partageons un même but : celui de satisfaire le même client.

… Malheureusement, face à ces demandes surréalistes, il nous arrive parfois de pousser un soupir et céder : « ok, je vais essayer », et c’est alors le début de la fin. Mais là, ce n’est plus seulement le manager qui est en cause.

Nous comportons-nous comme des professionnels ?

Il y a long à dire sur ce « je vais essayer » que l’on a tous répondu au moins une fois dans notre carrière. Des gens comme 'Uncle Bob' Martin5 et Sandro Mancuso2 l’ont déjà fait bien mieux que je n’en suis capable. Je me bornerai donc à dire que ce « je vais essayer » est la chose la moins professionnelle à répondre à un manager qui nous met la pression, nous cajole, nous bullshite en nous promettant une refacto après la release, et essaye tous les stratagèmes possibles pour faire entrer nos deux mois d’estimations dans un délai de trois semaines.

Cette réponse, c’est celle de quelqu’un qui joue les héros. Je vais éclater ce truc en deux fois moins de temps que prévu, ça va sauver le projet et ça sera bon pour mon avancement. Foutaises !

Ce que cette réponse envoie comme signal au manager ou au client, c’est qu’on en avait "gardé sous la pédale" jusqu’à maintenant, et que l’on ne travaille pas déjà, d’ordinaire, en faisant de notre mieux. Ce par quoi elle se traduit dans la réalité, c’est une gigantesque pression. Ce sont des heures supplémentaires à la pelle que nous nous infligeons, à travailler dans un état de fatigue trop avancé pour que l’on puisse écrire autre chose que du code pourri.

Et si, par un jour d’éclipse, on arrivait à tenir cette deadline impossible, vous croyez que le manager nous donnerait une claque dans le dos, et qu’il demanderait à toute la boîte de s’arrêter un instant pour nous applaudir ? Pour avoir réussi à faire notre travail, pour une fois ?

Est-ce que tenir une deadline ne devrait pas aller de soi, pour vous ? Si seulement on vous en donnait les moyens ?

Prenons le temps de méditer sur ces mots de maître Yoda :

Do, or do not. There is no try.
Do, or do not. There is no try.

Si nous nous engageons sur une date, alors nous refusons de ne pas la tenir. Dans ce cas, il vaut mieux pour tout le monde que nous ne nous engagions jamais sur un résultat que nous ne sommes pas absolument certains de tenir. Quand nous nous engageons, nous livrons. C’est une question de fiabilité.

Si nous savons que cette tâche ne peut pas tenir dans le délai que l’on nous demande, c’est qu’elle ne peut pas, le prix à payer pour la faire tenir dedans, il est de notre poche, et nous ne voulons pas nous tirer cette balle dans le pied.

Soyons honnêtes avec nous-mêmes deux minutes.

  • Si vous embauchez un avocat pour qu’il vous aide à régler vos problèmes légaux, quelle tête feriez-vous s’il vous répondait « OK, mais en plus de mes honoraires je veux que tu m’achètes un ou deux livres de droit. » ?
  • Si vous subissiez une opération à cœur ouvert, que diriez-vous si le chirurgien se mettait à crier des « WHAT THE FUCK?! » alors qu’il vient de vous ouvrir, ou encore se mettre à râler, peut-être en balançant des ustensiles au travers du bloc opératoire, après sa hiérarchie qui fait n’importe quoi, après la deadline à laquelle il doit avoir fini de vous opérer, et après l’état de votre valve mitrale qu’il faudrait retaper entièrement après l’avoir "cramée au lance-flammes" parce qu’il n’y a plus rien à en tirer ?
  • Si vous embauchez un couvreur pour qu’il vienne refaire votre toiture, est-ce que vous accepteriez qu’il vous en recouvre un bout avec les dernières tuiles à la mode (qui ne vont pas du tout avec le reste de la toiture) "parce qu’il a envie d’essayer la techno" ?

Alors pourquoi les gens devraient-ils accepter ce genre de comportement de la part des développeurs ?

Que notre employeur nous forme sur les technologies dans lesquelles il a investi, c’est normal. Mais est-ce que ce sont sur ces technologies que nous voulons nous former, nous ?

Auriez-vous envie de nous retrouver dans une situation où vous devriez demander à votre employeur de vous former pour que vous puissiez partir de chez lui ? Si vous voulez quitter cet employeur, ce serait quand même dommage de dépendre de lui pour ça, vous ne pensez pas ?

C’est pour ça que nous nous tenons à jour. C’est pour piloter notre carrière.

Chaque fois que nous nous reconnaissons dans les exemples que je viens de citer, nous nous souvenons d’une situation où nous ne sommes pas comportés en professionnels. Admettons que nous ne nous serions pas traités nous-mêmes comme des professionnels à la place d’un client ou d’un manager.

Alors, quand certains supérieurs se mettent à nous micro-manager, c’est aussi en partie parce qu’on leur tend le bâton pour se faire battre : si vous n’entrez pas dans le détail à parler de pair programming avec votre manager (que cela ne concerne pas), il n’y a aucune chance qu’il vous interdise de le pratiquer et ça devient votre problème, tant que ça vous aide à livrer du bon travail en temps et en heure.

De la même manière, si vous considérez que les tests font partie du ticket et que leur existence va tellement de soi qu’ils ne méritent même pas d’être un item dans une checklist, alors personne ne viendra vous dire de faire l’impasse dessus ou de les remettre à plus tard. Pourquoi tenter le diable ?

Si nous ne voulons pas être micro-managés, alors comportons-nous comme des pros et gardons ce niveau de détails pour nous. Nous-mêmes, plus que quiconque, comprenons les bénéfices de l’encapsulation dans notre code : c’est la même chose ici.

La "gueule de bois Agile"

J’ai une fois aidé une société pour laquelle je travaillais à adopter une méthodologie Agile. Lorsque j’ai démissionné un an et demi plus tard, j’en étais arrivé à haïr SCRUM.

J’étais perplexe : qu’est-ce qui a bien pu foirer ?

On avait une pièce dédiée avec un grand tableau blanc sur lequel on faisait bouger des étiquettes colorées. On faisait religieusement notre standup tous les jours. On faisait tout by the book, comme il fallait. On faisait tous de notre mieux pour limiter les réunions au strict nécessaire, pour que nos communications soient efficaces.

Et on s’enlisait quand même.

Les échecs s’accumulaient. On ratait des deadlines, on continuait à prier pendant les déploiements. L’environnement de développement était devenu un marécage radioactif truffé de modifications manuelles. On remplaçait le code legacy par du code qui devenait legacy encore plus rapidement. Le code mort s’accumulait. On avait le goût de l’échec dans la bouche en nous brossant les dents le matin.

Alors on les serrait. On bougeait encore plus frénétiquement nos étiquettes colorées sur notre grand tableau blanc. Mes collègues démissionnaient les uns derrière les autres. SCRUM nous avait trahis en rendant les choses encore pires.

C’est ce que l’on appelle la "gueule de bois Agile" (the Agile hangover2).

Ce qui a foiré, c’est que SCRUM n’est qu’une méthodologie, pas un remède miracle et qu’Agile ne se résume pas à des méthodologies : Agile est une philosophie. On ne fait pas "du Agile". On est Agile ou on ne l’est pas.

Ce qui a foiré, c’est que pour qu’une méthodologique comme SCRUM fonctionne, il y a des prérequis. Et l’un de ces prérequis est l’excellence de l’équipe : SCRUM fonctionne à merveille quand chaque développeur de l’équipe est traité comme professionnel et se comporte en tant que tel, quand l’équipe a le pouvoir (et l’exerce dans la pratique) de s’améliorer, de s’entraider, de s’engager. Si le planning se conclut par un "on va essayer" de la part de l’équipe, le sprint est mort-né.

Si les développeurs ne sont pas responsables de leurs outils et de leurs pratiques, alors :

  • ils ne peuvent plus garantir la qualité du code,
  • il ne peuvent plus s’engager sur des deadlines,
  • ils ne peuvent plus améliorer le code en continu et maintenir son hygiène,

… et ils livrent, itérativement et progressivement, du code de merde.

Autrement dit : avant de jeter du SCRUM sur nos problèmes, commençons par nous comporter en professionnels, sans quoi SCRUM ne fera qu’empirer les choses.

  1. Il faut prendre ce passage avec des pincettes. Tout le monde n’est pas en mesure de tenir tête à un employeur abusif. Par contre, subir ce genre de violence et s’y plier de la part d’un employeur, c’est l’assurance que cela recommencera, et donc que vous vous trouvez dans un poste particulièrement toxique que vous n’allez pas pouvoir garder longtemps. Ou alors au détriment de votre santé.↩
  2. The Software Craftsman: Professionalism, Pragmatism, Pride, Sandro Mancuso, éditions Prentice Hall.↩
  3. Comme je regrette aujourd’hui de ne pas avoir pratiqué le TDD plus tôt ! J’aurais adoré voir sa tête, quand, avec tout le sérieux et la bonne foi du monde, je lui aurais annoncé 20% de délai supplémentaire pour finir la fonctionnalité sans écrire les tests.↩
  4. Et s’il vous manque les tests, vous le savez comme moi, ça va se casser la figure en production.↩
  5. The Clean Coder: A Code of Conduct for Professional Programmers, Robert C. Martin, Pearson Education ↩

Il y aurait encore des tas de choses sur lesquelles je pourrais écrire. Notamment sur ce que cela implique en termes de recrutement, sur les pratiques que l’on peut adopter…

Mais vous, qu’est-ce que vous pensez de tout ça, déjà ?

41 commentaires

Il y a des points qui me gênent dans ton billet, et je ne sais pas s’ils sont annexes ou non :

  • Tu parles globalement de zapper le droit à la déconnexion, ou de ne pas compter ses heures. C’est peut-être ma volonté très progressiste, mais je ne suis vraiment pas pour cette idée. Pour moi, on doit pouvoir quitter son travail comme prévu (de préférence à 17h, vu qu’on est censé être aux 35h) et arrêter d’y penser. Si une expérience labo a foiré, on ne devrait pas se retrouver tard le soir pour étudier pourquoi ça a foiré, ça devrait être prévu en amont comme éventualité.
  • Tu parles de ne pas céder quand on te menace de te virer, de la responsabilité du développeur face à un manager intransigeant. Je ne suis pas d’accord du tout. Personne ne réagit de la même manière face à ce genre de menaces, et on ne peut pas blâmer quelqu’un de ne pas réussir à faire face à un management problématique. C’est une situation psychologiquement très dure.
  • Je ne suis pas d’accord non plus sur la question de la formation, et c’est d’ailleurs dans la loi française. C’est ton employeur qui doit te permettre de te former. J’ai eu l’impression que c’était sous-entendu également, et ça a été mentionné plus tôt je crois : se former soi-même sur son temps libre. C’est également quelque chose que je refuse. La veille, ça fait partie de mon boulot, les nouvelles formations aussi. Je ne pense pas que ça devrait me manger plus de temps libre que ce que me prend déjà mon travail.

Edit : En fait, tu présentes une abnégation forte à son travail, appliquée au cas du développeur informatique. Et je ne dis pas, je trouve ça beau comme démarche, mais ce n’est pas pour autant quelque chose que je chercherais à encourager et encore moins à définir comme le "normal".

(Par ailleurs, mais c’est du détail, l’exemple du bâtiment est pas forcément bien choisi :p )

+9 -0

Salut. Je pense que tu passes complètement à côté de mon propos en me faisant dire des choses que je n’ai ni dites, ni pensées.

Tu parles globalement de zapper le droit à la déconnexion, ou de ne pas compter ses heures

Non. Je ne parle pas de zapper le droit à la déconnexion. Je parle de l’état d’esprit que l’on a quand on est passionné par son travail. Le droit à la déconnexion, c’est autre chose, il est irrévocable.

D’ailleurs, la discipline que je dresse en parallèle de cette passion implique de savoir ne pas répondre en dehors des heures de travail, et trouver un équilibre correct entre travail et vie privée. Je suis passionné par mon travail, mais ce n’est que mon travail. Il ne se substituera jamais à ma vie de famille ni au temps que je passe avec ma femme et mes enfants, ce qui invalide complètement ta remarque sur l’abnégation. Ce n’est pas de l’abnégation : c’est considérer qu’une prestation professionnelle de haute qualité est une fin en soi.

Il n’en est pas moins que quand j’ai un bug ou un système particulièrement ardu à faire manger à mon cerveau, j’y pense, j’y réfléchis, et le lendemain à 9h00 j’arrive avec une solution. Je ne le présente pas comme une norme, je le présente comme un état de fait. Je suis comme ça, et aucune loi ne changera ça.

Tu parles de ne pas céder quand on te menace de te virer, de la responsabilité du développeur face à un manager intransigeant. Je ne suis pas d’accord du tout. Personne ne réagit de la même manière face à ce genre de menaces, et on ne peut pas blâmer quelqu’un de ne pas réussir à faire face à un management problématique. C’est une situation psychologiquement très dure.

C’est précisément parce que ce genre de situation est une violence que l’on peut subir qu’il faut s’armer pour la traverser. Et quelle que soit notre façon de réagir : on supporte mieux ce genre de situation lorsque l’on ne doute pas d’avoir fait ce qu’il fallait.

Si on finit par s’y plier pour d’autres raisons, notamment économiques et personnelles, ça nous regarde. Mais dans ce cas, il faut être conscient que l’on pourra de toute façon pas longtemps continuer à exercer notre métier sous une hiérarchie qui nous soumet à ce genre d’agressions.

Je ne suis pas d’accord non plus sur la question de la formation, et c’est d’ailleurs dans la loi française.

Encore une fois, tu brandis une loi sans regarder ce qu’il y a derrière mon propos. Si un employeur potentiel m’offre avec le poste des jours de conférence, du temps d’exploration et globalement du temps pour que l’équipe de développeurs s’améliore et se tienne à jour, c’est très bien, c’est un employeur qui prend soin de ses développeurs et qui crée un environnement sain, et tout le monde y gagne.

Mais je n’attends pas après ce genre de postes pour me former.

Ce ne sont pas mes employeurs qui pilotent ma carrière. C’est moi.

On ne parle pas du DIF, là. On parle d’investir une partie des revenus conséquents que nous procure notre métier dans notre carrière.

+0 -0

Merci pour ton billet !

Il est fort intéressant et me fais me remettre en question. Notamment avec les analogies que tu exploite avec d’autres métiers.

Pour moi qui suis en début de ma vie professionnel cela m’est très utile.
J’ai vu lors de certains recrutement les entreprises qui incite les développeurs à ne pas se comporter en tant que professionnel, cependant, c’est cohérent avec le reste des l’organisation (micro-management, faire de l’Agil, …).
Je pense que la philosophie n’est pas la bonne, qu’ils essayent d’appliquer la méthode à la lettre coûte que coûte sans vouloir non plus lâcher certaines habitudes qu’ils ont, tels que le pouvoir décideur des manageur (car la méthode SCRUM permet une plus grande autonomie et liberté au développeur). De ce fait, on reste dans un entre-deux de deux méthode qui, parfois, rentrent en conflit.

A présent, je vais me remettre en question dans mon travail et devenir un professionnel !

+0 -0

Merci pour ce chef-d’œuvre nohar !

J’ajouterai deux trois choses annexes qui ne sont pas couvertes par ton billet et qui peuvent peut-être découler sur une discussion :

  • tout l’enjeu ici réside à trouver un équilibre entre passion et contraintes économiques. Le fait est que le marché se contrefiche de nos passions ; à juste titre j’ai vu très peu de clients finaux qui ont salué la qualité du code / de l’architecture d’un projet ; pour eux tant que ça marche et que ça ne bogue pas, ça passe en général. Faut-il donc les éduquer sur ce sujet ?
  • Quel serait le contraire du craft ? J’aurais pensé à quelque chose d’« industriel », un peu froid et dénué de passion, qui ne possède peut-être pas la même qualité.

Pour moi, on doit pouvoir quitter son travail comme prévu (de préférence à 17h, vu qu’on est censé être aux 35h) et arrêter d’y penser.

C’est une généralité, ce genre de cas ne s’applique pas (ou très peu ?) aux cadres et aux gens comme nohar ou moi (au moins). Je parle pour les 35 h. Pour le reste, je pense que le PO a suffisamment étayé ses propos pour expliquer qu’il y avait un certain investissement de fond en dehors des heures de travail. Pas pour l’entreprise, mais pour soi.

+1 -0
  • Quel serait le contraire du craft ? J’aurais pensé à quelque chose d’« industriel », un peu froid et dénué de passion, qui ne possède peut-être pas la même qualité.

Source: Ge0

Le contraire du craft, comme tu le dit c’est l’«industriel».
Je pense à toute les entreprises qui montent des pole inovation constitué d’une armée de stagiaire et d’alternant en autonomie (pour ne pas dire laissé à l’abandon) à qui on demande le même niveau qu’un sénior et qui travaillent sur des projets CIR.

C’est très problématique car cela donne une fausse vision du travail et n’incite pas à se comporter comme un professionnel. En plus de pouvoir dégouter certaines personnes du métier, les apprentis n’apprennent pas car ils n’ont personne pour les guider.

+0 -0

juste titre j’ai vu très peu de clients finaux qui ont salué la qualité du code / de l’architecture d’un projet ; pour eux tant que ça marche et que ça ne bogue pas, ça passe en général. Faut-il donc les éduquer sur ce sujet ?

À quoi faudrait-il les éduquer ?

Tu le dis toi même : tant que ça marche et que ça ne bugge pas, ça passe. Donc il faut que ça marche sans bugger. Personne ne nous dira "merci" de faire du code de qualité. Le code de qualité va de soi. C’est pour avoir cette qualité de code qu’ils nous payent cher.

Elle est exigée comme un pré-requis pour le client. Et c’est également la seule façon dont on peut maintenir un projet en vie pendant des années.

C’est comme l’hygiène à l’hôpital. Cela va de soi. On ne paye pas un bonus à l’hôpital pour bénéficier d’un "supplément d’hygiène". On ne remercie pas les infirmières pour leur propreté. Ça fait partie de leur travail d’être propres. C’est leur responsabilité.

Quel serait le contraire du craft ?

Je pense que vous faites fausse route avec @pyoroalb en disant que le contraire du craft est "l’industriel". Le contraire du craft, c’est le travail salopé, dont on ne prend pas soin, et personne n’a (plus) rien à faire.

Le code industriel peut parfaitement être bien fait (well-crafted) : il suffit qu’il soit réalisé par de bons professionnels qui ont le contrôle sur leur craft (leurs outils et leurs pratiques).

+3 -0

C’est assez intéressant tout ce qu’on lit là, et c’est applicable très largement à d’autres domaines de l’ingénierie non logicielle selon moi.

J’ai l’impression que la chose qui sous-tend tout ça, c’est le principe de responsabilité. Responsabilité au sens de se sentir responsable et prendre en charge une mission, et pas dans le sens être responsable parce que quelqu’un l’a décidé. Quand on se sent responsable de quelque chose, on adopte pas du tout le même état d’esprit.

Quand on lit qu’il faut cacher les détails à son chef, c’est vrai, c’est le principe même de fournir une prestation peu importe à qui ; on est responsable du résultat, pas du moyen d’y parvenir (même s’il y a parfois des contraintes importantes à ce sujet). Seul ce qui est visible compte (même si c’est indirect comme la maintenabilité). Cela implique que les responsabilités de chaque groupe soient un minimum bien définies avec un bon périmètre, afin qu’ils puissent travailler ensemble efficacement pour faire quelque chose d’auto-contenu.

Là où les gens même de bonne volonté peuvent être embêtés, c’est quand la définition de l’organisation ne permet justement pas de faire ça facilement. Je suis passé d’une organisation où j’avais plus de marge pour me comporter en professionnel à une où tout est plus morcelé, et ça crée des difficultés pour tout. La moindre tâche nécessite de consulter la terre entière, et les équipes se retrouvent noyées le process, ce qui nuit au passage au temps nécessaire pour développer une plus grande maîtrise du métier.

+4 -0

C’est un avis intéressant que tu donne la mais je suis pour le moins partagé par la vision philosophique qui se dégage de ce billet.

Derrière l’image du bon professionnel comme décrit dans le billet, il y a surtout à mes yeux l’image du travailleur irresponsable qui ne pense pas la finalité sociale de ce qu’il réalise et qui obéie à la finalité choisie par ses maîtres (patrons, client, supérieurs, …).

Quant à l’injonction à aimer son travail qui est affirmé dans ce billet (et plus globalement dans l’ensemble de la société), cela me semble être un objectif irréaliste (d’un point de vue collectif) et derrière il y a l’idée de la non remise en cause du travail et des conditions socio-politique dans lequel il s’effectue.

Désoler pour cet avis de mauvais développeur fainéant et irresponsable :)

+3 -0

l’image du travailleur irresponsable qui ne pense pas la finalité sociale de ce qu’il réalise et qui obéie à la finalité choisie par ses maîtres (patrons, client, supérieurs, …).

Ce que tu décris, c’est précisément le animal laborans qu’Hannah Arendt identifie par exemple en la personne de Oppenheimer. C’est pile l’image à laquelle Richard Sennett oppose son craftsman dès son avant-propos.

À quel moment est-il écrit que je me moque de la finalité sociale de mon travail ? Je ne vois vraiment pas d’où on pourrait tirer cette idée de mon billet. C’est même plutôt l’inverse !

Quant à l’injonction à aimer son travail qui est affirmé dans ce billet

Il n’y a aucune injonction à aimer son travail écrite dans ce billet.

Tu coupes la phrase en deux là : dans "pour faire ce que tu aimes, tu dois aimer ce que tu fais", il y a "pour faire ce que tu aimes". À nous de savoir ce que nous considérons comme du travail bien fait, et si on le considère comme une fin en soi.

Si c’est le cas, alors le billet dit "voilà ce que l’on peut en déduire".

Si ce n’est pas ton cas, tant mieux pour toi. C’est ton point de vue. Ce n’est pas pour autant que je considère que tu réponds en développeur fainéant et irresponsable.

Par contre tu réponds à complètement autre chose que ce qui est écrit. Et c’est bien dommage.

+2 -1

Billet très intéressant, merci @nohar.

Cependant, autant je comprends les idées derrière, autant je me demande si c’est réellement toujours applicable. Ce que je précise par la suite peut se résumer par : la relation de confiance.

(Je balance des idées comme ça un peu déconstruites, mais c’est ce qui me vient en tête à la lecture du billet)

La difficulté de comparaison

Je pense que tous les secteurs de métiers n’ont pas forcément la même exigence qualité. Quand je vais chez le médecin, s’il me prescrit un traitement qui met en cause ma santé par négligence, je peut porter plainte et gagner le procès. Si j’embauche un développeur et qu’il me produit un nid a bugs par négligence avant de démissionner six mois plus tard, je vais avoir du mal à porter plainte.

C’est donc difficile de comparer les exigences de qualité d’un métier à un autre et ça rend certaines analogies du billet par toujours réalistes.

Les choix de recrutements

Faire confiance au professionnel dans ses outils, c’est aussi quelque chose de compliqué. Parfois le professionnel va me dire que mon logiciel doit absolument être codé en Rust (et c’est peut-être le meilleur choix technique). Mais il n’aura pas en tête le jour où il quittera mon entreprise et que je vais avoir du mal à recruter un dev Rust à un prix raisonnable pour mon budget.

La aussi il est assez difficile de se reposer entièrement sur le professionnalisme de l’autre partie.

Le danger de l’encapsulation

Comme mentionné dans le billet, le développeur va épargner des détails techniques (tests unitaires, outils, etc.) a son management, mais le management aussi épargne des détails commerciaux/opérationnels aux développeurs.

Le problème c’est que des deux coté, quand il y a conflit, il est assez difficile de faire confiance à l’autre partie qui n’a pas forcément conscience des enjeux globaux. La preuve en est qu’il existe des tas de produits à succès (coucou Php3) qui ne sont pas forcément des produits de bonne qualité. Là ou le développeur va refuser de s’y mêler, sa hiérarchie va voir une immense occasion de gagner de l’argent ^^ .

Excellence technique et débutant

Un débutant n’a pas forcément toujours assez d’expérience pour que son manager, ou même son tech lead lui fasse confiance les yeux presque fermés sur ses choix et sur son travail "professionnel". Etant donné que le billet présente l’excellence technique comme prérequis de réussite, est-ce qu’il faut en conclure que l’agilité se prête mal à une équipe mixte (débutants et expérimentés) ?

+5 -0

Je ne le présente pas comme une norme, je le présente comme un état de fait. Je suis comme ça, et aucune loi ne changera ça.

nohar

Justement, j’ai l’impression que ton billet dit bien plus que ça.

Je ne sais pas si c’est un problème de formulation de ton côté ou de compréhension du mien, mais moi je lis dans ton billet que pour être un bon développeur, quelqu’un de professionnel, un craftman, il faut fonctionner comme ça.

Je me considère comme tel, et pourtant quand je quitte mon travail je me refuse de continuer à y réfléchir, à garder le moindre bug en tête : je coupe la machine et toute la charge mentale associée s’éteint avec.
Le lendemain matin je reviens sur mes bugs et les redécouvre, avec un regard tout neuf sur la question parce que je les ai oubliés.

Et j’ai aussi été gêné par les autres points relevés par @moté, car à la lecture de ton billet je les comprends vraiment comme la norme pour faire bien son travail.

+2 -0
Ceci concernait une ancienne version du billet que j’ai mal interprétée, et n’est plus d’actualité

Comme dit plus haut dans les commentaires, je comprends vraiment ce billet, de la façon dont il est écrit, comme voici ce qu’est le software craftmanship et pour moi c’est un but à atteindre et pas comme voici comment moi je le vis. Si ton point était de faire passer le second message et pas le premier, pour moi tu as un problème de forme. En particulier, l’usage systématique du « nous » qui inclus de fait le lecteur dans ta réflexion et tes propositions influence très fortement la compréhension. Tu as aussi beaucoup de choses qui ressemblent à des prescriptions, etc.

Bref, je réponds dans la suite à partir de ce que j’ai compris du billet.

De mon point de vue, aimer le travail bien fait, réaliser du travail bien fait, c’est quelque chose de positif qui devrait être poussé – et pas seulement en informatique, c’est possible dans énormément de métiers, y compris des métiers qui ne peuvent pas être des métiers-passion.

Par contre, j’y vois deux remarques.

La première, c’est qu’il faut pourvoir définir ce qu’est le « travail bien fait ». C’est loin d’être trivial, surtout quand on est le nez dans le code et qu’on ne voit pas quelles sont les contraintes fonctionnelles et financières derrière (c’est fréquent de ne même pas avoir cette seconde information). Et donc en voulant bien faire, on tombe souvent dans le dogmatisme ou l’obsession perfectionniste décrits dans le billet. Parce que parfois, le bon choix c’est quelque chose qui se serait appelé une verrue dans un autre contexte (parce qu’on sait que l’élément va être repris sous peu, qu’il n’a aucune forme d’importance, ou au contraire que c’est primordial que ça fonctionne le plus vite possible quitte à repasser au propre plus tard).

La seconde, c’est le danger de devenir esclave de sa passion. Et ce qui me chagrine, c’est quand ce billet montre d’une façon que je perçois comme positive des points qui vont dans ce sens, et qui donc pour moi devraient être évités autant que possible. De mon point de vue, il n’est pas nécessaire d’être passionné pour faire du bon travail1 (même si ça peut aider) – et sur ce point, je suis en opposition totale avec la théorie décrite dans ce billet.

1: Point décrit explicitement dans le billet : «  Pour faire ce que tu aimes, tu dois aimer ce que tu fais. », « parce qu’à nos yeux les problèmes que nous résolvons sont passionnants. Ce métier coule dans nos veines », « Ce sont essentiellement cette passion et cette discipline que nous transmettons aux jeunes professionnels… » et surtout «  notre métier est bien plus qu’un travail ; c’est une passion. » et « Cependant, être passionné est une condition nécessaire, mais pas suffisante pour se comporter en craftsman, car le travail bien fait exige que notre passion soit canalisée par une discipline tout aussi grande. ». C’est du domaine de l’anecdote, mais j’ai eu les félicitations (et une demande de poursuite) sur une mission de gestion de projet qui m’a gonflée d’un bout à l’autre. Comme quoi il semblerait qu’on puisse faire du bon travail sans l’aimer.

De plus, je pense que le travail devrait être strictement séparé des autres activités (loisirs, vie de famille, etc). Et que l’une des difficultés du travail-passion, c’est précisément d’arriver à séparer ce qui est du domaine du travail du reste. Or, il me semble que la proposition du software craftmanship est plutôt l’inverse, et qu’elle encourage à penser en permanence à son travail-passion – en tous cas c’est ce que je comprends du billet.

J’ai l’impression que le billet mélange un peu deux points assez différents en réalité : la nécessite d’être passionné pour faire du bon travail d’une part, et la gestion d’un métier-passion d’autre part.

Je trouve assez inquiétant qu’autant de points soient présentés à la fois sous un jour que je perçois comme positif voire nécessaire (« Cependant, être passionné est une condition nécessaire, mais pas suffisante pour se comporter en craftsman »), tout en présentant autant de vocabulaire issu du champ lexical de l’abnégation. Le billet parle de « s’infliger une discipline », mentionne « les sacrifices nécessaires à l’affûtage de notre discipline professionnelle », etc.

Que l’on se passionne pour son travail ou que l’on fasse de sa passion un travail, c’est d’excellentes choses. Mais cela ne devrait jamais :

  • Être un prérequis pour un quelconque poste. Le besoin, c’est que la personne fasse bien son travail, et je persiste : elle n’a pas besoin d’être passionnée pour ça.
  • Être un prétexte pour attendre de la personne qu’elle travaille en dehors du travail (travail direct ou auto-formation).2 Si l’employeur a besoin qu’une tâche soit faite, il y met les moyens (embauches et/ou heures supplémentaires dûement payées). S’il a besoin de compétences, il les embauche ou permet à ses équipes de se former3.

2: J’ai entendu des gens dire « j’ai développé tel truc pour le boulot » un dimanche après-midi, hors heures supplémentaires explicitement demandées par l’employeur, de la part de personnes qui ont femme et enfant. Je n’arrive même pas à comprendre comment on peut en arriver là et encore moins comment on peut en tirer de la fierté. Si tu es passionné et que tu as une idée à une heure incongrue, tu peux la noter, c’est normal (et j’ai eu d’innombrables idées pour le boulot en étant aux toilettes, sous la douche, dans les transports). Ce qui l’est moins, c’est d’implémenter cette idée en dehors de tout cadre.

3: À ce sujet, l’exemple de l’avocat qui demanderait qu’on lui paie des livres de droit est mauvais pour deux raisons. La première, c’est qu’on lui paie effectivement sa formation continue, puisque qu’il va se servir d’une partie de ses honoraires pour ça. La seconde, c’est que c’est une profession libérale, donc qu’on l’embauche pour ses compétences déjà acquises – ou qu’on attends qu’il les acquièrent sur ce qu’on lui paie. La situation n’est pas comparable avec celle d’un employé déjà embauché. Elle le serait plus avec un freelance, qui effectivement ne peut pas trop se permettre de dire « j’accepte la mission si tu paies la formation ».

Et donc j’appuie ceci :

Pour moi, on doit pouvoir quitter son travail comme prévu (de préférence à 17h, vu qu’on est censé être aux 35h) et arrêter d’y penser.

Et pour qui est passionné par son travail, l’enjeu, de mon point de vue, est surtout de parvenir à cette décorrélation travail/passion plus que de justifier les excès de sa passion.

(Aparté : c’est pour ça qu’attendre des candidats en informatique qu’ils présentent un Github bien rempli est, de mon point de vue, délétère. On peut tout à fait être très bon développeur en ayant aucun projet personnel public à présenter).

Un point qu’il serait intéressant de détailler aussi, c’est la notion de travail en équipe (autrement qu’au travers les relations d’enseignement ou de manager / développeur). La personne que j’ai connu qui me semblait le plus répondre à titre individuel à la définition que je comprends du software craftmanship produisait de l’excellent travail seule, mais était absolument incapable de travailler en équipe. À commencer parce qu’elle ne pouvait pas travailler avec quelqu’un qui ne fonctionnait pas exactement comme elle, et était incapable de déléguer.

Un point qui n’a rien à voir puisque le sujet est remonté plusieurs fois : si vous êtes développeur logiciel en France, vous êtes très probablement aux 35 heures annualisées (35 h / semaine réelle, ou plus de 35 h / semaine mais avec des RTT).

Pourquoi ? Parce que la grande majorité des développeurs sont sous la convention Syntec, qui n’autorise à peu près que ça, même si elle veut faire croire le contraire, et même si vos employeurs veulent faire croire le contraire.

Et donc, si vous considérez normal d’être passionné au point de ne pas compter vos heures, demandez un forfait jour, un vrai. Sous la convention Syntec, ça implique un salaire annuel minimum brut de 2x le plafond de la Sécurité Sociale, soit en 2021 : 2 x 41 136 = 82 272 €… si vous êtes payé moins que ça : soit vous n’êtes pas sous la convention Syntec, soit vous êtes aux 35 h plus ou moins déguisées.

+3 -0

Le billet aborde certains points en rapport avec le travail salarié dans une entreprise et les aspects qui vont avec : la hiérarchie, le management, les clients, les heures de travail.

Cependant, j’ai lu le billet en m’autorisant à prendre travail au sens large du terme (car c’est celui qui correspond aussi le mieux à mon propre cas), je n’aurai donc pas d’avis particulier sur les aspects relatifs au monde du travail.

Craftman (artisan/professionnel) vs. Ingénieur

Quelque chose m’interpelle dans ton billet.

Il ne s’agit donc pas que des métiers manuels ou artisanaux. Richard Sennett parle aussi bien dans son livre des exemples que je viens de donner que des docteurs et des infirmières, des architectes et des urbanistes, des ingénieurs, des cuisinières, des souffleuses de verre, des briquetiers ou des forgerons. À son sens, l’éducation des enfants est également un craft.

@nohar

Ce paragraphe semble sous entendre qu’on inclut pas les Software Craftmen dans les ingénieurs. Est-ce bien là une vision du Software Craftmanship en général, que d’opposer l'artisan et l'ingénieur ? (ou peut-être celle de Sennett en particulier ?)

À vrai dire, chez certains artisans, je trouve même que la frontière entre l’artisanat et l’ingénierie devient assez trouble. La différence majeure semble être la prise en compte de contraintes d’ordre industriel chez l’ingénieur. Mais quand on parle de « production logicielle », il me semble bien qu’on puisse y trouver des contraintes d’ordre industriel. Par ailleurs, on a bien dit plus haut que le craft ne s’oppose aucunement à l’« industriel » (et je suis plutôt d’accord avec ça).

Cela contraste aussi avec le commentaire d'@Aabu qui lui semble sous-entendre que les Software Craftmen pratiquent un métier dans l’ingénierie, comme les autres :

C’est assez intéressant tout ce qu’on lit là, et c’est applicable très largement à d’autres domaines de l’ingénierie non logicielle selon moi.

@Aabu
+0 -0

@entwanne : Comment un billet qui prône le pragmatisme en l’opposant aux écueils du dogmatisme pourrait-il être rédigé sous la forme d’injonctions ? J’ai peut-être une formulation personnelle, très franche, dans ce billet, mais à aucun moment je ne dis à quiconque ce qu’il doit faire.

Et je suis très embêté que ce soit pris comme ça. Parce que c’est passer totalement à côté de la démarche.

Dans le cas que tu cites :

Je me considère comme tel, et pourtant quand je quitte mon travail je me refuse de continuer à y réfléchir, à garder le moindre bug en tête : je coupe la machine et toute la charge mentale associée s’éteint avec. Le lendemain matin je reviens sur mes bugs et les redécouvre, avec un regard tout neuf sur la question parce que je les ai oubliés.

Ce que tu ne précises pas, mais qui est implicite, c’est que ce comportement fonctionne pour toi, c’est que tu t’es discipliné pour lâcher ton travail à la fin de la journée et faire autre chose. Et oui, tu te comportes en professionnel. Mais ça ne t’est jamais arrivé d’avoir un problème passionnant sur lequel tu continues à réfléchir sous la douche ou en te faisant à manger ? Un Eurêka poussé du fond des toilettes ?

Ce que ce billet décrit n’est que ça. Ce n’est absolument pas une injonction à rentrer avec du boulot à la maison et négliger le reste de sa vie. Cette attitude ne serait pas du tout professionnelle.

Est-ce que c’est plus clair ?

@firm1 : Merci pour cette réponse ! La discussion s’annonce intéressante ! :)

Je pense que tous les secteurs de métiers n’ont pas forcément la même exigence qualité. Quand je vais chez le médecin, s’il me prescrit un traitement qui met en cause ma santé par négligence, je peut porter plainte et gagner le procès. Si j’embauche un développeur et qu’il me produit un nid a bugs par négligence avant de démissionner six mois plus tard, je vais avoir du mal à porter plainte.

Les médecins se prennent des procès quand ils ne se comportent pas en professionnels. Des gens meurent, ils peuvent également perdre le droit d’exercer. Et pas les développeurs. C’est vrai.

Mais est-ce que tu ne pars pas quand même du principe que si tu embauches un développeur, c’est pour qu’il te livre un travail de qualité ?

Est-ce que tu ne penses pas qu’en tant que développeurs, c’est la moindre des choses que nous livrions un travail de qualité ?

J’aurais presque envie de te demander si ce n’est pas justement quand les développeurs peuvent chier du code sans se préoccuper de sa qualité qu’ils osent ne pas se comporter en professionnels ?

Faire confiance au professionnel dans ses outils, c’est aussi quelque chose de compliqué. Parfois le professionnel va me dire que mon logiciel doit absolument être codé en Rust (et c’est peut-être le meilleur choix technique). Mais il n’aura pas en tête le jour où il quittera mon entreprise et que je vais avoir du mal à recruter un dev Rust à un prix raisonnable pour mon budget.

J’ai l’impression que cet exemple te vient du fait que le professionnel est responsable de ses outils. Attention, Rust n’est pas "un outil" dans ton exemple : c’est la techno dans laquelle le produit est construit. Si tu as besoin que ton logiciel soit codé dans une technologie précise, un professionnel te demandera pourquoi, il challengera tes raisons, te proposera des alternatives, et si tu n’as pas changé d’avis, il le fera dans la techno que tu lui as demandée. Par contre ce n’est pas à toi de lui imposer vim ou visual code, gitlab ou gerrit, ni de travailler en TDD ou pas.

Si un développeur (en l’occurrence un freelance) te répond ça, alors déjà, il ne se comporte pas forcément en professionnel. Par contre, toi, en tant que professionnel qui l’embauche, c’est aussi ton rôle de lui demander de justifier son choix. En tant que professionnel, c’est à lui de te proposer les alternatives en t’expliquant tout ce que chacune implique pour toi.

Après, tu as raison : il est difficile de se reposer sur le fait que l’autre partie se comportera de façon professionnelle, et de lui faire confiance pour ça. Ce qui joue, par contre, c’est si le type que tu as embauché ne t’a pas livré une prestation de qualité, s’il n’a pas été un bon professionnel, tu ne feras plus appel à ses services, donc ce n’est pas dans son intérêt de t’entuber.

Dans tous les cas, je ne prétends pas du tout qu’il faut faire confiance au professionnalisme des gens. Je dis juste qu’il à la base ne pas les micro-manager, les traiter en professionnels, et se comporter soi-même en professionnel.

La confiance, dans notre boulot, dans n’importe quel boulot, et même pas qu’au boulot, ce n’est pas quelque chose que tu accordes par défaut. C’est quelque chose que tu crées et que tu entretiens. Ce qui est absolument certain, c’est que tu ne la crées pas en infantilisant les développeurs ou en leur imposant des choix sur lesquels ce sont eux les experts.

Un débutant n’a pas forcément toujours assez d’expérience pour que son manager, ou même son tech lead lui fasse confiance les yeux presque fermés sur ses choix et sur son travail "professionnel". Etant donné que le billet présente l’excellence technique comme prérequis de réussite, est-ce qu’il faut en conclure que l’agilité se prête mal à une équipe mixte (débutants et expérimentés) ?

Bien au contraire ! :D

Je me suis gardé de parler du fonctionnement interne des équipes de développeurs dans ce billet parce qu’il était déjà bien assez long, mais il y a des tas de choses à dire là-dessus. Les équipes sont faites pour collaborer, pour être des équipes, pour entretenir une culture de l’apprentissage et d’amélioration continue de leurs pratiques.

Contrairement à ce que tu sembles déduire de ton raisonnement, une équipe de craftsmen est justement le meilleur environnement dans lequel puisse tomber un débutant. C’est une équipe dans laquelle il va être mentoré, apprendre à bosser auprès de gens solides, apprendre des bonnes pratiques, les remettre en question avec son équipe, en adopter de nouvelles.

Quand on pense au software craftsmanship, d’ordinaire, on pense à cette notion de reproduire l’apprentissage un peu comme celui des artisans : "on commence apprenti, on devient compagnon, et on finit maître"… En fait, l’inspiration est plus ou moins là, mais ce n’est pas explicitement décrit comme ça dans la littérature.

Par contre, la littérature précise pas mal de trucs assez solides comme :

  • Quand on est en difficulté, il n’est pas professionnel de se renfermer sur soi et ne pas demander de l’aide à son équipe.
  • Quand on voit un collègue en difficulté, il n’est pas professionnel de ne pas lui proposer notre aide, par exemple en essayant de faire une séance de pair programming pendant 30 minutes, pour voir si on peut l’aider à se débloquer.

Ce que je retiens et qui diffère le plus de ce que j’ai connu jusqu’à présent, c’est justement le fait que les développeurs sont censés collaborer entre eux énormément. Et adopter une attitude qui leur permet de se tirer les uns les autres vers le haut, ensemble.

+0 -0
Ceci concernait une ancienne version du billet que j’ai mal interprétée, et n’est plus d’actualité

Je réponds à ce point parce que je pense que c’est l’un des gros points d’achoppement entre ce qu’il me semble que tu as voulu dire (surtout à la lecture de ton dernier commentaire) et ce qui semble avoir été compris :

@entwanne : Comment un billet qui prône le pragmatisme en l’opposant aux écueils du dogmatisme pourrait-il être rédigé sous la forme d’injonctions ? J’ai peut-être une formulation personnelle, très franche, dans ce billet, mais à aucun moment je ne dis à quiconque ce qu’il doit faire.

nohar

En fait, en l’état, il y a beaucoup de phrases qui peuvent être prises comme des injonctions, ou au moins une description de ce que tu présenterais comme « la bonne façon de faire ». Je pense à des vérités générales de ce genre :

En résumé, on ne peut s’épanouir au travail qu’à partir du moment où celui-ci a un sens pour nous.

À ce genre de phrase donnée sur un ton déclaratif, avec une mise en forme sophistiquée, ce qui incite beaucoup à y lire une prescription :

Cependant, être passionné est une condition nécessaire, mais pas suffisante pour se comporter en craftsman, car le travail bien fait exige que notre passion soit canalisée par une discipline tout aussi grande.

Je pense aussi aux passages où tu entraines le lecteur dans ton raisonnement avec le « nous ». Ça peut donner des choses là encore qui confinent à l’injonction :

Au minimum, il importe que nous autres, développeurs, réalisions cet examen de conscience

Ça présuppose aussi que le lecteur ou la lectrice est d’accord avec ton raisonnement, alors que pas forcément, comme dans des phrases comme :

Le moins que nous puissions faire est de financer nous-même notre formation, et c’est ce que font les bons développeurs.

Dans laquelle la partie en gras ressemble quand même aussi fortement à une injonction.

Je pense enfin aussi aux prises à partie :

Pensez-vous encore que "je vais essayer" soit une réponse professionnelle ?

J’espère que ça t’aidera à comprendre où il peut y avoir des incompréhensions et d’où elles peuvent venir.

+1 -0
Ceci concernait une ancienne version du billet

En résumé, on ne peut s’épanouir au travail qu’à partir du moment où celui-ci a un sens pour nous.

À ce genre de phrase donnée sur un ton déclaratif, avec une mise en forme sophistiquée, ce qui incite beaucoup à y lire une prescription

La phrase que tu cites fait partie de la définition (vulgarisée) que je donne de la notion de sens au travail en psychologie. Existe-t’il d’autres façons de donner une définition que de façon déclarative ?

Ensuite, tu cites effectivement la seule injonction ferme du billet : se regarder dans le miroir, observer notre propre comportement, le questionner. Oui, ça, c’est une injonction. Que le lecteur soit d’accord pour opérer ce questionnement ou pas, c’est en tout cas ce que je l’enjoins à faire.

Est-ce que vous êtes en train de me reprocher d’inviter les gens qui lisent un billet sur Zeste De Savoir à réfléchir à leurs pratiques et leurs comportements ? Si c’est le cas, alors on a bien plus qu’un problème de forme ou de fond.

+0 -1
Ceci concernait une ancienne version du billet que j’ai mal interprétée, et n’est plus d’actualité

La phrase que tu cites fait partie de la définition de la notion de sens au travail en psychologie. Existe-t’il d’autres façons de donner une définition que de façon déclarative ?

Je dis bien ce genre de phrase, pas cette phrase en particulier et elle seule. Ce qui est important c’est l’idée, pas l’exemple qui aurait pu être mieux choisi (si on voulait faire un étude de texte on pourrait disserter sur cet paragraphe et la place de cette phrase en tant que définition, mais ça n’est pas le sujet).

Est-ce que vous êtes en train de me reprocher d’inviter les gens qui lisent un billet sur Zeste De Savoir à réfléchir à leurs pratiques et leurs comportements ? Si c’est le cas, alors on a bien plus qu’un problème de forme et de fond !

nohar

Je ne crois pas que quiconque ici dise ça.

+3 -0

J’aurais presque envie de te demander si ce n’est pas justement quand les développeurs peuvent chier du code sans se préoccuper de sa qualité qu’ils osent ne pas se comporter en professionnels ?

nohar

On est d’accord. Mais comment (qui ?) imposer de la part du développeur de la qualité (en sachant que cette notion est très vague) et être à même de juger d’un travail de qualité du point de vue du manager (qui n’a pas forcément toutes les clés pour juger techniquement le travail) ?

Les équipes sont faites pour collaborer, pour être des équipes, pour entretenir une culture de l’apprentissage et d’amélioration continue de leurs pratiques.

nohar

Justement il y a un conflit entre ce que tu dis là et ce que je lis dans le billet là (la graisse vient de moi):

Et l’un de ces prérequis est l’excellence technique des développeurs : SCRUM fonctionne à merveille quand chaque développeur de l’équipe est traité comme professionnel et se comporte en tant que tel.

billet

Attendre d’un débutant qu’il se comporte comme un professionnel c’est compliqué. Cette phrase mérite d’être un minimum nuancée ne serait-ce que parce que, comme tu le dis, atteindre l’excellence technique c’est lors, et ça demande beaucoup d’année d’expérience derrière soit.

+1 -0

À propos des outils utilisés, et dans le cadre du travail salarié, je me pose aussi la question des outils de gestion de projets.

Les développeurs vont plutôt se porter sur une gestion des tâches à l’aide de github, gitlab ou équivalents. Mais ils et elles travaillent aussi avec des managers et des responsables de produit qui vont parfois préférer d’autres outils tels que Jira pour avoir une autre vision.

Tous ces outils ne s’accordent pas toujours bien ensemble, donc qui devrait avoir le dernier mot pour les imposer ?

+0 -0

Mais comment (qui ?) imposer de la part du développeur de la qualité (en sachant que cette notion est très vague) et être à même de juger d’un travail de qualité du point de vue du manager (qui n’a pas forcément toutes les clés pour juger techniquement le travail) ?

C’est vraiment si vague que ça ? un logiciel que l’on peut utiliser et qui fait ce que j’attends de lui sans bugger. Ce n’est pas le rôle du manager de juger de la qualité du logiciel, c’est celui du client qui l’utilise. Le manager n’est pas idiot : il voit bien si le code que release son équipe satisfait son client ou pas. Il voit bien si l’équipe a livré ce qu’elle avait promis à la date promise.

Quant à imposer la qualité, on en revient au même : c’est aux développeurs d’exiger d’eux-mêmes de livrer de la qualité à leurs clients, et de faire tout ce qui est en leur pouvoir pour trouver avec leur manager une façon de livrer ce qu’attend le client.

Le billet semble "opposer" managers et développeurs, parce qu’il décrypte notamment certains éléments qui expliquent que cette coopération se passe mal. Mais les développeurs et leur manager sont dans la même boîte et ils ont le même but. Pourquoi leur prêter des buts contradictoires ?

Attendre d’un débutant qu’il se comporte comme un professionnel c’est compliqué. Cette phrase mérite d’être un minimum nuancée ne serait-ce que parce que, comme tu le dis, atteindre l’excellence technique c’est lors, et ça demande beaucoup d’année d’expérience derrière soit.

OK, je vois ce qui te pose problème. Je comprends que ça puisse apparaître comme une contradiction, laisse moi t’expliquer.

Attendre qu’un développeur débutant (apprenti) se comporte en professionnel, ce n’est pas la même chose qu’attendre qu’un dévelopeur confirmé se comporte en professionnel. Par contre, s’ils font équipe ensemble, alors on attend de cette équipe un résultat professionnel et que qualité : l’équipe est un "corps". Le senior va assurément assumer une part de responsabilité dans la formation du junior : ils sont dans la même équipe !

En ce qui concerne l’attitude professionnelle, ce qu’un débutant peut apprendre très tôt auprès de son équipe, c’est déjà la base comme ne pas s’engager si on n’est pas sûr d’y arriver. C’est d’aller poser la question à un autre membre de l’équipe s’il ne sait pas. C’est de se discipliner pour appliquer les pratiques de son équipe.

Oui, atteindre la maîtrise et l’excellence technique, c’est très long. La littérature parle de cent mille heures, plus ou moins, quel que soit le domaine. Mais là tu confonds excellence technique et attitude professionnelle. À aucun moment je ne parle d’attendre d’un débutant qu’il ait l’excellence technique d’un senior. L’excellence technique, c’est celle de l’équipe : tu peux être un débutant et apprendre à bosser avec une équipe qui fait de l’excellent travail, partage ses pratiques, et globalement t’apprend à bosser et contribue à ce que tu acquières cette excellence technique.

PS :

@entwanne : pour le coup c’est vraiment du détail. L’outil de gestion de projet me semble plutôt devoir être le résultat d’une négociation entre tous les stakeholders. Rien n’empêche à l’équipe d’utiliser, par exemple, Jira pour la gestion de projet, d’un côté, et gitlab (sans les issues) pour la CI, le code-review et le workflow général et quotidien des développeurs.

+3 -0

Les médecins se prennent des procès quand ils ne se comportent pas en professionnels. Des gens meurent, ils peuvent également perdre le droit d’exercer. Et pas les développeurs. C’est vrai.

Mais est-ce que tu ne pars pas quand même du principe que si tu embauches un développeur, c’est pour qu’il te livre un travail de qualité ?

Est-ce que tu ne penses pas qu’en tant que développeurs, c’est la moindre des choses que nous livrions un travail de qualité ?

J’aurais presque envie de te demander si ce n’est pas justement quand les développeurs peuvent chier du code sans se préoccuper de sa qualité qu’ils osent ne pas se comporter en professionnels ?

Il y a effectivement une différence de gravité nette entre les deux domaines qui poussent les gens à prendre un risque (zapper les sécurités) d’un côté et pas de l’autre. Mais plutôt que de considérer ces risques comme des contraintes, n’y a-t-il pas moyen d’en faire des opportunités ?

Je m’explique. Si on excepte certaines applications informatiques critiques qui de toute façon sont soumises à des vérifications beaucoup plus poussées, pour la plupart des logiciels, s’ils plantent, ce n’est pas très grave. Par exemple, en rédigeant ce message, j’utilise Firefox et je jette un œil sur Discord en parallèle. Si un de ces deux logiciels plante, c’est agaçant, mais ça n’a rien de grave : personne ne va mourir ou avoir de séquelles graves.

Est-ce que justement, on ne pourrait pas utiliser cette absence de gravité comme une opportunité de faire plus vite ? Si je zappe les tests de mon application, je sais qu’elle va finir par planter, j’estime les chances de plantage à mettons 1% à chaque lancement mais en même temps, je sais que je gagne 20% de temps de développement. Est-ce qu’il n’y a pas moyen de présenter cette option au client/manager en lui disant que son application sera certes moins stable (ce qui n’est pas si grave au final), mais par contre que je vais économiser du temps de développement et donc de l’argent ?

Contrairement à ce que tu sembles déduire de ton raisonnement, une équipe de craftsmen est justement le meilleur environnement dans lequel puisse tomber un débutant. C’est une équipe dans laquelle il va être mentoré, apprendre à bosser auprès de gens solides, apprendre des bonnes pratiques, les remettre en question avec son équipe, en adopter de nouvelles.

La question que je me pose (puisque c’est un peu le cas dans lequel je me suis retrouvé lors de ma brève expérience de l’informatique), c’est que faire quand on est junior, qu’on a envie d’adopter cette façon de faire mais qu’on atterrit dans une équipe qui fonctionne mal ? On n’a pas le recul pour savoir ce qui fonctionne ni comment le mettre en place (exemple : le TDD je sais vaguement ce que c’est, je sais que c’est considéré comme bien mais je n’ai aucune idée de comment ça se met en place concrètement). On n’a pas non plus forcément l’autorité ni l’expérience ou le recul nécessaires pour se permettre de ne pas céder.

Pour prendre mon propre exemple, je travaillais dans une équipe dans laquelle il n’y avait aucun test à part des tests manuels faits pas les business analysts, la plupart des solutions techniques étaient choisies pour leur facilité et leur rapidité de mise en œuvre plutôt que pour leur efficacité (et elles étaient souvent très opposées à la solution que recommandait l’éditeur du logiciel dont nous étions chargés de développer des extensions). En ce qui me concerne, je n’avais pas le recul nécessaire pour me poser les bonnes questions, mais si j’avais lu ton billet à cette époque, j’aurais probablement commencé à me poser des questions sur nos façons de faire. Comment introduire le sujet dans une équipe où on m’aurait répondu des choses comme « on n’a pas le temps », « on a toujours fait comme ça », etc. ?

Merci pour le billet en tout, c’était très intéressant. ;)

+0 -0

Est-ce que justement, on ne pourrait pas utiliser cette absence de gravité comme une opportunité de faire plus vite ? Si je zappe les tests de mon application, je sais qu’elle va finir par planter, j’estime les chances de plantage à mettons 1% à chaque lancement mais en même temps, je sais que je gagne 20% de temps de développement. Est-ce qu’il n’y a pas moyen de présenter cette option au client/manager en lui disant que son application sera certes moins stable (ce qui n’est pas si grave au final), mais par contre que je vais économiser du temps de développement et donc de l’argent ?

C’est une excellente question !

La réponse courte est : Non, surtout pas, c’est un piège !

J’a déjà tenu ce raisonnement, et bossé dans des projets dans lesquels faire l’impasse sur les tests et balancer à la QA avait localement "plus de sens" que se fatiguer à écrire des tests. La première observation que je peux en faire, c’est que tous ces projets étaient pourris, et travailler dessus un calvaire.

Mais le plus intéressant, c’est ce que les sources de ce billet on à dire à ce propos.

Quand on se dit que l’on "gagne 20% de temps de développement" à ne pas écrire des tests, on se ment. Les gens qui pratiquent le TDD ont pris le temps de mesurer ces trucs-là : écrire une petite fonctionnalité (on parle d’une tâche d’une demi-heure, comme "calculer le scores d’une partie de bowling") prend entre 20% et 10% moins de temps quand on la résout en TDD que quand on implémente directement la solution.

Faire les choses "bien" ne prend pas "plus longtemps". Faire les choses "bien" ça prend autant ou moins longtemps. Du moins c’est le cas quand on pratique sérieusement le TDD. C’est-à-dire en prenant un peu de notre temps libre (30 minutes max, une ou plusieurs fois dans la semaine) à nous entraîner à pratiquer TDD.

Mais admettons, "pour l’argument", qu’on ne pratique pas TDD parce qu’on a pas la compétence dans l’équipe. Si du code part en prod sans être testé, ce n’est pas 1% de chances qu’il a de casser. L’estimation la plus raisonnable serait plutôt 100%. Donc tu vas devoir le réparer à un moment, le couvrir de tests, le refactoriser, le soigner. Si tu le remets à plus tard, tu contractes une dette. C’est ta dette technique.

Quand je commence le billet en disant que "j’ai fini de rembourser ma dette technique", c’est de ça qu’il s’agit. Mais j’ai de la chance d’avoir pu la rembourser. C’est parce que je l’ai très sévèrement contrôlée dès le début du projet. Cette dette, elle peut aussi tuer un projet ou faire couler une boîte.

L’expérience, tant la mienne personnelle que celle des auteurs des bouquins que je cite dans le billet, suggère que quand on fait un ticket "nettoyer tel truc" pour remettre la tâche à plus tard, ce ticket ne sera jamais fait.

Pour prendre mon propre exemple, je travaillais dans une équipe dans laquelle il n’y avait aucun test à part des tests manuels faits pas les business analysts, la plupart des solutions techniques étaient choisies pour leur facilité et leur rapidité de mise en œuvre plutôt que pour leur efficacité (et elles étaient souvent très opposées à la solution que recommandait l’éditeur du logiciel dont nous étions chargés de développer des extensions). En ce qui me concerne, je n’avais pas le recul nécessaire pour me poser les bonnes questions, mais si j’avais lu ton billet à cette époque, j’aurais probablement commencé à me poser des questions sur nos façons de faire. Comment introduire le sujet dans une équipe où on m’aurait répondu des choses comme « on n’a pas le temps », « on a toujours fait comme ça », etc. ?

Le « on n’a pas le temps », c’est facile d’y répondre. On a le temps parce que c’est du temps à gagner. Les pratiques comme TDD et le pair programming sont faites pour gagner du temps.

Par exemple, est-ce que vous faisiez des code review ?

Ça prend du temps une review bien faite. Il faut repasser sur le code, comprendre comment l’autre a réfléchi, puis finalement identifier des problèmes, puis faire un retour par écrit. Et si la review avait lieu en même temps que le développement, à voix haute, à deux avec le code sous les yeux, en se passant le clavier ? On perdrait moins de temps à comprendre comment l’autre a réfléchi : il est à côté de nous ! On lui pose la question sur le moment. On s’encouragerait à écrire du bon code. On échangerait in situ. On apprendrait des choses de cet échange. Et puis ça marche bien avec TDD : un qui écrit un test, l’autre qui écrit le code qui le fait passer au vert.

Non seulement ça permet de dégager de la tâche tout le délai supplémentaire de la revue de code. Mais en plus c’est un super moyen de former les juniors. C’est du temps gagné pour toute l’équipe au final.

Le plus dur c’est d’essayer de donner l’impulsion. Parfois il suffit de "montrer l’exemple". Parfois les gens sont juste blasés. On ne peut pas les forcer d’en avoir quelque chose à faire contre leur gré.

+2 -0

Je rajouterais une précision à la très bonne explication de nohar sur les tests dans un projet, c’est qu’évidemment elle ne s’applique que sur un projet ou c’est possible de coller des tests dans un temps raisonnable.

Selon ton contexte projet, le calcul peut être différent : tu peux te retrouver dans des cas où pour bien faire il faudrait ajouter des tests, mais objectivement c’est plus intéressant de laisser le truc planter s’il doit planter et de réparer le problème à la main. Par exemple, sur un projet historique de 2 500 000 lignes de code réelles (plus formatage et commentaires) dont seulement 500 000 sont accessibles à des tests automatisés (le reste n’a tout simplement pas été conçu pour être testable sans grosses modifications).

Évidemment, le premier réflexe face à ce genre de projet c’est de le refuser en prétendant qu’il est pourri, mais en fait l’état de la base de code n’est qu’une petite partie du problème, tout ce qu’il y a autour peut être très intéressant : perspectives d’évolution technique (volonté de mettre à niveau un projet très endetté techniquement), intérêt fonctionnel pour le projet, qualité des équipes en place (techniques et fonctionnelles), qualité du pilotage du projet, etc…

D’ailleurs j’ai l’impression que beaucoup de développeurs ont tendance à sous-estimer l’importance du contexte du projet (au sens le plus large : intérêt fonctionnel, pilotage, liberté laissée aux équipes dans tous les domaines, qualité des spécifications…) et à trop en donner à la base de code (y compris ses accompagnements directs : tests, CI/CD, équipe de dev). C’est un réflexe que je retrouve chez les jeunes développeurs comme chez les expérimentés, mais avec des justifications différentes.

+1 -0

Je viens de corriger le billet, en virant notamment tous les propos qui pouvaient inciter à penser que je faisais l’apologie de la vision romantique du professionnel qui ne compte pas ses heures et ne déconnecte jamais. Je vois que ça a beaucoup attiré l’attention dans les commentaires, c’est aux antipodes de ce que je voulais faire comprendre, j’en déduis donc que je me suis mal exprimé.

D’ailleurs j’ai l’impression que beaucoup de développeurs ont tendance à sous-estimer l’importance du contexte du projet (au sens le plus large : intérêt fonctionnel, pilotage, liberté laissée aux équipes dans tous les domaines, qualité des spécifications…) et à trop en donner à la base de code (y compris ses accompagnements directs : tests, CI/CD, équipe de dev). C’est un réflexe que je retrouve chez les jeunes développeurs comme chez les expérimentés, mais avec des justifications différentes.

Je partage un peu cette impression, mais je la comprends aussi. Du moins je ne pense pas qu’on donne trop d’importance à la base de code, parce que c’est quand même ce sur quoi on travaille, et qu’une base de code pourrie peut couler un projet. C’est important.

Par contre, je regrette un peu que ces discussions sur la base de code soient rarement pragmatiques : c’est important de faire gaffe à la base du code, parce qu’on veut la rendre meilleure, et la plupart des discussions ont tendance à vite perdre de vue cet objectif.

Par contre quand tu dis que l’on sous-estime l’importance du contexte du projet, je suis totalement d’accord avec toi. Je dirais même qu’une des choses auxquelles on pourrait essayer de faire plus attention, c’est comment détecter et glaner des infos fiables à ce sujet quand on est dans un processus de recrutement.

Ça peut passer par des indicateurs assez subtils. Par exemple : est-ce que j’ai au moins un entretien avec un dev de l’équipe qui recrute ou bien juste avec des managers et des encadrants ?

Typiquement, dans le second cas, je tourne les talons. Si l’équipe de développement ne participe pas au recrutement de quelqu’un qui va bosser avec eux, c’est que ça ne doit pas des masses collaborer là-dedans, et que tout passe par les managers. Ça ne sent pas vraiment l’équipe responsabilisée.

+5 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte