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

J’ai aussi (à l’instant) revu le passage hyper maladroit où je parle de prendre sa formation en charge. J’essaye d’inviter à la réflexion plutôt que d’affirmer des choses.

+0 -0

En lisant rapidement l’article et les commentaires, je pense qu’il faut savoir prendre du recul sur son travail et ses collègues.
Je pense que pas mal de personnes ont un travail que je qualifierait d’alimentaire, il n’y a pas vraiment de passion dans ce qu’ils font, ils font leurs heures, cherchent à grimper les échelons pour gagner plus et peut-être changer de métier (passer manager par exemple) vers quelque chose de moins technique.

Je pense que ZdS regroupe des personnes passionnées et compétentes. Sans me vanter, j’en fait partie aussi mais pas en informatique, en électronique.

Sans être forcément passionné, la différence par rapport à certains collègues que j’ai pu avoir, qui faisaient un taf allant de médiocre à bon, c’est qu’il n’y a pas ce petit "plus", cette envie d’aller une marche plus haut. J’intègre ça dans la "veille technologique", se renseigner sur les nouveaux composants, lire des articles techniques, des papiers de conférences, etc.

J’ai eu un collègue qui ne faisait aucune veille technologique, il faisait ses heures, pouvait faire un peu plus parce que le but c’est pas de mettre le projet dans la merde, mais il n’avait pas ce petit plus. Il fait ce qu’on lui demande, applique des méthodes connues, mais le problème c’est que pour de l’innovation et mettre en application les dernières technologies c’est pas vraiment ça.
Je trouve cela dommage pour la personne, car cela rejoint la partie sur la formation, la veille technologique, ça permet d’être à jour et donc de ne pas être obsolète dans 20 ans parce qu’on ne s’est pas adapté.

Sur la partie management et le fait de savoir dire non, j’ai déjà plusieurs fois menacer de ne pas signer le "bon de production" d’une carte électronique sans que des concessions soient faites. Par chance elles ont toujours été faites, mais je sais que je n’aurais pas hésité à ne pas "signer" le lancement en production d’une carte que j’aurais considérée comme mauvaise, en laissant le soin à mon n+1 de signer et d’assumer la responsabilité.

J’ai aussi eu des difficultés avec un manager qui ne me faisait pas confiance et qui a précipité mon départ de mon dernier poste. Mais outre le manager, c’était toute la boite et le processus de décision qui était mauvais, verrouillé par des personnes toujours aux même postes depuis des années et qui n’ont que des prismes de rentabilité et de coût malgré leur postes techniques.
Je vois aussi que certaines boites/équipes n’ont plus cette volonté de dépassement technique, d’envoyer du rêve même si derrière y a du boulot. Non le truc c’est de copié ce que fait le concurrent parce que les clients vont nous demander la même chose, on ne propose plus grand chose car on est tête baissé à suivre ce que fait la concurrence. Et derrière ça mène à faire des tests plus léger, à faire le minimum d’études et de documentation.
Si pendant quelques années ça ne pose pas de problèmes, au fur et à mesure que les gens partent, l’information se perd et on ne comprend plus pourquoi telle fonction a été faite comme ça. Et donc plusieurs années après on doit soit faire du copier/coller sans comprendre, soit passer du temps à faire du reverse engineering sur un design maison, soit repartir de zéro.

+5 -0

Je pense que pas mal de personnes ont un travail que je qualifierait d’alimentaire, il n’y a pas vraiment de passion dans ce qu’ils font, ils font leurs heures, cherchent à grimper les échelons pour gagner plus et peut-être changer de métier (passer manager par exemple) vers quelque chose de moins technique.

Oui. Et ça n’a rien de répréhensible en soi.

Par contre un des soucis que l’on retrouve dans la littérature, c’est justement que vouloir passer manager ne devrait pas être considéré comme la normalité ou une fatalité pour un développeur. L’une des raisons pour lesquelles on appelle ça du craftsmanship, c’est qu’il y a cette notion de fierté sous-entendue.

En tant que professionnels qualifiés, on devrait pouvoir considérer comme normal le fait de vouloir être développeurs toute notre carrière. Comme tu le dis, passer manager, c’est changer de métier et donc de carrière.

Une des choses qui expliquent cet état de fait ("si t’es toujours développeur à 30 ans t’as raté ta carrière"), c’est justement que l’on ne considère pas les devs comme des professionnels hautement qualifiés et spécialisés : c’est comme considérer que si un médecin n’est pas devenu chef de service à 50 ans, il aurait "raté sa carrière".

Alors bien sûr, je fais des comparaisons avec d’autres métiers sont les réalités sont très différentes, mais il ne faut pas leur donner plus de portée qu’elles n’en ont : dans ce cas je veux juste dire que "rater sa vie parce qu’on est pas devenu chef" n’a aucun sens dans nos métiers. Du coup, j’ai envie de dire que le craftsmanship ne concerne pas forcément ces gens qui veulent juste être promus et qui ne veulent pas faire carrière là-dedans. Il concerne plutôt ceux qui le veulent et qui ont besoin pour cela de résister au chant des sirènes.

