Je ne sais pas si vous avez suivi le monde des blogs anglophones ces derniers jours, mais un débat fait rage autour du mouvement software craftmanship. Une polémique était latente depuis le lancement de ce mouvement en 2009 sur le bien fondé et la signification de ce manifeste. C'était perceptible dans les discours de certains participants à la QCon 2010 par exemple. L'étincelle est venue de Dan North avec son article Programming is not a craft.

Ont suivi de multiples réactions sur différents blogs et sur twitter. Je trouve l'analyse de Martin Fowler très fine. Il explique la naissance de ce mouvement par la faible adoption de XP qui était attaché à la méthode et la technique d'une part, et la montée de Scrum et du Lean qui ne disent rien sur les pratiques d'ingénierie. Les programmeurs passionnés auraient vu cette évolution comme une menace de non reconnaissance de la valeur de leur travail, et ont affirmé l'importance de la maîtrise de leur discipline.

Il redoute que ce type de mouvement ne participe à l'augmentation de la "crevasse" qui a toujours existé entre les programmeurs et le métier des clients.

J'ai participé à la QCon 2010 et il y avait tout un track consacré au sujet du "software craftmanship". Nous sommes allé voir Correy Haines, qui expliquait comment être un compagnon du développement. Il expliquait comment bien faire son travail mais pas pourquoi nous le faisons. Le malaise que j'ai ressenti était la focalisation sur le moyen plus que sur la fin dans cette approche. Cela fait écho à ce que disait Martin Fowler dans sa présentation "what are we programming for ?" en introduction au track "IT - more than tools and technology", à savoir qu'il était toujours troublé lorsqu'à la question "que fais tu?" un programmeur réponde "du JEE, sous tomcat en TDD, etc" et non "un logiciel qui remplit telle fonction".

En revanche, ce que j'ai trouvé rafraîchissant dans ce mouvement c'est le côté pragmatique, l'amélioration permanente par la pratique et par l'échange avec les autres comme les compagnons bâtisseurs, et cette posture d'apprenti impliquant une certaine modestie dans le comment je fais mon travail. Cette valorisation du métier peut aussi apprendre à des programmeurs à aimer ce qu'ils font, voire à susciter des vocations. Dans ce sens je trouve software craftmaship utile. C'est par exemple une bonne réponse à quelqu'un qui demande, "mais comment je peux être un bon développeur ?"

Ce débat nous renvoie plus globalement à la question de pourquoi nous faisons du code : est-ce pour s'amuser à résoudre un problème technique ? Est-ce pour toucher un salaire en fin de mois ? Est-ce pour apporter de la valeur au client, et plus largement à la société ?

Dans le fond, software craftmanship est peut-être juste une posture de certains qui veulent dire qu'ils aiment leur métier, là où d'autres pratiquent leur "art" et s'attèlent à leur tâche comme le dit Dan North dans son 2e post sur le sujet :

They just love coding, solve difficult technical or domain problems in innovative and highly skilful ways in a fraction of the time of us regular mortals, to deliver real benefits. They learn a new tool or technology by using it in real work situations and figuring it out as they go. They think all this navel-gazing, posturing and chatter is a bit silly.

Comme Monsieur Jourdain, on fait bien de la prose sans le savoir !


Quelques-un des posts principaux :</p>