Software Craftsmanship, ou le marketing de l’échec
10 février 2011
Suite à un intéressant article de Nicolas Martignole, ça buzze beaucoup ces temps-ci autour du Software craftsmanship et ça me donne envie de réagir. En particulier quand je vois les tentatives de récupération (je n’ai pas mis de lien pour ne pas les encourager ;-).
Le mouvement du Software Craftsmanship constate que les bons logiciels sont faits par de bons programmeurs. Notre profession aura atteint la maturité lorsque les bons logiciels pourront être faits par de mauvais programmeurs ou même, sans programmeur du tout.
Le Software Craftsmanship : commercialement anxiogène
Comment terroriser nos clients : en leur expliquant que la seule manière de leur apporter de la valeur c’est de réunir des développeurs expérimentés, membres de la communauté des Software Craftsmen (sorte de compagnonnage). Pour que le projet fonctionne il leur faut l’élite : tous ont fait leur Tour de France et réalisé leur Chef d’Oeuvre. Sinon, c’est l’échec assuré.
En toute logique, le client part en courant acheter un ERP (au fait, qui met en place les ERP ? En tout état de cause pas des Software Craftsmen. Pourtant ça fonctionne plutôt pas mal, et ça crée de la valeur chez leurs utilisateurs).
Je pense qu’un client sera bien plus rassuré si on lui explique que le projet ne repose pas exclusivement sur des individualités, mais sur une entreprise qui, par les processus mis en place, par sa capacité à recruter, mais aussi, à former et à encadrer, par ses outils et ses infrastructures, lui garantit une qualité de service éprouvable et surtout, répétable.
C’est justement la différence entre une boîte qui « vend des CV » (donc des individus) même bons, et une boîte qui vend un savoir faire d’entreprise.
Si ma boîte n’apporte rien de plus à mon client que la somme des qualités individuelles de ses salariés, je passe freelance immédiatement.
Le Software craftsman et le Renard (Jean de la Fontaine)
L’idée d’une « Communauté de professionnels » est intéressante par son aspect « partage de bonnes pratiques » : c’est exactement ce que je recherche en participant à des conférences ou à des séminaires professionnels. Elle l’est beaucoup moins par son aspect ségrégationniste : il y aurait donc deux sortes de gens. Ceux qui en sont, et les autres.
Evidemment tout ce discours s’adresse aux premiers. Ceux qui adhèrent aux valeurs et qui ont signé le Manifeste. Ceux qui sont de « bons » artisans qui, jours après jour cisellent leur code pour en faire un chef d’oeuvre.
Les bons programmeurs seraient donc les gardiens des bonnes pratiques qui se transmettraient leur savoir faire « de bouche de druide à oreille de druide ».
Sauf qu’en fait, il n’y a pas de ségrégation : tout le monde se reconnait dans le manifeste. Tout le monde veut (ou croit) être un partenaire productif de son client, membre d’une communauté de professionnels qui apportent de la valeur en créant du bon logiciel (sic).
C’est en fait une grosse ficelle. Il s’agit simplement de développer l’esprit de corps.
Pour une SSII, faire l’apologie du Software Craftsmanship, c’est du clientélisme. C’est flatter la communauté dans le sens du poil en espérant ramasser des CV.
Et Uncle Bob, dans ses conférences comme dans ses posts est sur la même longueur d’onde. Il espère mettre dans sa poche son auditoire en lui jouant du violon : « comme vous ête forts, vous les programmeurs quand vous vous efforcez de faire de la belle oouvrage ». Ca marche plutôt bien, il parait qu’il ya même des SSII qui l’écoutent… Cette leçon vaut bien un fromage sans doute.
Software Craftsmanship : un constat d’échec
Quelqu’un se souvient-il de ce que signifie le premier « I » de SSII ? « Ingénierie » ! Nous sommes censés être des ingénieurs. Pas des artisans.Et notre métier est considéré comme « industriel ».
Et bien en fait non. Nous sommes encore (malgré un demi siècle d’existence) un métier où le savoir faire individuel reste plus important que le processus et l’outillage.
L’existence même d’un mouvement comme le Software Craftsmanship est un aveu d’échec pour notre profession. Ca me désole mais, je dois bien l’admettre, on ne sait pas, aujourd’hui, fabriquer du logiciel comme on fabrique des voitures. D’ailleurs, si c’était le cas, il n’existerait pas de « petites SSII ». A-t-on déjà vu un « petit constructeur automobile » ? Oui, il y a un siècle, quand le métier balbutiait.
Le Software Craftsmanship est donc un pis aller pour pallier notre incapacité à industrialiser la production de logiciel. Et bien mon objectif personnel n’est pas de me complaire là dedans mais plutôt de tenter de faire changer les choses !
A contrario d’une réaction au post de Nicolas, j’ai l’impression que les initiatives de type Centres de Service vont plutôt dans le bon sens de ce point de vue. L’industrialisation d’un processus de production, la mutualisation des moyens ne sont pas antinomiques du développement du savoir faire individuel des programmeurs, au contraire. En créant un environnement communautaire et en lui donnant plus de confort, il favorise le partage des connaissances au quotidien, il permet la répétabilité et l’amélioration des processus, il autorise l’investissement dans l’outillage. Le seul inconvénient est le possible éloignement du client ou de l’utilisateur final qui peut être compensé par une organisation distribuée (par exemple des products owners délégués qui font la colle). Et évidemment, le MDA est un autre avatar de la même ambition industrielle.
Je voudrais tout de même terminer sur une note un peu plus positive par rapport au Software Craftsmanship. Ne vous méprenez pas, je reconnais bien volontiers (mieux, j’apprécie et surtout je revendique), le caractère créatif de notre métier. Je suis sensible à l’esthétique, voire à l’élégance d’un programme (ou à sa laideur). Et, pratiquant le coaching, je suis souvent amené à tenter de partager mon expérience avec de jeunes Padawan. Je suis juste un peu déçu, de voir que c’est ce genre de sujet plutôt passéiste, qui tient le haut du pavé dans notre profession. J’aimerais bien pouvoir m’enthousiasmer pour des idées vraiment nouvelles, des « changements de paradigmes » ou des « révolutions technologiques » plutôt que pour ce qui me semble fortement teinté d’un conservatisme confortable.
PS Les commentaires sont réactivés
février 10th, 2011 at 23:52
[...] Ce billet était mentionné sur Twitter par Bonnel Yan et Nicolas Martignole, maximebonnet. maximebonnet a dit: Une autre vision du software #craftmanship : http://mdblog.fr/blog/2011/02/10/software-craftsmanship-ou-le-marketing-de-l-echec/ [...]
février 11th, 2011 at 11:22
Bonjour,
Je ne pense pas que le craftmanship soit utilisé comme argument commercial. En tout cas, il ne devrait effectivement pas l’être.
La comparaison avec un artisan créatif me semble pertinente. Et la démarche de Fowler et consort a son intérêt : admettre que nous comme des artisans et en tirer les conséquences.
Je ne pense pas qu’il s’agisse d’un constat d’échec.
La vérité c’est que le métier de développeur est effectivement une profession unique, qui réclame des connaissances d’ingénieur, un esprit créatif et une démarche d’artisan.
Contrairement aux voitures, chaque logiciel est unique, et doit être forgé par des artisans qualifiés. D’ailleurs le prototype d’une voiture est fabriqué d’une manière qu’on peut considérer comme artisanale, avant la production en série. Dans « l’industrie » du logiciel, il n’y a pas de production en série, que des prototypes, et donc pas d’industrie.
février 12th, 2011 at 8:39
Bonjour,
tout d’abord merci pour cet article qui m’a fait découvrir le « mouvement » des « Software craftsman ».
Je suis plutôt d’accord avec Raphael.
Le débat qui est soulevé est, pour moi, celui du système et de l’humain.
Si j’ai bien compris le propos, les craftsmen défendent les qualités individualistes en laissant croire à chacun des membres de la communauté qu’il est unique, qu’il est le meilleur, bref qu’il est indispensable.
La démarche d’industrialisation consiste à créer une organisation et des processus banalisés où l’on va uniformiser la manière de travailler. On ne veut pas être dépendant de l’humain, on gomme les différences, on rationalise le travail ….
L’exemple repris souvent est celui de l’industrie automobile vs l’industrie du logicielle :
Une chaine de production chez Rena… ressemble à s’y méprendre à une chaine de production chez Peuge….. Où est la différence ?
Les individus sont interchangeables et ils n’ont de spécialisés que le nom.
Je ne suis pas certain que les ingénieurs en informatique souhaitent être assimilés à des O.S.. ;-).
Au delà du partage communautaire et de flatter l’égo du « Geek » qui sommeille en nous, c’est peut-être parce qu’il se recentre sur l’individu que ce mouvement est apprécié de la communauté.
Cdlt.
février 13th, 2011 at 0:03
Bonjour,
Permettez moi de me présenter, je ne suis pas un Geek 2.0, ça fait dix ans que je suis dans la même boite. Je ne développe plus, pire je suis commercial depuis deux ans. Oh mon Dieu, Père Damien Karras Nicolas, Père Merrin Didier, vite aidez-moi, je suis possédé par le démon Mouton 2.0. Exemple, en 2009, je faisais partie des 2,52% de développeurs à utiliser encore la 3.1 d’Eclipse. Un retard de 4 générations, un vrai Mouton 2.0 !
Mouton 2.0, mais je me soigne ! Ma thérapie :
NS – Abonnements Twitter bien tunnés, sur mon PC le matin et le soir, et sur Blackberry plusieurs fois par jours – A renouveler.
NR – Des heures et des heures sur des blogs sérieux : Standblog, L’informatique Conviviale, Le Touilleur Express, …
NS : Non Substituable ; NR : Non Remboursable
Et puis un jour, je suis tombé sur un article super intéressent Software Craftsmanship par Nicolas Martignole.
Quelques jours après, en prenant mon médicament discrètement pendant une réunion Go/NoGo où certains parlent de choses qu’ils ne connaissent pas. Hé oui syndrome bien connu chez certains commerciaux : IABMC (Intelligence Artificielle à Base de Mots Clés). Je tombe sur le twitt de @nmartignole lien vers le billet de Grégory Weinbach ‘Software Craftsmanship, ou le marketing de l’échec’.
Heuuuu, serait-on pas entrain de réveiller le vieux démon de l’éternel débat Standardisation vs Customisation ?
Entre agilité, mouvement du Software Craftsmanship, Ingénierie, industrialisation. Je me dis que le point commun est peut être ‘comment mieux faire son métier ?’
Je doute l’existence d’une réponse définitive à cette question structurante et le métier de l’informatique, c’est d’abord un métier intellectuel, alors comment nous motiver pour mieux le faire ?
Daniel Pink nous propose 3 facteurs principaux de motivations pour mieux faire un métier intellectuel : Autonomie, Maitrise et Sens.
Qu’en pensez-vous ?
Un grand MERCI à Nicolas, Didier, Grégory, Guillaume, Pierre , Tug et tous ceux qui œuvrent à animer des blogs de qualité et à vous de m’avoir lu.
Je retourne à ma cotation :-(
Un Mouton 2.0 qui rêve de «Travailler en sifflant» ;-)
février 14th, 2011 at 1:31
Bonsoir,
J’ai l’impression que ce billet passe un peu à côté de ce que signifie l’artisanat du logiciel (qui reste, à ma connaissance, la traduction la plus largement acceptée de « software craftsmanship »).
L’analogie avec l’industrie automobile ne tient pas vraiment la route. En passant, précisons qu’il existe, encore aujourd’hui en 2011, des petits constructeurs automobiles : Venturi, Secma, Lumeneo pour ne citer que des français.
Mais ce qui flingue l’analogie, c’est qu’un constructeur auto vend un *produit* et non pas du service. Dans le monde du logiciel, ça existe aussi. En général, on appelle ça des « éditeurs » et leurs méthodes de fabrication de produits logiciels n’ont pas grand chose à envier à celle du secteur automobile ou autre. D’ailleurs, si on veut une analogie plus parlante, on pourrait poser la question : existe-t-il aujourd’hui des « petits éditeurs de systèmes d’exploitation » ? Certainement, mais il y en avait beaucoup plus il y a 30 ans quand le métier balbutiait !
L’erreur à ne pas commettre quand on veut parler des changements de paradigme dans la réalisation de logiciels, c’est de tout ramener à la notion de SSII comme si ce qu’est devenu aujourd’hui le concept de service dans la réalisation de logiciels était inéluctable.
En tant que client potentiel, je mesure la qualité d’une SSII à la qualité des développeurs que celle-ci est capable de fournir. Et ça s’arrête là.
Le reste, c’est la création d’un produit logiciel. Dans le processus de création, la définition du produit – ce que l’on pourrait appeler aujourd’hui le « product ownership » pour rester dans le vocabulaire Scrum qui tend à s’imposer – est indissociable des aspects techniques. C’est ce qui était déjà mis en avant dans le manifeste agile (customer collaboration over contract negotiation) et qui va encore plus loin dans le manifeste pour l’artisanat du logiciel (not only customer collaboration but also productive partnerships).
La création d’un produit logiciel, c’est un partenariat entre plusieurs personnes. Idéalement, ces personnes font partie de la même société et, si ce n’est pas le cas car on ne peut pas toujours embaucher tous les talents dont on a besoin, elles font au moins partie de la même équipe.
Dans une telle équipe, la notion d’artisan prend tout son sens : c’est quelqu’un qui apporte son savoir faire personnel pour le bénéfice de l’équipe et du produit. Cela ne veut pas dire qu’il ne met pas en oeuvre des méthodes industrielles quand celles-ci sont justifiées (qui ose se passer d’un compilateur de code source ou d’un gestionnaire de configuration ?) mais la touche humaine qui fait qu’une machine ne sait pas *créer* un produit logiciel est incontournable.
De même qu’une machine ne sait pas créer une automobile : elle sait tout au plus l’assembler à partir de directives définies par des humains comme un système d’intégration continue sait générer un logiciel à partir de directives définies par d’autres humains.
Quant au « client qui part en courant acheter un ERP », honnêtement, je ne sais pas ce qui est le mieux pour lui.
Acheter un produit logiciel qui n’a pas été conçu en pensant spécifiquement à lui et essayer de le configurer aux forceps ?
Ou faire confiance à une société qui lui promet de réaliser sur mesure le produit dont il a vraiment besoin et ne pas vraiment s’impliquer dans la définition de ce produit puisqu’il paie quelqu’un pour ça ?…
En tant qu’artisan du logiciel, je lui conseillerais plutôt de faire le choix entre
- acheter un produit conçu par quelqu’un d’autre et adapter sa façon de travailler selon les choix faits par ceux qui ont conçu le produit en question
- se prendre en main pour définir soi-même le produit qui convient réellement et recruter, ne serait-ce que sur une durée déterminée, les personnes compétentes qui vont l’aider à concrétiser le projet.
février 14th, 2011 at 12:39
Je fais partie de la catégorie des « Padawans », de ceux qui n’ont pas atteint le quart de siècles et qui font tout pour qu’on leur enlève cette casquette de « Junior ». Et pourtant … cela fait bientôt 10 ans que je lis, et que j’écris du code…
J’ai débarqué dans le monde de l’entreprise il y a 3 ans, et là j’ai découvert l’envers du décors. Pire aujourd’hui je suis choqué quand je lis cette phrase :
« Le Software Craftsmanship est donc un pis aller pour pallier notre incapacité à industrialiser la production de logiciel. Et bien mon objectif personnel n’est pas de me complaire là dedans mais plutôt de tenter de faire changer les choses ! »
C’est à cause de ce genre de pensées que j’ai arrêté de coder pour les entreprises. Parce que « bien coder » est synonyme de « perte de temps » et qu’être « artisan » ce n’est pas être intelligent … en voilà des manières ….
Industrialiser c’est quoi ? Permettre de reproduire un quelque chose, à l’identique. Bon, reproduire un logiciel euh bah messieurs, le copier/coller existe déjà ! Allez y.
Je reste persuadé qu’un codeur qui code bien, est une énorme plus value pour l’entreprise … pour plein de choses !!
Pas seulement pour pisser du bon code, mais aussi et surtout parce qu’il va prendre du plaisir à faire ce travail, à le faire bien, et si des commerciaux veulent vendre leurs ingénieurs avec cette marque de fabrique et bien tant mieux !
Arrêtez de vouloir faire de nous des machines, on aime coder, et oui, on aime faire du bon code, pour nous, pour vous, et heureusement pour vous ! on est capable de s’adapter à toutes les demandes les plus farfelues de vos clients, justement parce qu’avec nos mains d’artisans, et notre cerveau d »ingénieur, on fait fonctionner ces logiciels qui n’ont rien de quelque chose d’industriel, et encore moins » d’industrialisable « .
février 17th, 2011 at 15:08
Personnellement je préférerais comparer notre métier avec l’industrie du textile/vêtement plus qu’avec l’automobile.
On pourrait comparer le prêt à porter avec les progiciels, le sur mesure et la haute couture avec les gros projets/grands comptes.
L’analogie me semble plus naturelle
février 18th, 2011 at 14:15
hihi, et SAP c’est Zara, Websphere H&M…
Moi je suis plus d’accord avec Oaz.
Je vois pas trop en quoi la non industrialisation de l’informatique pose en problème…
Pour moi, un métier tombe dans le domaine de l’artisanat dans la mesure ou pour obtenir un résultat voulu, il y a plusieurs moyens de faire, chacun ses méthodes et outils, et il n’est pas forcément évident de trouver le bon du premier coup.
Alors au final, les mecs qui conçoivent les nouveaux avions, les nouvelles voitures et autre, sont bien des artisans.
Ceux qui surveillent et contribuent à la production de masse, auditent, contrôlent les normes… ceux qui suivent à la lettre une méthodologie donnée sans la remettre en question et ni y apporter leur contribution cérébrale, ne sont surement pas des artisans.
Personnellement je suis fier d’être un artisan, et je ne me vois pas faire autre chose. Après, suis-je un bon artisan? Il faudra que je demande a Uncle Bob.
février 19th, 2011 at 18:18
Premier point, désolé mais le passage sur les ERP décridibilise vraiment l’article.
Par ailleurs la posture qui consiste à opposer la software craftmanship à une démarche d’industrialisation de production logicielle est juste un non-sens.
Les deux participent à la production d’un service de qualité, pour lequel le client peut au final être content de payer.
L’erreur pour les SSII est de croire que sa seule la force est celle de ses processus ou égale à la somme des forces de ses developpeurs.
Et puis il y a une dimension à prendre en compte c est celle de la pénétration des softs open source dans le processus de production ou d’exploitation.
février 26th, 2011 at 19:21
Salut Grégory, pourquoi penses-tu que « notre profession aura atteint la maturité lorsque les bons logiciels pourront être faits par de mauvais programmeurs ou même, sans programmeur du tout »?
En quoi est-ce une définition raisonnable de la « maturité »? (A supposer d’ailleurs que la maturité soit un objectif en soi, par opposition à une tactique verbale selon laquelle évidemment personne ne pourrait déclarer vouloir appartenir à une profession « immature ». On nous a déjà fait le coup: Knuth avait choisi le nom « literate programming » parce que personne ne se serait déclaré en faveur d’une programmation illettrée.)
Comparaison n’est pas raison, mais on ne vise pas dans l’immédiat une médecine qui se passerait de médecins, une éducation qui se passerait d’enseignants, une alimentation qui se passerait de cuisiniers…
Cette vieille idée selon laquelle « le programmeur est l’ennemi », c’est précisément celle-là qui est un marketing de l’échec, mais dans le sens inverse: en direction des programmeurs. Nous n’avons jamais su manager des programmeurs, alors faisons ce qu’il faut pour essayer de s’en passer. Il ne faudra pas s’étonner que les idées qui combattront sous cette bannière soient rejetées par les programmeurs, et on s’étonnera ensuite de ne pas voir la profession progresser!
Il faudra un jour que je te fasse mon topo sur l’historique tourmenté du Software Engineering (ma session s’intitule « Quarante ans de crise, dix ans d’agilité » et je suis assez rôdé là-dessus pour la faire chez OD quand ça vous branche).
Nous ne sommes pas *nécessairement* des ingénieurs, cette idée du génie logiciel est une construction sociale, avec une origine historique bien précise. Et force est de constater que malgré des objectifs grandioses la vision des pères fondateurs du génie logiciel est loin d’avoir été réalisée; alors pourquoi refuser que d’autres modèles fassent à leur tour une proposition?
juin 21st, 2012 at 10:05
Greg tu soulèves des points très pertinents. Je salue ton courage. Les commentaires sont plutôt décevants de naîveté. Mais tu aurais du continuer à argumenter.
Seul un autre point est mis en évidence par Stéphane : « Au delà du partage communautaire et de flatter l’égo du « Geek » qui sommeille en nous, c’est peut-être parce qu’il se recentre sur l’individu que ce mouvement est apprécié de la communauté. »
Et là il faudrait se demander pourquoi. Pourquoi le fait que ca se recentre sur l’individu est-il une bonne chose, pourquoi est-ce mieux au fond ? Est-ce que ce n’est pas plutot une dérive subie d’un modèle de société néolibéral ? Cette question est vraiment au centre, mais je pense que la communauté informatique, et en particulier celle des ‘Software Craftmanships’ (qui n’osent mm pas appeler cela en français, et c’est bien un signe), le plus souvent en statut d’indépendants, est bien loin de pouvoir entendre ce que cela recèle.
Chacun ne voit que son nombril, à croire qu’on ne doive plus coder avec ses mains aujourd’hui.
Mais j’ai trouvé une bonne faille dans ce système de pensée nécrosée, dont je me suis servi comme introduction de ma session « Démocratie Agile » à la dernière Scrum Night chez Google. Ca a tenu ses promesses. Je t’en parlerai à l’occasion. Ou peut etre que j’en ferai un billet.