En ce qui me concerne j’ai 36 ans et je suis très fier d’être "un raté". :D

J’ai eu un collègue qui ne faisait aucune veille technologique, il faisait ses heures, pouvait faire un peu plus parce que le but c’est pas de mettre le projet dans la merde, mais il n’avait pas ce petit plus. Il fait ce qu’on lui demande, applique des méthodes connues, mais le problème c’est que pour de l’innovation et mettre en application les dernières technologies c’est pas vraiment ça.

Puisque c’est un des points qui ont prêté le plus à confusion dans mon billet à l’origine, je vais me permette de préciser : attention, il n’y a aucun mal à "faire ses heures", on peut être un excellent professionnel et "faire nos heures", d’ailleurs, on EST un excellent professionnel quand on arrive à "faire nos heures" (dans le sens de ne pas dépasser) parce que ça signifie que l’on sait négocier et ne pas s’engager sur des deadlines impossibles, et donc que l’on a la maîtrise de notre temps de travail.

Par contre, tu le dis toi-même : ne pas se tenir à jour, c’est devenir peu à peu obsolète.

Je vois aussi que certaines boites/équipes n’ont plus cette volonté de dépassement technique, d’envoyer du rêve même si derrière y a du boulot. Non le truc c’est de copié ce que fait le concurrent parce que les clients vont nous demander la même chose, on ne propose plus grand chose car on est tête baissé à suivre ce que fait la concurrence. Et derrière ça mène à faire des tests plus léger, à faire le minimum d’études et de documentation.

Et c’est exactement ce phénomène que l’on veut éviter, parce que dans le cas du logiciel, ça donne le Disenchantment sur lequel écrivait @Spacefox il y a quelques années. C’est tout "le corps de métier" qui souffre de ça.

Encore pire : aujourd’hui le logiciel est partout dans notre monde. Donc si on se contente tous de faire du Big Mac logiciel, alors on finira par vivre dans un gigantesque McDo… et en fait c’est déjà le cas. Quoique même McDo a des standards de qualité mieux respectés que l’équipe de développement moyenne.

+2 -0

En tant que professionnels qualifiés, on devrait pouvoir considérer comme normal le fait de vouloir être développeurs toute notre carrière. Comme tu le dis, passer manager, c’est changer de métier et donc de carrière.

Une des choses qui expliquent cet état de fait ("si t’es toujours développeur à 30 ans t’as raté ta carrière"), c’est justement que l’on ne considère pas les devs comme des professionnels hautement qualifiés et spécialisés : c’est comme considérer que si un médecin n’est pas devenu chef de service à 50 ans, il aurait "raté sa carrière".

[…]

En ce qui me concerne j’ai 36 ans et je suis très fier d’être "un raté". :D

nohar

Je ne suis pas aussi rigide sur les frontières du métier. Passer manager, ce n’est pas forcément changer de métier, pour moi. Je veux bien croire que pour certains ce soit le cas, étant sûrement dans une logique « si t’es toujours développeur à 30 ans t’as raté ta carrière » que tu décris.

Car passer manager, c’est peut-être changer de métier sur le papier, mais cela veut-il dire pour autant perdre sa vision ? Pas forcément.

Passer manager, cela peut être vu comme une opportunité : celle de devenir un porte-parole du Craftmanship auprès des autres départements et des clients ; celle d’avoir le pouvoir suffisant pour assurer aux équipes techniques des conditions de travail en adéquation avec cette vision ; celle de prouver aux grands chefs qu’il ne s’agit pas d’un simple caprice, mais d’un réel enjeu avec des vrais retours sur investissement ; enfin, celle d’avoir in fine un poids suffisant pour faire tendre l’entreprise vers une culture de l’excellence technique.

Ce manager-ci, il lâche la technique pour lui, mais pas pour ses compagnons. On peut voir ça un peu comme le Undercover Craftman ^^

Le cas que je présente est-il représentatif ? Malheureusement, je ne pense pas. J’ai néanmoins la « chance » d’avoir connu au moins une entreprise (de ~500 personnes) dans cette situation pour savoir que ça existe. Inutile de préciser que le courant entre les managers et les équipes techniques passe d’ailleurs en général très bien.

+0 -0

@sgble : ce que tu décris me semble assez "dangereux". Mais ça dépend de ce que tu appelles un manager.

Un manager qui a toujours les mains dans le code, pour moi c’est un tech lead et il fait partie de l’équipe, bosse sur le code au quotidien avec l’équipe, et reste à jour sur la réalité du code. Il est la tête et les mains à la fois. Ça fonctionne très bien.

Un manager qui ne touche plus au code, ce n’est pas un craftsman : c’est "une tête" sans les mains. Ses mains ne font pas le même boulot, son rôle n’est donc pas le même (il doit négocier, discuter, etc.) donc fatalement, son métier n’est pas le même : ce ne sont pas les mêmes compétences qu’il a besoin de mobiliser pour faire correctement son travail.

