Le plus difficile dans le Software Craftsmanship ce n'est pas la technique. C'est l'Humain.
Temps de lecture : 10 min
Ce que vous allez lire : les différents types de développeurs et leur “compatibilité” avec le Software Craftsmanship
Je travaille professionnellement depuis août 2010, j’ai donc plus de dix ans d’expérience à ce jour. Pendant cette période, j’ai rencontré beaucoup de développeurs différents.
Même si je ne savais pas le nommer à l’époque, j’ai toujours eu à cœur de développer et partager ma passion pour la qualité du code, ma passion pour le software craftsmanship.
Cela fait donc plus de 10 ans que j’essaye, et je dois avouer que je n’ai toujours pas réussi à faire comprendre à tous les développeurs d’une même équipe les enjeux et intérêts du software craftsmanship.
Je ne perds pas espoir, car comme le dicton le dit : “seul on va plus vite, à plusieurs on va plus loin.” Mais peut-être devrait-il rajouter : “à condition de partager la même vision de la qualité”.
C’est tout l’enjeu de ce post ! Je vais tenter de résumer les grands profils de développeurs que j’ai pu rencontrer, ainsi que leurs points forts et leurs points faibles selon moi, à travers le prisme de ma propre vision de la qualité logicielle. Ce qui est donc entièrement subjectif, tout en respectant la façon de travailler de chacun, évidemment :)
Qu’est-ce que la qualité logicielle ?
Pour être sur la même longueur d’onde, il faut que vous compreniez ma vision de la qualité logicielle.
Comme je le mentionnais aujourd’hui dans un commentaire sur LinkedIn, je n’ai pas la prétention d’ériger haut et fort MA vision de la qualité logicielle.
J’ai l’humilité de reconnaitre que je ne pèse pas lourd dans le milieu, et je fais ainsi confiance à ceux qui ont éprouvés avant moi et depuis des dizaines d’années les problématiques que nous rencontrons tous les jours.
Voici pour moi les conditions de l’assurance d’une haute qualité logicielle :
👉 Une architecture testable
Une architecture testable impose de découpler son code, de séparer les concepts et les niveaux d’abstractions. On retrouvera alors des concepts comme l’inversion et l’injection de dépendances au sein d’une architecture Ports & Adapters (hexagonal architecture).
👉 Des tests automatisés
Le point précédent permet la rédaction de tests automatisés qui doivent a minima assurer les non-régressions. Le plus optimal restant selon moi de se laisser guider par le Test-Driven Development (TDD) afin d’avoir une vraie documentation vivante et des tests non fragiles (qui ne cassent que pour les bonnes raisons).
👉 Une pipeline d’intégration continue
D’un clic sur un bouton, ou lors d’un push, ou d’une simple commande en local, le logiciel doit pouvoir être testé / déployé sur un environnement le plus proche de la production possible.
👉 Des mises en production le plus fréquentes possible
L’ensemble des points ci-dessus permet de pouvoir livrer une nouvelle version en production plusieurs fois par semaine, voire plusieurs fois par jour, et ce, dans l’objectif d’avoir le plus rapidement possible un retour des utilisateurs finaux, pour ainsi améliorer l’existant en permanence. Cela implique d’avoir directement accès aux clients ou a défaut au responsables métiers.
👉 Une dette technique réduite et gérée
La dette technique ce sont tous les choix que l’on fait à un instant T pour nous faire gagner du temps. Temps que l’on emprunte donc au futur, car il s’agira ensuite de repasser sur ce code pour le refaire proprement, sans quoi la codebase deviendrait juste un énorme plat de spaghettis. Les points ci-dessus permettent de réduire la création de dette technique, mais cette dette est inévitable. Elle peut cependant être gérée et “remboursée” régulièrement.
Tout cela concerne donc surtout la partie technique du Software Craftsmanship. Et tout l’intérêt est d’arriver à partager cette vision pour que le niveau standard de l’industrie soit tiré vers le haut. Avec en ligne de mire, à ne jamais perdre de vue, la valeur ajoutée pour l’utilisateur final. Le partage de ces valeurs au sein de l'équipe, la gestion de l’Humain, c’est ce qu’il y a de plus difficile dans le Software Craftsmanship.
Pour appuyer mon propos, voici quelques types de développeurs que j’ai pu rencontrer dans ma carrière (ce n’était que des hommes, donc je vais employer “il/le” partout). Moi-même j’ai fait partie de plusieurs de ces catégories au fil de ma carrière. Aujourd’hui encore je me retrouve un petit peu dans plusieurs catégories.
Les différents types de développeurs et leur rapport au Software Craftsmanship
🤝 Le développeur Fidèle
Ce développeur est dans l’entreprise depuis de longues années. Il y a évolué, a probablement participé à ce qui fait le legacy aujourd’hui. Il se plaît dans sa boîte, n’est pas spécialement passionné par le code, et se satisfait donc de répondre simplement à ce qu’on lui demande.
Il se voit généralement comme un exécutant et quand il rentre chez lui le soir va laisser son ordinateur dans un coin, et ne plus toucher au code jusqu’au lendemain matin au bureau.
Toutefois, il arrive que ce développeur si attaché à son entreprise devienne force de proposition en parlant plus intensément avec le métier.
Ses points forts pour le Software Craftsmanship :
✅ connaît bien l’entreprise, et peut être un pont très efficace entre le métier et la technique.
✅ connaît bien le legacy et devient ainsi totalement indispensable quand il s’agit de repenser les différents éléments métiers au sein du legacy en vue d’une migration progressive
Ses points de friction avec le Software Craftsmanship:
❌ forte résistance au changement
❌ peut parfois avoir une vision produit qui se limite aux solutions techniques déjà implémentées dans l’entreprise.
❌ il peut avoir tendance à considérer que “on a toujours fait comme ça”, donc pas de raison que ça change
❌ comme il est dans l’entreprise depuis de nombreuses années, il s’est habitué à la qualité médiocre des produits actuels et considère donc une qualité sous-optimale comme une qualité “normale”. Les différents éléments du Software Craftsmanship deviennent donc de la surqualité pour lui.
👨🎓 Le développeur Ultra Perfectionniste
Ce développeur, assez souvent avec peu d’expérience concrète, est extrêmement renseigné sur la théorie. Il connaît tous les concepts, tous les design patterns, et cherchera donc à les appliquer partout, même dans les moments où il eut été plus judicieux d’opter pour une solution plus simple.
Ses points forts pour le Software Craftsmanship :
✅ peut rapidement devenir référent “technique” sur la théorie. Il va proposer des solutions dont les autres développeurs n’ont probablement jamais entendu parler sous ce nom.
Ses points de friction avec le Software Craftsmanship:
❌ un manque criant de pragmatisme. Il va vouloir utiliser un bazooka pour tuer une mouche. Il va par exemple considérer qu’il faut partir immédiatement sur de la clean architecture pour tous les projets, sans arriver à expliquer que le plus important n’est pas la clean architecture en elle-même mais la testabilité avec l’injection de dépendance notamment. Certains éléments de code bénéficieraient plus d’un simple transaction script, mais ça le développeur ultra perfectionniste ne peut s’y résoudre.
❌ une frustration et donc une démotivation qui arrivera tôt ou tard.
👨💻 Le développeur Ultra Pragmatique
C’est le penchant inverse du développeur ultra perfectionniste. Ce développeur érige en valeur absolue le principe yagni (You Ain’t Gonna Need It) qu’il comprend à l’envers, et qu’il utilise pour justifier le fait qu’il n’y a pas le temps pour les tests, qu’il n’y a pas besoin d’architecture logicielle, que de toute façon “c’est juste un CRUD”, etc.
Ses points forts pour le Software Craftsmanship :
✅ il peut rapidement faire des spike complets pour tester différents types de solution.
✅ il ne s’embarrasse pas des principes de clean code / de testabilité, etc., le code jetable est son terrain favori, sur lequel personne ne peut le battre. Quand il s’agira de tester une nouvelle approche pour un futur développement, il peut être l’homme de la situation, à la condition sine qua none que l’on jette vraiment le code après…)
Ses points de friction avec le Software Craftsmanship:
❌ eh bien malheureusement un peu tout…Son code rapidement écrit et fonctionnel en apparence ravira le management, et ce code vivra bien plus longtemps que prévu initialement, et sera utilisé dans des cas absolument pas envisagés au préalable.
❌ s’ensuivront de longues semaines / années où ce code sera le cauchemar de tous les autres développeurs qui devront le récupérer, car il sera buggué, et très difficile à tester
🥷 Le développeur Mercenaire du Code
Ce développeur ressemble à l’Ultra Pragmatique, mais fait quand même montre d’une expérience plus poussée, et d’un sens de la qualité bien plus aigu. Ce développeur est une machine. Il va débiter du code à une vitesse incroyable par rapport aux autres développeurs.
Généralement, c’est quelqu’un de confiant dans son code, et qui va donc 9 fois sur 10 commencer par écrire le code directement, pour ensuite écrire un test de non-régression.
Tout repose sur sa vision court-termiste, voire fataliste, de la qualité logicielle. Changeant régulièrement de mission, il se retrouve face à deux cas de figure :
soit il intervient pour aider une équipe au sein d’une codebase existante
soit il intervient pour lancer un nouveau projet
Dans les deux cas, il ne reste que quelques mois, voire 1 ou 2 ans, juste le temps nécessaire pour apporter de la valeur et partir au moment où le code contient trop de dette technique. Comme le remboursement de la dette technique n’a pour lui pas de sens, il ne s’encombre pas de toutes les valeurs du Software Craftsmanship qu’il juge comme de la surqualité ou juste de la prose sortie de livres purement théoriques.
Ses points forts pour le Software Craftsmanship :
✅ il livre très rapidement du code fonctionnel, avec des tests de non-régression.
✅ il peut être le vrai moteur d’une équipe, et faire bouger les choses quand l’équipe souffre d’une inertie trop importante
✅ généralement force de proposition pour échanger avec tous les départements de l’entreprise. Il prend d’ailleurs souvent le rôle de tech lead car il est apprécié du management (même si j’ai déjà vu des développeurs de ce type rester seul dans leur coin aussi).
Ses points de friction avec le Software Craftsmanship:
❌ un certain manque d’humilité, qui ne lui fait pas reconnaitre le fait qu’il ne sait pas qu’il ne sait pas plein de chose sur la qualité logicielle, car son monde s’arrête au moment où la majeure partie des principes du Software Craftsmanship démontrent toute leur efficacité
❌ ne s’embarrasse pas de refactorer le code, de créer des concepts ou des abstractions pour en simplifier la compréhension et l’évolution, si un bon gros copier-coller fait le taf, alors il n’aura aucun scrupule à le faire pour aller plus vite
❌ a une vision quelque peu fataliste sur la dette technique qui de toute façon est impossible à éviter. Certes, il a raison, le but n’est pas de l’éviter mais de l’empêcher au maximum pour la garder sous contrôle
❌ ne cherche pas à comprendre l’intérêt d’appliquer des principes qui lui semblent tout de suite “overengineered” car de toute façon il est souvent parti avant de voir les vrais problèmes arriver
🦸♂️ Le développeur Héro
Ce développeur est, comme le développeur Fidèle, depuis très longtemps dans la même entreprise. Il y est depuis tellement longtemps qu’il est devenu le référent technique pour un nombre incalculable de produits différents au sein de l’entreprise.
Si ce développeur quitte le navire, ce n’est pas bon pour l’entreprise…
A chacune de mes missions j’ai rencontré un développeur Héro, même s’il n’a jamais été directement dans mon équipe. C’est quelqu’un de passioné par le code, mais qui n’a que faire de la qualité. Il veut tout faire lui-même, à sa façon, et est souvent autodidacte.
Ses points forts pour le Software Craftsmanship :
✅ sensiblement les mêmes que le développeur Fidèle. Il devient une plaque tournante entre le produit, le business et la technique
Ses points de friction avec le Software Craftsmanship:
❌ aucun, ou très peu de partage de la connaissance métier sur son propre code
❌ il n’a que faire de la qualité logicielle, il préfère agir vite et précisément en aval, plutôt qu’empêcher les bugs en amont par une architecture logicielle un minimum réfléchie et une suite de tests automatisés
❌ un Bus Factor énome, s’il part, il met plusieurs équipes en grand danger
🙋 Le développeur Ouvert et Curieux
Ce développeur est souvent le meilleur allier de qui cherche à promouvoir le Software Craftsmanship. Il justifie souvent d’une certaine expérience dans le milieu professionelle qui lui a fait sentir les douleurs que viennent apaiser les bonnes pratiques du Software Craftsmanship. Il arbore les mêmes valeurs concernant la qualité logicielle, bien qu’il ne sache pas forcément nommer concrètement les différents concepts qu’il applique sans le savoir tous les jours.
Ses points forts pour le Software Craftsmanship :
✅ a souvent de très bonnes connaissances techniques acquises grâce à sa curiosité et son ouverture d’esprit
✅ est toujours prêt à échanger sur telle ou telle pratique, et à essayer de nouvelles choses si elles lui paraissent intéressantes
✅ est souvent force de proposition grâce à ses idées et sa curiosité
✅ ne rechigne pas à discuter avec le métier / produit pour faire un produit
correspondant un maximum aux attentes de l’utilisateur final
Ses points de friction avec le Software Craftsmanship :
❌ peut se laisser embarquer par d’autres types de développeurs et ainsi réduire sa propre vision de la qualité logicielle
❌ peut être plus lent à la livraison qu’un développeur Héro ou Mercenaire, car il teste de nouvelles façons de travailler comme le TDD ou le Test-First, et n’est pas encore entièrement à l’aise
❌ la qualité livrée est bien plus élevée, mais aux yeux du management il peut être vu comme moins efficace.
👨🏻🏫 Le développeur Crafteux et Passionné
Celui-là n’est pas dans toutes les équipes. C’est un développeur très paradoxal dans une équipe car il pourrait apporter une valeur énorme à celle-ci en arrivant à promouvoir le Software Craftsmanship, mais devient finalement un frein car proposant des changements trop brusques. Son objectif est alors d’embarquer avec lui d’autres développeurs (comme le développeur Ouvert et Curieux) pour avoir plus de poids par rapport au reste de l’équipe. Mais ce n’est pas sans danger, et ce peut même devenir contre-productif :
Ses points forts pour le Software Craftsmanship :
✅ sa passion pour le Software Craftsmanship, et l’envie d’en apporter les principes et les concepts à son équipe, de façon la plus pragmatique possible sans sacrifer la qualité (tous les points mentionnés plus haut sur la définition de la qualité logicielle)
✅ référent technique et théorique sur plein de points. Contrairement à l’ultra-perfectionniste, il a beaucoup plus d’expérience professionnel, et a donc pu voir de lui-même les problématiques que viennent résoudre les principes du Software Craftsmanship
✅ une envie de réellement partager son savoir, car il est convaincu que c’est la meilleure façon de produire un logiciel de qualité sur le moyen et le long terme (et même sur le court terme si toute l’équipe est à l’aise avec ces principes, ce qui n’arrive jamais…)
Ses points de friction avec le Software Craftsmanship :
❌ se heurte de plein fouet au fatalisme de certains développeurs résignés à accepter la dette technique comme une fatalité, comme si le fait de devoir refaire un produit tous les 2 ans était normal, et moralement acceptable
❌ peut avoir du mal à travailler selon d’autres méthodologies, qu’il sait moins efficaces, mais qui sont mieux appréhendées par l’équipe
❌ accepte difficilement de voir tant de potentiel dans une équipe, qui pourrait faire de la qualité 1000 mais qui se contente de faire de la qualité 10, car tout le monde (produit, business, tech) est habitué à ce niveau de qualité
❌ il devient alors un frein à l’équipe, la ralentie, ce qui est contre-productif.
❌ comme l’Ultra Perfectionniste, il finit souvent par partir, et par bosser seul, à défaut de trouver une équipe où chacun comprend, connaît, et veut suivre les mêmes principes de qualité logicielle.
Ces différents portraits sont évidemment exagérés. La réalité est bien plus nuancée et beaucoup développeurs sont à cheval sur plusieurs des catégories que j’ai mentionnées, voire même font partie de type que j’ai totalement oubliés ici.
Quoiqu’il soit, il ne sert jamais à rien d’imposer des choix à une équipe. Pour être capable de travailler efficacement, des compromis doivent être fait pour correspondre à la vision globale de l’équipe sur la qualité logicielle.
Toutefois, quand cette vision de la qualité est trop éloignée de la sienne, que ce soit à cause des développeurs ou (trop souvent) à cause de la politique au sein de l’entreprise, alors il devient dangereux de rester et s’entêter. Il est alors le temps de partir :)
Sur ce, je vous dis à la semaine prochaine !
Happy Coding :)