Software Craftsmanship ou la déchéance ?

Suite aux attaques en règle de Kevin et le drama qui s’en est suivi, j’ai beaucoup réfléchi car j’entendais une petite musique qui me gênait.
Dans mon enthousiasme, et même une forme de ferveur, de défendre une cause noble à mes yeux, le bonheur des développeurs, j’ai eu l’impression de franchir une ligne rouge.
Alors je me suis remis en question.

Développeur perdu

Suis-je devenu (trop) tranchant ?

C’est Robin qui m’a alerté en premier :

Il entendait des airs de Michael dans mon discours. 😳
Lui qui me trouve trop bisounours !

Premier signal. Premier questionnement.
Le ton est plus ‘virulent’. Je mets ça sur le compte du drama.
Pour que la tension joue son effet, il faut justement de la tension… Je me dis que j’en ai fait peut-être un peu trop.

Puis c’est au tour de Benoit de m’interpeler :

Et là, ça fait mouche.

En particulier un passage sur ma réponse à la réponse de Kevin me revient en tête :
“[…] je dirais que 80% des devs n’ont strictement rien à faire du software craftsmanship et de ce qu’il pourrait leur apporter.
Ils codent sans trop se poser de questions et la vie est belle. Ils s’habituent souvent à une forme de médiocrité et se font une raison […]”

Si tu connais mon travail, tu sais qu’il y a quelque chose qui m’énerve plus qu’une classe de 4.000 lignes avec 12 niveaux d’indentation : c’est le connard qui te dit que tu fais de la merde.

Et là, cette question terrible me taraude : serais-je devenu ce connard ?
Suis-je en train de dire que si un développeur ne s’intéresse pas au software craftsmanship, il est condamné à faire du code médiocre toute sa vie ?

Et je suis obligé de reconnaitre que ça pourrait être perçu comme ça.
Peut-être même qu’il y a un fond de vrai là dedans…

Ce qui me pose poblème

Fondamentalement, ce qui me pose problème c’est le jugement que revêt cette sentence.
Je suis sincèrement convaincu que chacun fait ce qu’il veut, et surtout ce qu’il peut.
Après tout, si quelqu’un ne s’intéresse pas au craft, très honnêtement, je m’en moque. C’est en ça que je ne cherche plus à évangéliser depuis longtemps, même si j’ai à coeur de porter un message et de montrer qu’une autre manière de faire est possible.

En fait, c’est le mot ‘médiocrité’ qui me gêne : il contient cette idée de jugement et a une connotation péjorative.
Pourtant le Larrousse définit médiocre comme quelque chose “qui est très au-dessous de la moyenne, qui est insuffisant ; modique, modeste”.
Finalement la définition nous renvoie à une logique d’évaluation ou de mesure, pour définir une moyenne et ainsi pouvoir se positionner.
La définition ne contient pas cette idée de jugement.
Mais j’ai l’impression que l’usage courant oui.

Du coup, si on enlève cette idée de jugement et qu’on le ramène à une évaluation objective, que reste-t-il ?

Une question de compétences

Cela revient à poser la question suivante : est-ce que je considère que pour sortir de la médiocrité, du moyen, en gros devenir un bon développeur, il faut s’intéresser au craft ?

Et bien en fait, je pense que oui. 🤷‍♂️

Pour devenir un bon développeur, il me semble important de connaitre les principes d’architecture majeurs, maîtriser certaines techniques de développement comme le TDD, savoir collaborer en binomage ou mob, savoir écouter son client et comprendre son besoin, savoir communiquer entre les membres de l’équipe, s’intéresser à la manière de produire du logiciel, savoir automatiser un build.
Bref tout ce que le craft apporte.

Si ce n’est pas le seul, c’est clairement un chemin possible. Et à vrai dire je n’en connais pas d’autres, ce qui ne veut pas dire qu’ils n’existent pas, juste que je ne les connais pas. C’est peut-être là mon angle mort, mon point aveugle. Alors si tu en as à proposer, je suis preneur.

Est-ce que tous les développeurs devraient connaitre le contenu du livre Sofware Craft ?
Pour moi, oui.
Si c’était le cas, notre industrie s’en porterait mieux, j’en suis convaincu.
Si en plus les développeurs appliquaient 10% de ce que le livre contient, ça augmenterait déjà la performance économique des sociétés qui les fait travailler tout en améliorant des conditions de travail.

Nécessaire, mais insuffisant

Est-ce le seul livre à livre ?
Clairement pas.

Devenir un maître en craft serait-il suffisant suffisant pour devenir un bon développeur ?
Non, clairement pas non plus.
Par exemple, il faut maîtriser sa stack technique ou son IDE.
Les soft skills prennent aussi un place importante et sans un travail sur soi, cela me semble difficile de bien communiquer avec son équipe.