Si ce manager a une connaissance du code et de la technique, ça peut être bien comme ça peut devenir un sacré problème, notamment s’il a adopte la posture : je suis au-dessus de toi, j’ai aussi connu ce que tu fais alors je sais mieux que toi ce que tu dois faire. Autrement dit, le risque c’est qu’un développeur qui devient manager se considère ou soit considéré par sa boîte comme "le meilleur de ses développeurs" alors qu’il ne l’est pas et qu’il a divorcé des moyens de l’être, et quand bien même ce serait le cas le jour de sa promotion, il perdrait très rapidement ce statut parce que son équipe, elle, ne va pas arrêter d’avancer, le code va continuer à changer, et ses besoins aussi.

C’est un paragraphe que j’avais dégagé dans la première partie du billet parce qu’il n’était pas assez significatif, mais c’est une notion importante : un craftsman c’est "une tête et des mains" bien entraînées, dans le même corps.

+1 -0

@sgble : ce que tu décris me semble assez "dangereux". Mais ça dépend de ce que tu appelles un manager.

Un manager qui a toujours les mains dans le code, pour moi c’est un tech lead et il fait partie de l’équipe, bosse sur le code au quotidien avec l’équipe, et reste à jour sur la réalité du code. Il est la tête et les mains à la fois. Ça fonctionne très bien.

Un manager qui ne touche plus au code, ce n’est pas un craftsman : c’est "une tête" sans les mains. Ses mains ne font pas le même boulot, son rôle n’est donc pas le même (il doit négocier, discuter, etc.) donc fatalement, son métier n’est pas le même : ce ne sont pas les mêmes compétences qu’il a besoin de mobiliser pour faire correctement son travail.

Je parle bien d’un manager, pas d’un tech lead, ni même forcément d’un directeur technique qui peut être assimilé à un tech lead dans certaines petites structures. Ce que j’entendais par manager, c’est la même chose que toi : une tête sans les mains dans le code, c’est bien ça. C’est bien une telle personne qui, selon moi, peut avoir un pouvoir d’« évangélisation » impactant et profitant à la Profession.

Si ce manager a une connaissance du code et de la technique, ça peut être bien comme ça peut devenir un sacré problème, notamment s’il a adopte la posture : je suis au-dessus de toi, j’ai aussi connu ce que tu fais alors je sais mieux que toi ce que tu dois faire.

Exact, et c’est un cas que j’ai observé. De la part d’un manager qui était bien une tête sans les mains. Ce n’était pas aussi incisif, mais en sous-texte il fallait comprendre « je sais mieux que vous que vous devez utiliser Machin au lieu de Truc » alors que cette décision nous revenait, pensions-nous. Pourquoi même était-il intéressé à ce point par nos choix de libs Python ?

Reconnaissons tout de même qu’il avait le pouvoir de négocier auprès de la direction des conditions de travail en adéquation avec les contraintes et les attentes du métier de la part des développeurs. Et c’est cette partie-ci que je trouve intéressante. C’est bien celle-là qui contribue, je pense, à permettre aux aspirants craftmen de l’entreprise de s’épanouir et de fournir un travail solide et sérieux, forgeant la réputation de qualité de l’entreprise.

Quand je parlais d’opportunités intéressantes, je parlais bien de la propagation d’une vision, de la big picture. Pas du tout de ce qu’on pourrait appeler le « micro management des détails techniques », charge qui reviennent légitimement, je pense, aux tech leads et à leurs équipes.

Mais les dérives dont tu donnes des exemples, oui : elles existent et c’est malheureux.

+0 -0

Dans ce cas on est bien d’accord. Mais ce que tu appelles un manager "évangéliste du craft" (pour résumer), pour moi c’est un manager qui se comporte en excellent professionnel : il sait quand et pourquoi l’équipe ne peut pas s’engager, il sait que quand elle dit non, c’est que c’est dans le meilleur intérêt de tout le monde, et donc au lieu de faire du forcing, il cherche avec tout le monde des solutions.

C’est le genre de manager qu’une équipe de bons développeurs a envie de "couvrir", quoi.

Par contre ça demande bel et bien un jeu de compétences différent (mais pas complètement disjoint) d’un excellent développeur. C’est pour ça que je dis que ce n’est pas le même métier.

+1 -0

Par contre ça demande bel et bien un jeu de compétences différent (mais pas complètement disjoint) d’un excellent développeur. C’est pour ça que je dis que ce n’est pas le même métier.

nohar

Je veux bien l’entendre, dans ce cas :)

Je pense que je voulais surtout évacuer l’idée selon laquelle un développeur aspirant à devenir manager n’était pas un « vrai », pas un Craftman, une personne à fond dans la logique du « si t’es toujours développeur à 30 ans t’as raté ta carrière », voire une personne qui commettra un affront en reniant ses valeurs. Non pas que tes propos en particulier le suggèrent, mais c’est tout de même une impression ambiante que l’on peut ressentir dans la profession. Or, je ne suis pas d’accord avec cela, car un développeur qui compte devenir ce que tu appelles un « un manager qui se comporte en excellent professionnel », je trouve ça très positif et il en faut !

+0 -0

Bien sûr !

D’ailleurs c’est aussi une remarque importante que tu fais, le software craftsmanship n’a rien d’un genre de secte élitiste. Le but du jeu n’est pas de savoir qui est "un vrai" ou qui n’est pas "un vrai" : c’est juste de garantir du bon travail en sortie.

