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?

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.

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 « .

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.

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» ;-)