Finalement, faute de référentiel de compétence, chacun continuera d’y mettre ce qu’il veut derrière ‘devenir un bon développeur’.

Et c’est ok.

Maintenant, tu sais quels sont mes critères. Et j’accepte bien volontiers que les tiens soient différents.

C’est peut-être ça qu’il faudrait faire : créer un référentiel commun. Peut-être qu’il existe déjà d’ailleurs.
Mais quand je vois que chaque société créé un chemin de carrière qui lui est propre, je m’interroge sur la faisabilité d’une grille universelle de compétences.

Le software craftsmanship est-ce la seule voie ?
Bien sûr que non. Penser l’inverse pousserait dans une guerre de religion stérile.
Et puis encore une fois peu m’importe : mon but n’est pas de convertir qui que ce soit, mais de proposer un chemin.
Et j’accepte bien volontiers qu’il y en ait d’autres, même si certains me rendent sceptiques : après tout chacun est sensible à des critères différents et je suis heureux si les gens sont heureux ! 😘

6 réflexions sur « Software Craftsmanship ou la déchéance ? »

  1. La fierté de faire du craft semble vous avoir fait basculer effectivement du côté de l’arrogance et de l’élitisme. Félicitations, vous faites parti des 4% (pour reprendre l’article précédent) des meilleurs des meilleurs… suivant les critères d’évaluation énoncés par ces même 4%.
    C’est probablement ce que reprochent les détracteurs : dès qu’on se met à sortir des chiffres pour se comparer aux autres, c’est qu’on a basculé du côté obscur. Alors que beaucoup de devs utilisent déjà une bonne partie de la boîte à outils qu’est le craft, en n’en ayant effectivement rien à carrer que ce soit dans le craft et que d’autres viennent leur dire comment ils devraient bosser.

    Vous ne voyez pas qu’évaluer « objectivement » que 80% des devs se complaisent dans ce qui « est très au-dessous de la moyenne » pour reprendre Larousse ou dire qu’ils se complaisent dans le caca c’est la même chose ?
    Comment évaluer/juger (c’est un synonyme) objectivement sur des critères subjectifs ?

    Pour reprendre votre liste sur comment devenir un bon développeur, il vous semble important de
    – connaitre les principes d’architecture majeurs => oui, c’est mieux pour faire des choix, même si j’imagine que déjà sur la liste de quels sont ces principes majeurs tous ne seraient peut-être pas d’accord pour y mettre la même chose. On peux aussi être très bon sans savoir les nommer et les énumérer.
    – maîtriser certaines techniques de développement comme le TDD => non. Je préfère un dev qui aura pensé et géré manuellement tous ses cas, mieux, qu’il ait mis des tests automatisés dessus avant la fin de son dev, plutôt qu’un gars qui applique bien son TDD en oubliant systématiquement la moitié des cas. Le second ne sera jamais un bon dev pour moi. Jamais. Les tests automatisés sont hyper importants selon moi (non-régression, documentation) mais le TDD me parait « juste » un meilleur moyen de les exploiter, pas un must have. Je sais que ça peux permettre de faire émerger le code via les tests de manière potentiellement inattendue, ça fait réfléchir différemment à la solution, mais est-ce que ça engendre un gain pour autant ?
    – savoir collaborer en binomage ou mob => c’est bien pour le partage et sortir une solution potentiellement mieux réfléchie, mais déjà ce n’est pas un gage, puis en quoi être un mauvais communiquant/solitaire ferait de quelqu’un un mauvais dev ?
    – savoir écouter son client et comprendre son besoin => ça c’est la base effectivement, j’aurai surtout ajouté qu’il faut savoir répondre efficacement à ce besoin. Mais ce n’est pas particulièrement le craft qui enseigne ça, à mon avis.
    – savoir communiquer entre les membres de l’équipe => c’est appréciable c’est sûr. Mais est-ce qu’on ne va pas taper un peu loin de la définition du dev et là encore en quoi le craft est pertinent sur ce point ?
    – s’intéresser à la manière de produire du logiciel => je ne suis pas sûr de ce qu’on entend par là, c’est trop vague, je ne vais donc pas émettre d’avis sur ce point
    – savoir automatiser un build => non, quelqu’un peut très bien le mettre en place au sein du projet pour vous sans que ça fasse de vous un mauvais dev.

    Si on n’applique qu’une partie du craft, on est un semi-bon dev ?

    ’Fin voilà, gros pavé, désolé, et beaucoup à charge alors que j’essaie également autour de moi de dispenser les bonnes pratiques et de me familiariser spécifiquement avec celles du craft, qui reprend énormément de trucs qui se faisaient déjà, sans un nom ronflant derrière pour unifier le tout.
    Mais justement, je tombe beaucoup trop souvent dans mes lectures/rencontres sur cet esprit élitiste de se sentir au dessus de la masse, de devoir suivre LA voie et lire des bouquins comme des bibles, alors que ce ne sont que des conseils et qu’on a « juste » posé un buzz word sur un ensemble de pratiques pré-existantes. Encore une fois, beaucoup font du craft sans le savoir.
    Ça me dérange beaucoup dans ma démarche ce prosélytisme, je n’ai pas envie de glisser du côté de ceux qui imposent leur vision comme une doctrine.

    1. Bonjour,

      Je trouve plutôt bienvenu de mettre un nom ronflant (en 2008/2009) derrière un ensemble de pratiques évoquées dans des livres, discutées dans des forums ou conférences depuis les années 90, car cela permet de discuter de la chose en sachant ce qu’elle regroupe/recouvre.

      Il serait intéressant de demander pourquoi certains (élitistes) considèrent que c’est La voie à suivre.

      Mon avis (de vieux) sur une partie de ce pourquoi : c’est la lassitude à se taper des sessions de debug pour des régressions, décrypter des implémentations exotiques (reverse engineering) qui ne sont en fait que des hybridations de concepts existants et documentés, etc…
      Ce sont des activités qui ne sont pas sans intérêt car chacun y apprendra des choses mais à un certain stade de sa vie professionnelle et aussi quand on a des contraintes de temps pour produire de la valeur, il est préférable de réduire leur occurrence : il semblerait que l’ensemble des pratiques software craft aident ces personnes en ce sens. Elles constatent que leur journée de travail sont différentes, elles se passent mieux.

      A partir de là, il est facile de croire que c’est La voie à défaut d’autres méthodologies documentées.

  2. Benoit, je pense qu’à partir du moment où on passe dans les extrêmes, on finit par juger les autres.

    Pour rester ouvert au débat et pouvoir discuter des sujets, il faut ce recul, cette ouverture d’esprit dont on manque quand on veut absolument convaincre l’autre.

    Concernant celui qui dit aux autres qu’ils font de la merde, en effet, ce n’est en rien constructif et cela peut être insultant.

    Je suis moi-même entrée dans ces travers quelques fois et après une prise de recul et des échanges avec divers dev, j’ai pu me faire « mon » idée et ne pas suivre un avis sans forcément en comprendre les enjeux.

    En réalité rien n’est tout blanc ou tou noir et selon nos objectifs, on doit prendre ce qui nous correspond pour avancer.

    Certains ce sera l’argent et la croissance uniquement.
    D’autres chercheront à faire un travail de qualité, en prenant le temps, quitte à ne pas faire autant d’argent.

    Si le but n’est pas le même, la méthode ne le sera pas non plus

  3. Article très intéressant et ta remise en question me fait te respecter encore plus !

    Oui c’est hyper agaçant d’entendre ce genre de propos qui seront forcément mal interprétés, en particulier quand on les reçoit derrière son écran 😉

    LinkedIn prône ces temps-ci un certain élitisme effectivement, et certains ne se prennent vraiment pas pour de la m**** et on un égo qui crève les plafonds !
    Ce n’est pas ton cas, et c’est pour ça que j’apprécie de te suivre 😉

    Tu dis des choses justes mais il est important de savoir garder une certaine mesure. Le craft est un apprentissage très long, et on en apprend toujours. C’est une étape de remise en question constante. Dans ce cas, n’est-on pas toujours « le médiocre » de quelqu’un d’autre ?

    1. « Dans ce cas, n’est-on pas toujours « le médiocre » de quelqu’un d’autre ? »

      Bien sûr que si.
      Mais ce n’est pas vraiment ce qui est important : la dynamique me semble prépondérante sur le niveau.
      Je préfère un développeur débutant qui se remet en question et qui avance qu’un développeur sénior qui stagne et reste sur ses acquis. Le débutant finira forcément par dépasser le senior.

  4. Le craft semble avoir pour but de faciliter le travail à ceux qui voudraient améliorer leurs approches. Personne ne dit que c’est LA voie, c’est juste que pour l’instant, on n’a pas trouvé grand chose de mieux.

    Rien d’ésotérique. Cela permet de formaliser.

    On sera dans l’erreur si on applique les principes à la lettre sans aucun esprit critique ni discussions régulières mais c’est valable pour tout.

    Les retex intéressantes fournissent quelques metrics qui peuvent justifier l’adoption de ce paradigme plutôt qu’un autre.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.