D’ailleurs, beaucoup de gens refusent l’étiquette de craftsman tout en se comportant en "craftsmen". C’est pas un "label qualité", quoi. C’est plutôt un chemin que l’on se propose de suivre avec les autres professionnels qui sont poussés par le même but du travail bien fait.

Si on dévie en cours de route pour faire un autre métier, ça n’a rien de mal ni de répréhensible, il faut de tout pour faire un monde et chacun doit faire selon ses aspirations. Quand je dis que le software craftsmanship ne s’adresse pas trop à ces gens-là, c’est juste parce que leur finalité n’est pas de devenir d’excellents développeurs, mais autre chose, de peut-être tout aussi excellent.

+0 -0

Bonjour,

Merci pour ce billet très intéressant. J’y retrouve des choses vécues au boulot, dont celle d’avoir des difficultés à dire non au client, et de dire OK pour faire passer des carrés dans des trous ronds même si on sait d’avance qu’on n’y arrivera pas.

Première question:

  1. le client vient voir le manager
  2. les développeurs disent au manager qu’il faut 6 mois
  3. Le manager dit au client qu’il y en a pour 6 mois
  4. Le client répond au manager: alors vous me le faites en 4 mois
  5. Le manager dit OK ça sera fait en 4 mois.
  6. Au final les développeurs ont une deadline qu’ils n’ont pas choisie et doivent faire avec

Comment on fait dans cette situation ? Qui est-ce qui n’a pas été proffessionnel ici ? Est-ce que le manager aurait dû dire non au risque de perdre sa place ? Ou bien le problème fondamental, c’est en fait la méconnaissance du client sur le travail qu’il demande ?

Si on remplace le manager par un architecte, il ne viendrait à l’idée d’aucun client d’imposer que la maison soit construite en 4 mois au lieu de 6. Donc on est bien d’accord, il n’y a qu’en informatique que ça peut arriver…

En introduction, Nohar, tu dis avoir remboursé ta dette technique. Ce serait intéressant que tu expliques dans un autre billet comment tu as réussi ce que j’ai l’impression d’être un exploit, et plus généralement comment tu l’as gérée. J’ai l’impression que la norme, c’est plutôt qu’on n’arrive jamais à la rembourser, et au contraire qu’elle s’agrandit inexorablement jusqu’au point où, fatalement, la seule solution pour avancer est un reboot du projet; après quoi, évidemment, on recommence encore et encore. En d’autres termes on ne se pose jamais vraiment les questions que tu abordes dans ton billet.

Vos discussions sur les managers me font rappeler quelque chose que j’avais lu il y a longtemps, depuis je n’ai évidemment plus la source.

Une étude américaine expliquait que tant qu’on est bon dans son domaine, on gravit les échelons, jusqu’à atteindre une position dans laquelle on est incompétant. A partir de là on ne bouge plus. Le corrolaire, c’est qu’on passerait ainsi le plus clair de son temps dans une position où on est incompétant ! Par appât du gain, on ne resterait pas au niveau N -1, là où on serait pourtant le meilleur !

du coup je ne crois pas qu’on soit des ratés à rester développeur toute sa vie sans jamais devenir chef. C’est une question de … sagesse peut-être ? ON a la chance de faire un métier pour lequel on est passionné, alors profitons-en, on n’a pas besoin de grimper à tout prix.

+0 -0

Vos discussions sur les managers me font rappeler quelque chose que j’avais lu il y a longtemps, depuis je n’ai évidemment plus la source.

Une étude américaine expliquait que tant qu’on est bon dans son domaine, on gravit les échelons, jusqu’à atteindre une position dans laquelle on est incompétant. A partir de là on ne bouge plus. Le corrolaire, c’est qu’on passerait ainsi le plus clair de son temps dans une position où on est incompétant ! Par appât du gain, on ne resterait pas au niveau N -1, là où on serait pourtant le meilleur !

Principe de Peter. Un principe purement empirique et en partie satirique. C’est intéressant en soi, mais ce n’est pas une étude fiable. Plus un point de reflexion à garder en tête.

+2 -0

Comment on fait dans cette situation ? Qui est-ce qui n’a pas été proffessionnel ici ? Est-ce que le manager aurait dû dire non au risque de perdre sa place ? Ou bien le problème fondamental, c’est en fait la méconnaissance du client sur le travail qu’il demande ?

Celui qui a mal réagi c’est le manager oui. Il n’aurait pas dû prendre un engagement sans consulter l’équipe, et il aurait dû répondre : "4 mois, ça semble compliqué, il faut changer le scope, je vais reboucler avec les développeurs et voir ce que l’on peut vous proposer pour dans 4 mois".

Le problème, ici, c’est vraiment qu’il a contracté un engagement que les devs ne peuvent pas prendre. Et dans ce cas, le rôle d’un développeur c’est d’expliquer au manager "écoute non, là il faut que tu revoies avec le client mais ça ne tient pas, c’est impossible : on se met d’accord avec lui sur ce qu’on enlève du scope".

