"Tu dois maîtriser le TDD, le DDD, la Clean Architecture si tu veux être efficace !" : et si on faisait fausse route ?

En ce moment, quelques débats font rage sur tout ce qui tourne autour du Software Craftsmanship, et notamment des pratiques comme le TDD, le DDD, la Clean Architecture, et j’en passe.

Le problème est qu’on en oublie que ce sont avant tout des outils, et non une fin en soi, pour atteindre un objectif : développer de meilleurs logiciels plus rapidement.

Le manifeste Software Craftsmanship

Pour rappel, voici les points énoncés par le manifeste Software Craftsmanship :

• Pas seulement des logiciels opérationnels, mais aussi des logiciels bien conçus.

• Pas seulement l'adaptation aux changements, mais aussi l'ajout constant de la valeur.

• Pas seulement les individus et leurs interactions, mais aussi une communauté de professionnels.

• Pas seulement la collaboration avec les clients, mais aussi des partenariats productifs.

Ce manifeste est né pour recentrer l’agilité autour de l’excellence technique, trop souvent négligée dans l’interprétation du manifeste agile.

Comment ne pas être d’accord avec le manifeste Software Craftsmanship ? C’est du bon sens pur et dur. Quel est le problème alors ?

Eh bien le problème est que pour en vanter les mérites, on a trop souvent tendances à mettre en avant les techniques comme le TDD, le DDD, la Clean Architecture comme étant des pré-requis, supposant que les équipes qui ne les pratiquent pas seraient en contradiction avec le manifeste, ne seraient pas efficaces, voire pas “professionnelles”.

L’objectif, rappelons-le, est avant tout de pouvoir développer de meilleurs logiciels plus rapidement.

Pour ce faire, n’oublions pas la mention “ingénieur” dans le métier “software engineer” (je ne parle pas du diplôme, on s’en tape de ça).

Le lien entre Software Craftsmanship et ingénierie logicielle

“Développer de meilleurs logiciels, plus rapidement”.

Rapidement, on sait ce que ça veut dire.

Mais qu’entend-on par “meilleurs logiciels” ?

Eh bien tout simplement des logiciels qui répondent réellement aux besoins utilisateurs, et qui ne souffrent pas de bugs empêchant de bosser sur des fonctionnalités.

À partir de ce constat, peu importe comment une équipe travaille, si elle est totalement satisfaite de ces 2 dimensions, alors il n’y a rien à dire, et il n’y a surtout rien à apporter, car l'équipe ne "souffre" pas (elle souffrira peut-être dans quelques années, mais "quelques années" ce n’est pas une temporalité qui existe pour la plupart des boîtes).

Maintenant, si l'équipe n'est pas satisfaite, elle peut s'améliorer, en visant l'excellence technique et la "vraie" agilité.

C'est ce que mentionne le manifeste Software Craftsmanship quand il évoque des logiciels “bien conçus”, “l’ajout constant de valeur” et des “partenariats productifs”.

C'est là que l'ingénierie logicielle joue un rôle prépondérant.

Le développement logiciel est un domaine exploratoire. C’est-à-dire que l’on apprend au fur et à mesure ce que l’on doit faire, ce qui marche, ce qui ne marche pas.

En ce sens, on doit absolument devenir des “experts en apprentissage”. Apprendre au plus vite.

Ce qui veut dire réduire le feedback entre le moment où l'on a une idée, jusqu'au moment où c'est entre les mains de l'utilisateur (le lead time).

Pour ce faire, il faut donc avancer itérativement, et incrémentalement. C'est tout l'objectif du Continous Delivery. Avoir un logiciel dans un état toujours releasable assure de pouvoir potentiellement déployer plusieurs fois par jour, pour raccourcir le feedback.

Sauf que pour être capable de faire ça, il faut aussi devenir expert en gestion de la complexité. Si tout est un bordel fini, impossible pour plusieurs développeurs de bosser en parallèle sans se marcher sur les pieds, ni même d'être serein que le logiciel fonctionne à chaque merge.

Ça implique alors de créer un logiciel modulaire, qui a un couplage cohérent, et c'est là qu'interviennent des techniques comme le TDD, le DDD, la Clean Architecture, etc.

C'est un moyen pour atteindre une fin, et c'est le meilleur moyen que l'on connait pour le moment (cf étude Accelerate), mais peut-être que plus tard, on trouvera quelque chose de plus efficace.

Pourquoi on devrait arrêter de se focaliser sur la technique pour promouvoir le Software Craftsmanship

En ce moment, je suis en plein “marketing” de mon offre de formation. Honnêtement, je déteste ça. Le marketing. Le fait de devoir trouver des formulations alléchantes, jouer sur des biais cognitifs, etc., c’est pas ma came.

Pour autant, le marketing a l’avantage de mettre en avant les bénéfices pour la cible, pas les détails ni les moyens concrets d’y parvenir.

Un bénéfice répond à une douleur du client, on lui fait la promesse que l’on a la solution pour soulager sa douleur et lui permettre de ne jamais la ressentir à nouveau.

Je pense que c’est exactement la même chose pour évangéliser les bonnes pratiques pour développer de meilleurs logiciels plus rapidement : mettre en avant les bénéfices pour répondre à des problématiques précises rencontrées par les équipes.

Il ne peut pas exister d’approche universelle, applicable quelque soit l’équipe. À moins de travailler seul de A à Z sur un projet, ça me semble totalement utopique. Dès lors que l’on est dans une équipe, il faut composer avec l’expérience de chacun, les égos, le contexte. Dire à quelqu’un que ce n’est pas un “vrai développeur” parce qu’il ne pratique pas le TDD ou que son code est pourri parce que son modèle est anémique n’est pas du tout dans l’esprit craftsmanship (et pourtant je me suis déjà abaissé à ce genre de remarque dans un passé pas si lointain).

Plutôt qu’être vu comme des gourous ou des évangélistes, des prêcheurs de bonnes paroles, peut-être que l’on gagnerait à être vus comme des médecins généralistes. Des médecins qui s’intéressent avant tout aux douleurs du patient, et qui, étant donné son profil, sont aptes à lui recommander telle ou telle pratique pour soulager ses maux.

Tout comme on sait depuis des dizaines d’années qu’il ne faut pas manger trop gras, trop sucré, trop salé, et faire du sport pour être en bonne santé et éviter d’aller chez le médecin, on sait la conduite à adopter pour développer de meilleurs logiciels plus rapidement. Reste à convaincre l’industrie dans sa globalité de faire les efforts conscients en amont, pour éviter d’avoir à guérir les maux ensuite.

Happy Coding :)

Pierre.