Le goût des autres ... domaines d'ingénierie !

C'est le buzz du moment: le software craftsmanship est sous toutes les plumes des bloggers agiles qui se respectent, notamment là ou là. Et je ne vais pas me priver de relayer le buzz car d'une part je me respecte (ouf), et d'autre part le sujet semble être hautement polémique et donc j'aime ça.

Il est toujours amusant de voir les réactions vives et parfois étayées de semi-insultes que provoquent ces discussions. L'arrivée de l'agilité avait donné lieu à des diatribes enflammées dans la blogosphère. Je trouvais à l'époque qu'un profil particulier se mettait régulièrement en lumière dans ces échanges: l'ingénieur en bâtiment refoulé. Celui qui voulait utiliser la même méthode pour construire un immeuble que pour construire un logiciel. Je n'ai pas encore compris pourquoi. Un exemple ici dans le commentaire n°9. NB: il y avait aussi la catégorie ingénieur civil refoulé qui voulait construire des ponts comme des logiciels. Les plus audacieux d'entre eux n'hésitaient pas à clamer vouloir construire une centrale atomique de la même manière qu'un logiciel ! Si si, je vous jure, c'était dans un commentaire sur le numéro 1 (le seul numéro d'ailleurs) du Valtech Mag en Décembre 2006, dommage qu'il ne soit plus en ligne, ça devrait passer à la postérité ! Bref, l'ingénieur en bâtiment refoulé avait raté sa vocation et était arrivé dans l'ingénierie logiciel avec l'ambition ferme d'y mettre un peu d'ordre et de relayer ses développeurs au rang d'ouvrier, ses concepteurs au rang d'architectes, et ses leaders techniques au rang de chefs de chantier. Malheureusement l'agilité compromet ses plans et on ne l'entend plus tellement de nos jours. NB: évidemment il va être le premier à me laisser un commentaire.

Mais voilà, le software craftsmanship a réveillé une autre catégorie d'ingénieur : les industriels malheureux. Un exemple ici (Gregory, sans rancune). Porté par la vulgarisation des termes "industrialisation", "usine logiciel", et "lean software development" qu'on utilise à tours de bras de nos jours dans l'informatique, l'industriel veut croire qu'un logiciel est fabricable en grande partie mécaniquement, depuis les plans de son concepteur ou selon un processus immuable, et avec une intervention réduite à la portion congrue "d'opérateurs" (autrement dit peu qualifiés). Il semble oublier que le développement informatique n'a pour but que de produire une pièce unique qu'on fait évoluer au cours du temps, et pas des milliers, voire des millions de pièces identiques, et que donc les procédés, méthodes, outils, ou pratiques utilisés pour produire la pièce N, ne sont plus tout à fait applicables pour produire la pièce suivante. Le modèle de l'industriel est la fabrication d'automobiles, un monde idéal qui doit nous montrer l'exemple. On y trouve pourtant des faillites vertigineuses, des ratages monumentaux, et des loupés en tout genre (même pour les meilleurs), dont fait rarement état l'industriel malheureux lorsqu'on en vient à comparer l'automobile et le logiciel.

Personnellement j'ai hâte de voir arriver les prochaines vagues d'ingénieurs malheureux qui vont nous expliquer comment développer du logiciel en se calquant sur les autres domaines d'ingénierie. Ainsi on pourra peut-être entendre:

• l'ingénieur agricole qui va nous expliquer comment labourer et fertiliser des systèmes d'exploitation avant d'y planter des graines de code qui vont pousser lentement chez les hébergeurs pendant l'hiver et donner leurs fruits d'expérience utilisateur au printemps. L'amélioration d'un SI passera par des boutures systématiques des vieux systèmes pour donner naissance à de jeunes applications que l'on pourra éventuellement greffer entre elles afin d'obtenir des systèmes plus productifs et de meilleure qualité, le tout abondamment arrosé d'engrais générateur de code,
• l'ingénieur en biologie qui va nous expliquer comment procéder à des tests cliniques sur des bouts de code souche pour évaluer les effets d'une crème de refactoring avant de l'appliquer sur des applications vivantes en production,
• l'ingénieur chimiste qui va nous expliquer que comme rien ne se perd et tout se transforme, si vous voulez dissoudre votre ancien SI dans une solution acide de nouvelles technologies, les émanations de gaz de changement vont fortement incommoder vos utilisateurs. Attention, si ce gars là devient copain avec l'ingénieur agricole, les effets risquent d'être désastreux sur votre SI et contaminer progressivement votre infrastructure avec du code "générétiquement" modifié,
• etc.

Bref, sortons-nous de ces comparaisons fatigantes avec les autres domaines d'ingénierie et continuons de réfléchir à comment faire les choses dans notre propre domaine. Les sources d'inspiration sont certes bonnes à prendre mais ont leurs limites qu'il faut savoir accepter. Le mouvement du Software Craftsmanship est une étape importante dans notre réflexion qui a le mérite de replacer les connaissances techniques au coeur du processus de création d'un logiciel. Elément qu'on a tendance à oublier avec la généralisation des méthodes agiles.

Un dernier point qui me chiffonne dans ces discussions autour de notre profession: pourquoi nous généralisons   souvent à partir de l'observation de notre propre nombril ? J'avais traduit il y a bientôt 9 ans un article très intéressant de JoelOnSoftware qui distinguait les différents mondes du développement logiciel. Il est toujours tellement d'actualité ! Dans toutes nos discussions sur le software craftsmanship nous réduisons systématiquement nos constats à notre propre monde. C'est un peu comme comparer le job du plombier et du menuisier. Ils ont bien sûr des points communs, de là à appliquer les mêmes règles à l'un et à l'autre, le raccourci est hasardeux...