Le pire qui puisse arriver dans cette situation, c’est le manager qui dit à la fois "oui oui" au client (oui oui t’auras ce que t’as demandé) et "oui oui" aux développeurs (oui oui on va renégocier). Il faut être vigilent à ce genre de trucs, et si le manager nous dit "oui on va renégocier" lui demander à quelle date, pour participer à la réunion et expliquer ce qui est faisable ou non au client.

Le livre de Uncle Bob que je cite dans le billet aborde assez longuement ce genre de situations avec des exemples et des dialogues.

Après, "4 mois", c’est quand même long pour un projet de dev, le mieux c’est quand même d’itérer avec le client toutes les deux semaines ou tous les mois pour lui livrer régulièrement quelque chose qui marche (même incomplet au niveau des features), recueillir son avis et corriger le tir. Agile, quoi.

Et en fait, on pourrait résumer toute cette partie de Agile en un seul principe : le client final et le développeur qui discutent directement.

Le fait d’avoir remboursé ma dette technique, c’est dû à plein de trucs particuliers à mon cas :

  • D’abord je l’ai sévèrement contrôlée dans le sens où j’ai essayé d’en contracter le moins possible.
  • Ensuite, j’ai eu des périodes avec très peu de dev à faire et plus d’exploration, et j’ai investi de ce temps sur le remboursement (écriture des tests, etc). Tout le monde n’a pas la chance de pouvoir faire ça.

Maintenant par contre, pour éviter de contracter à nouveau de la dette, j’ai un code qui n’est pas complètement couvert "mais quasiment" (aujourd’hui il est à 85%, c’est pas encore foufou mais honorable), et je me discipline pour travailler systématiquement en TDD. Une tâche n’est pas finie quand la refacto n’est pas faite. La refacto est faite en même temps que je développe, par toutes petites touches (par construction grâce au TDD). Et en vertu de TDD chaque nouveau code testable que j’ajoute dans mon projet (c’est-à-dire quasiment tout, en fait, sauf les fonctions main de mes binaires ou les bords qui sont vraiment très fins — requêtes DNS, connectivité réseau, chargement de la conf… —) est automatiquement couvert à 100% de tests unitaires.

Tout ce qui est couvert est par définition1 vachement plus facile et vachement plus rapide à refactoriser. En conséquence, je ne remets aucune refacto ni aucun test à plus tard : ça fait partie de la feature ou du bug de refactoriser le bout de code concerné.

Et jusqu’à maintenant, sans avoir beaucoup de recul toutefois, ce que je peux dire c’est que je ne livre pas mes features moins vite pour autant. Par contre j’ai gagné masse de confiance quand je déploie.

Du coup je pense qu’un futur billet vraiment intéressant devrait porter sur le TDD. Expliquer ce que c’est, ce que c’est pas, comment ça se pratique précisément, comment on s’entraîne, comment on rend notre code testable, etc.

Vos discussions sur les managers me font rappeler quelque chose que j’avais lu il y a longtemps, depuis je n’ai évidemment plus la source.

C’est le syndrôme principe de Peter. « Toute personne progresse dans la hiérarchie jusqu’à atteindre son niveau d’incompétence maximal ».

PS: J’avais pas vu la réponse de @Gabbro :p

  1. À une seule condition : que ce soit des bons tests et pas juste des tests écrits connement "pour faire du coverage" en atteignant les lignes pas couvertes sans les tester. Si une ligne n’est pas couverte, la première question à se poser, c’est pas "comment j’écris le test pour l’atteindre", mais plutôt "est-ce qu’elle peut/devrait être atteinte en prod ?", et parfois, au lieu de changer le test, il suffit de dégager le code mort pour pour augmenter la couverture. :) ↩
+1 -0

Si on remplace le manager par un architecte, il ne viendrait à l’idée d’aucun client d’imposer que la maison soit construite en 4 mois au lieu de 6.

QuentinC

Ou alors ça donne un film à base d’alexandrins, de bonnes et mauvaises situations et de potion magique :D

+4 -0

Si on remplace le manager par un architecte, il ne viendrait à l’idée d’aucun client d’imposer que la maison soit construite en 4 mois au lieu de 6. Donc on est bien d’accord, il n’y a qu’en informatique que ça peut arriver…

En fait, les contraintes débiles (dont des délais intenables) il y en a dans tous les domaines, et pas uniquement en informatique. L’un des exemples les plus connus et les plus couteux, c’est la centrale EPR d’Olkiluoto 3 en Finlande, où le consortium piloté par Areva a, fin 2003, vendu la construction d’un réacteur nucléaire de nouvelle génération (pas encore prototypé) pour construction en 4 ans (chantier prévu de 2005 à 2009), alors qu’ils n’avaient pas l’expérience d’un tel projet. Résultat : la fin du chantier est maintenant prévue pour début 2022 (… il a bien commencé en 2005, mais cette nouvelle date devrait être tenue) et le cout estimé est passé de 3 à plus de 8,5 milliards de dollars.

À plus petite échelle, un été je bossais sur le chantier de rénovation d’une école (donc avec une deadline relativement impossible à déplacer…). On devait tirer le nouveau gros câble d’arrivée électrique. Le chef me dit d’aller guetter l’arrivée de l’aiguille à la plaque au milieu de la cour. J’y vais et… pas de plaque. On regarde nos plans, il était bien censé y avoir un regard avec une plaque à cet endroit. On va chercher l’architecte, qui finit par nous expliquer que le regard du milieu de la court a été supprimé « parce que c’était moche » (et donc on a dû sortir le robot pour passer ce câble…)

Dans encore un tout autre domaine, voir ce topic sur les demandes d’Interflora aux fleuristes.

En fait, on trouve même ce genre d’exemples dans le domaine médical (oui, ceux-là même qui sont qualifiés de dingues dans le billet, et qui le sont).

C’était des exemples qui n’ont rien à voir les uns avec les autres sauf cette généralité : des gens qui font n’importe quoi (des managers qui promettent l’impossible, des clients qui exigent l’impossible, des commerciaux qui vendent l’impossible, des chefs qui veulent juste asseoir leur pouvoir), il y en a partout, dans tous les types de projets.

La spécificité en informatique, c’est qu’en l’absence de produit concret (on ne voit jamais visuellement la taille ou la complexité d’un projet, c’est incompréhensible pour le non-expert, alors que n’importe qui peut voir qu’une centrale nucléaire c’est gros et cher) ça peut être difficile d’expliquer pourquoi la proposition ou la décision sont imbéciles. Le fait que l’informatique est souvent vue comme un centre de cout même quand c’est objectivement un outil de production n’aide vraiment pas.

Sinon, merci @nohar d’avoir mis à jour le billet, je le trouve infiniment plus clair ainsi. J’ai mis à jour pour masquer (en spoiler) ce qui est devenu obsolète dans mes précédents commentaires.

J’ai l’impression qu’en fait la notion de craftmanship pourrait s’appliquer à n’importe quel travail, et est d’autant plus pertinente que le métier est spécialisé.

Là où je ne suis pas d’accord avec la proposition d’origine, c’est que pour moi il n’est pas nécessaire d’aimer son métier pour bien le faire. Cependant, c’est d’autant plus facile de bien faire son métier si on l’aime que le métier demande de mobiliser des compétences spécialisées et évolutives – et le développement informatique est plutôt extrême de ce point de vue.

Je pense aussi que si on prends le problème du point de vue du marché, la nécessité d’être passionné par son travail est d’autant plus importante que le travail est mal considéré financièrement, et que le marché est saturé. Parce que dans des conditions de travail mal payé et difficile à trouver, il devient vraiment nécessaire d’être passionné. Et d’ailleurs certains secteurs en profitent en soutenant plus ou moins explicitement que puisque le métier est une passion, il n’a pas besoin d’être bien payé.

Le marché du développement informatique étant plutôt un marché de pénurie (ce qui permet d’être très bien payé et de trouver très facilement du travail indépendamment de ses compétences réelles), ça explique pourquoi on a des gens qui font du développement informatique sans s’y intéresser, alors que ça nécessite objectivement de mobiliser beaucoup de compétences pour être fait correctement.

En fait je pense que cette notion de craftmanship amène à plusieurs axes de réflexions qui me semblent intéressants :

  1. En tant que passionné, comment est-ce que je combine cette passion et mon travail pour rendre mon travail agréable sans ̣me battre contre la direction (qui peut ne pas comprendre les besoins que je lui expose) ?
  2. En tant que passionné, comment j’évite que travail et passion ne se marchent dessus ? (dans les deux sens : ramener du travail à la maison, ou que les projets perso débordent sur le boulot).
  3. En tant que passionné, est-ce que je n’ai pas des choses à tirer de ma passion pour que mes collègues non-passionnés (et ils ont le droit, et ça n’est pas dépréciatif) aillent quand même dans la direction du travail bien fait plutôt que du minimum syndical ?

Concernant la formation, de mon point de vue l’employeur doit permettre la formation continue de ses salariés pour maintenir un bon niveau de qualité (et c’est… beaucoup trop rarement le cas, alors qu’on est dans l’un des domaines où l’autoformation est la plus facile). Mais effectivement, la personne qui veut changer de boulot (ou le freelance) doit se former elle-même pour trouver son nouveau poste (ou client), ça n’est pas à son employeur actuel de financer ça.

Le cas particulier des (très) vieux projets me semble particulièrement intéressant dans le contexte du software craftmanship, parce que souvent on y trouve des équipes qui sont confortablement installée dans leur routine obsolète, et qui ne comprennent pas le besoin de changer. Et inversement, le nouveau venu, surtout s’il est bien à jour sur les dernières technologies, va avoir énormément de mal à comprendre le pourquoi du comment, et les implications réelles de toutes ses propositions de changement qui sont pourtant bonnes en théorie1.

Enfin, sur le comportement des uns et des autres, pour moi c’est un cercle vicieux : trop de développeurs se comportent en divas, et trop de développeur sont considérés comme des enfants gâtés incapables de se gérer par leurs supérieurs ; les comportement se nourrissant mutuellement. Le fait que les compétences de communication ne soient pas spécialement nécessaires à faire « un bon développeur »2 (et donc pas ou mal enseignées dans les écoles d’informatique) n’aide pas non plus à résoudre ce problème.

  1. Le saviez-vous ? On peut casser du code JS en changeant un var par un const, parce que d’une part var permet les définitions multiples sans broncher, et d’autre part un const redéfinit plante tout ce qui suit dans le code JS… sans interdire l’interprétation du code présent avant l’erreur. C’est un exemple des blagues dont on ne peut pas avoir conscience en ayant toujours fait « du bon travail ».↩
  2. Dans le sens du « développeur rock-star » tant vanté par les startups ; dans la réalité je préfère infiniment travailler avec un développeur bon-sans-plus voire même moyen-qui-fait-ses heures mais sympa et qui communique bien, plutôt qu’avec quelqu’un de super efficace sur le code et toxique pour tout le reste.↩
+0 -0

J’ai l’impression qu’en fait la notion de craftmanship pourrait s’appliquer à n’importe quel travail, et est d’autant plus pertinente que le métier est spécialisé.

Alors le Craftsman de Sennett est le premier tome d’un essai en trois volumes, les deux autres volumes concernant le soldat et le prêtre. Du coup effectivement, le concept couvre un nombre assez impressionnant de professions.

Là où je ne suis pas d’accord avec la proposition d’origine, c’est que pour moi il n’est pas nécessaire d’aimer son métier pour bien le faire.

C’est une question d’opinion, oui. Au fond je ne suis pas certain que ce soit absolument nécessaire pour tout le monde. Je sais juste que ça l’est pour moi.

Ce qui est certain, par contre, c’est que notre travail doit avoir un sens pour nous. Chaque individu est unique et aura des éléments différents pour définir le sens de son travail, des affinités, des intérêts et des valeurs qui lui sont propres. Mais ce n’est pas seulement pour s’épanouir que c’est nécessaire : ça l’est pour pouvoir se lever pour aller au boulot sur une base quotidienne sans en souffrir.

La seule chose qui définit vraiment le craftsmanship, je le répète, mais c’est le fait de considérer le "travail bien fait" (une prestation professionnelle de qualité) comme une fin en soi.

Cette notion de "travail bien fait" est volontairement vague, justement parce que ça dépend des professions et des contextes. Dans le cas du logiciel, par contre, ce n’est pas très compliqué de le définir grosso modo, à quelques variations près, comme un logiciel livré en temps et en heure, qui fonctionne comme prévu, qui résout efficacement les problèmes de ses utilisateurs, et que l’on peut maintenir indéfiniment.

En ce qui me concerne, et ça par contre ça m’est personnel, j’ajoute à cela sans bouffer plus de ressources qu’il n’est raisonnablement nécessaire.

Les 3 questions que tu poses sont très intéressantes.

En tant que passionné, comment est-ce que je combine cette passion et mon travail pour rendre mon travail agréable sans ̣me battre contre la direction (qui peut ne pas comprendre les besoins que je lui expose) ?

Robert C. Martin a écrit une note de bas de page dans son livre Clean Coder, expliquant que de son point de vue, c’est forcément une lutte. Ça fait partie de la profession de faire comprendre à un client/employeur/utilisateur ce que l’on peut faire pour lui, et ce que l’on attend de lui pour le faire. D’apprendre à dire "non" quand il faut et comme il faut, ou bien "oui" quand il faut et comme il faut. Du moment que l’on se concentre sur l’aspect pragmatique de la chose, que l’on est capable de lui montrer que ce que l’on lui demande est dans son intérêt à lui, n’importe qui de raisonnable devrait pouvoir être convaincu.

Malheureusement, on ne peut pas convaincre tout le monde. Des gens bornés, il y en a aussi partout. Et dans ce cas, ce qui est préconisé, c’est plutôt… d’arrêter de se fatiguer et trouver un nouvel employeur chez qui on pourra faire du bon boulot. Tout bêtement.

En tant que passionné, comment j’évite que travail et passion ne se marchent dessus ? (dans les deux sens : ramener du travail à la maison, ou que les projets perso débordent sur le boulot).

Ça, c’est la discipline professionnelle. La gestion du temps, la séparation travail/vie privée, etc. C’est une infinité de micro-comportements, micro-compétences, d’habitudes à acquérir… et il faut commencer par être convaincu que cette discipline est bonne à acquérir.

En ce qui me concerne, par exemple, je sais que je ne suis pas irréprochable sur ce sujet, mais certains changements à venir vont très bientôt m’imposer de devenir vraiment carré. Et j’envisage pour ça de m’essayer à la méthode Pomodoro. Pour tout faire dans les temps, et m’habituer à changer de contextes de façon plus fluide.

En tant que passionné, est-ce que je n’ai pas des choses à tirer de ma passion pour que mes collègues non-passionnés (et ils ont le droit, et ça n’est pas dépréciatif) aillent quand même dans la direction du travail bien fait plutôt que du minimum syndical ?

Sandro Mancuso s’étend sur ce sujet. Comment emporter l’adhésion de mon équipe pour y instaurer une culture de l’apprentissage (a culture of learning) ?

Le mieux qu’on puisse faire est de proposer et de montrer l’exemple : "regardez, j’ai essayé ça, ça m’a fait gagner du temps, j’ai envie de creuser, ça vous dit ?". Il "suffit" qu’une autre personne de l’équipe se sente intéressée pour faire grossir un mouvement que l’on peut généraliser progressivement.

Le meilleur levier, c’est qu’ils se rendent compte que c’est du temps et des efforts de gagnés.

Par exemple, tout le monde ne s’amuse pas forcément en faisant du TDD (moi je trouve que ça rend la tâche encore plus marrante…), par contre n’importe qui peut mesurer le temps, se rendre compte qu’il a été vite, et que dans le même temps il est devenu beaucoup plus confiant sur la qualité.

L’autre truc, c’est de proposer une séance de pair programming à un collègue qui est visiblement en train de galérer. Chercher avec lui, lui poser des questions, par exemple : "ça fait 10 minutes que tu testes ce bout de code en recompilant/lançant et en cherchant tes print dans les logs, tu crois pas qu’on pourrait écrire un test pour que tu puisses vérifier les choses instantanément ?".

J’ai l’impression que le pair programming est la pratique la plus sous-estimée et celle qui lève le plus de boucliers lorsqu’on la mentionne, les gens pensent que c’est perdre du temps en utilisant 2 fois plus de ressources pour le même résultat. Là encore, on ne peut pas convaincre tout le monde, mais il suffit peut-être de le faire sans l’appeler comme ça pour qu’ils se rendent compte que ça marche. :p

+1 -0

Du coup je pense qu’un futur billet vraiment intéressant devrait porter sur le TDD. Expliquer ce que c’est, ce que c’est pas, comment ça se pratique précisément, comment on s’entraîne, comment on rend notre code testable, etc.

Volontiers, je me réjouis d’avance de le lire.

J’entends partout parler de TDD et à quel point c’est super bien, mais n’ai jamais réellement tenté de le mettre en pratique. C’est difficile de se lancer. Peut-être que tu pourras donner le bon déclic ? Du coup je suis très sceptique: comment peut-on écrire un test avant même d’avoir réfléchi à l’implémentation de la fonctionnalité ? Il faut au moins savoir ce qu’on va faire dans les grandes lignes pour savoir quel résultat attendre dans le test non ? ON dirait qu’au début on commence par écrire des tests qui ne compilent même pas, ça me parait complètement idiot… donc je dois avoir mal compris comment ça marche.

+0 -0

@QuentinC Tu poses piles les questions qu’il faut, en fait.

Dans les faits, oui, il y a bien une bonne façon de montrer comment on s’y prend et comment on s’entraîne à l’utiliser en même temps, c’est ces exercices que l’on appelle les katas.

Tu prends un problème qui se résout en 30 minutes maximum et tu t’en fiches de connaître déjà la solution, ce à quoi tu t’entraînes, c’est plutôt à toutes les micro-décisions et les étapes qui t’emmènent jusqu’à le résoudre, pour qu’elles deviennent des réflexes. Pour cela tu résous ce problème en reproduisant délibérément chaque idée, chaque pensée, chaque mouvement dans ton éditeur ou ton IDE, et ce faisant tu optimises toutes ces micro-réflexions et ces gestes. J’étais sceptique au départ, mais au bout de quelques itérations (2–3 jours), perso je sentais déjà plusieurs de mes habitudes de longue date bouger et se caler dans le flot. J’ai appris une ou deux commandes supplémentaires de vim (que j’utilise depuis plus de 10 ans), et systématisé une routine pour quand je démarre un ticket.

Dans les faits, tu commences à concevoir ton code et la façon dont il s’utilise en même temps, et c’est assez plaisant de voir comment tout se clipse en place simultanément.

Parce que oui, je préfère le préciser mais TDD ne consiste pas à écrire plein de tests avant d’écrire plein de code.

Mais :

  • Un bout de test, tout juste ce qu’il faut pour échouer,
  • Le bout de code minimal qui passe ce bout de test au vert,
  • Tout est vert et couvert, tu refactorises les tests et le code pour que ce soit joli.
  • La suite du test, jusqu’à la prochaine assertion qui échoue,
  • Le bout de code minimal,
  • Refacto,
  • Etc.

Cela demande effectivement au depart d’écrire un bout de test qui ne compile pas : il instancie un objet et appelle les méthodes tels que tu veux les utiliser, mais 30 secondes ou une minute plus tard ce test compile.

C’est une étape indispensable quand on débute, parce que les questions que tu t’y poses sont importantes, donc tant que ce n’est pas naturel de te poser ces questions en premier, tu ne peux pas vraiment t’autoriser à la zapper.

Ce qu’il en résulte, c’est le design minimal, le plus simple possible, qui résolve ton problème. Écrit dans un code lisible (parce que dès que ton test passe au vert, tu refactorises tout ce que tu vois qui peut l’être, c’est automatique).

La boucle de feedback hyper rapide que cela engendre est telle que tu te libères énormément de temps de cerveau pour penser à ton design, justement.

+0 -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