Yannick nous parle beaucoup de développement Agile (souvent très tôt le matin ou très tard le soir, et sans tricher je pense : je me sens donc obligé de répondre un dimanche :)  ). C'est très fashion, à tel point que ça contamine (heu, prophylaxise ?... À voir) même l'embarqué, ce joyeux monde d'électroniciens ratés, mais j'ai un très gros problème avec l'une de ses composantes qui s'applique à moi, ingénieur développeur/intégrateur : l'eXtreme Programming. Par exemple, on se souvient d'un tandem qui a essayé d'introduire la chose chez Thales il y a deux ans et demi, et qui a gagné le trophée de l'innovation pour ça (l'un des deux étant épitéen, et l'autre joueur d'échec, et tous deux bossant juste derrière moi, à Colombes). Mais surtout, j'ai souvenir d'avoir dû y passer moi-même, plus tard : et là, c'est moins drôle.

Mais commençons par un autre bout : oui, il faut des développeurs experts pour pondre les nombreux tests par fonction (heu, procédure : c'est surtout pour les langages pourris type C/Java qu'il est intéressant d'effectuer de tels tests -- mais c'est tellement répandu qu'on en oublie presque que le monde pourrait être parfait et en Caml  :)   ). Et c'est ici que vient s'insérer une anecdote d'un projet réalisé l'année dernière, dans mon ancienne boîte d'électroniciens (80% électronique / 20% informatique -- j'ironise à peine :)  ). Nous prenions pour réaliser les tests des gens en intercontrat, histoire de rentrer dans les coûts, parce que le client veut quelque chose qui marche avec une équipe, pas avec deux. Un jour, nous voyons un des deux développeurs de tests (sur la même machine, XP oblige) commencer à suer gravement : il était depuis deux jours sur un bug, qui arrivait de temps à autre sans prévenir. Et ce n'était pas que le programme à tester était mauvais, enfin, il ne savait pas trop : de temps en temps, segfault sans prévenir. Ciel ! Nous prenons un gdb, et effectivement, quand ça plante, ce n'est pas à moitié : la pile est totalement corrompue. Ça sent le scanf pourri.

Parce que lorsque l'on fait du test de ce genre, on utilise la libc à outrance, et on ne recode pas son parseur ("how many divisions ?"), alors on utilise des choses immondes comme scanf (il faudrait légiférer pour l'interdire définitivement). Bref, nous allons voir le code, et ma foi, il n'y a rien d'extraordinaire. C'est alors que vint l'idée : et si le tableau utilisé n'était pas forcément très ben alloué ? Et la réponse ne se fit pas attendre : "c'est quoi malloc ?". Ne riez pas : lorsque l'on est habitué à faire de l'informatique sur PIC et sans MMU, ça se comprend (enfin, presque, parce qu'un pointeur reste un pointeur, MMU ou pas, il vaut mieux s'assurer que ça ne pointe pas n'importe où). Et ils étaient deux à coder la même horreur côte à côte sur le même PC. Évidemment le bug du test absolument fatal fut rapidement corrigé. On pourra au passage se poser la question d'un bug encore plus mesquin (par exemple tableau alloué à un élément près) qui aurait pu avoir un effet de bord sur les résultats des autres tests (par exemple les déclarer faux alors qu'ils sont exacts, ou pire, les déclarer juste alors qu'ils sont incorrects).

Donc, il nous faut un ingénieur encore plus cher que le développeur, pour faire les tests. Déjà, trouver un développeur à peu près compétent par les temps qui courent, cela relève de l'exploit, et ce n'est pas gratuit ; mais en plus de ça, il faudra plus-que-doubler le coût final pour avoir quelque chose de potable. En ces temps de soldes permanentes que connaît le métier, j'ai comme un doute quant à la pertinence du business model (il va sans dire que le testeur ne doit jamais être la même personne que le développeur, c'est l'évidence même).

Ce que je n'aime pas avec la méthode agile, c'est qu'il s'agit d'une méthode. Ce qui dans le milieu veut dire : un dogme, avec ses gourous. Avant, c'était le cycle en V, que l'on louait beaucoup, malgré les 20% de projets réussis, et 80% de perte en ligne (lors d'une conférence, un commercial vantait son entreprise de génie logiciel qui arrivait au chiffre record de 35% de réussite dans ses projets -- et il était sérieux). Pourtant, le "bon sens" indique que ce système est digne d'un HEC pas bien dégrossi ne connaissant rien à l'informatique, et encore moins à la programmation. Calquer des modèles ne marche pas. Pourquoi ?

Parce que le métier de développeur relève de l'artisanat, et le concepteur d'un programme est un artisan. Il s'agit bien d'un art manuel. C'est pour cela qu'une armée de chinois ne prendra pas notre boulot (et une armée d'indiens non plus), sauf à ce que le travail ne relève plus de l'art, mais du "pissage de code", bête et méchant. De la robotisation, du travail automatique, taylorisé, déshumanisé. Le développement est une discipline artistique (avec des notions de beauté), il ne s'agit pas seulement d'être prompt et aisé dans ses mouvements. J'aime développer pour le vertige du kwrite blanc (contrairement aux chercheurs je ne développe jamais sur feuille : aucun moyen de compiler du papier n'a pour l'instant été trouvé) : il n'y a rien, l'immensité vierge, et il va falloir aller par touches successives mettre en place une cathédrale (à partir d'un bazar, c'est bien connu), échafauder un système complet et suffisant qui pourra effectuer des actions, qui aura des sorties voulues en fonction des ses entrées déterminées.

Tiens, du déterminisme ! Eh oui, à moins de développer le système du Deep Thought (qui est le nom de mon PC portable sur lequel j'écris, d'ailleurs), auquel cas un "return 42;" sera plus rapide, un programme informatique a des entrées attendues, et des sorties associées (en ce sens, on peut faire l'analogie avec une application mathématique : ne jamais oublier aussi que l'informatique est une branche les plus complexes des mathématiques, et dès lors que l'on sort de ce cadre, on fait de la peinture rupestre si l'on veut -- désolé pour les "développeurs" html --, mais certainement pas de la programmation !). Et nous pouvons donc tester directement en fonction de ces entrées et sorties depuis l'extérieur en mode "boîte noire" : c'est ce que l'on appelle une "moulinette de test", par exemple un script shell géant gérant toutes sortes d'appels (y compris devant générer des erreurs), et scannant la sortie pour nous répondre des OK ou des KO.

Il y a deux restrictions à cela : tout d'abord, le procédé peut paraître "grossier", en ce sens qu'il n'a pas la même profondeur de détail que le "test unitaire" (dont le nom est ambigu, d'ailleurs). On pourra répondre par la modularité nécessaire des grosses applications, par la nécessité de toujours mettre des hooks de debug sous macro (un "#if TEST", tout simplement), faisant des printf ou autres joyeusetés qui vont bien (attention cependant aux applications temps réel), et par le fait qu'empiler des briques préjugées correctes ne garantit pas non plus que le résultat final sera bon (pour répondre au présupposé agile). Ensuite, la limite de la moulinette se situe dans la programmation graphique.

Que l'on ne s'y trompe pas : l'XP a été créé pour et par des "génie logiciel" (attention aux acceptions de "génie" :)   ). Et l'on connaît les classeurs de centaines de page de test du style "cliquer ici, là, re-ici, etc, vous devez alors trouver blabla dans la zone de texte à droite". Sauf que c'est ici un faux problème : tout bon développement se fait en ligne de commande, et la partie graphique ne doit être qu'une interface qui... s'interface (c'est donc pour ça le nom ? :)   ). C'est exactement de cette manière que sont codés la plupart des applications sous KDE, ne serait-ce que parce que Qt est conçu dans cette optique précise.

L'habileté d'un programmeur ne se situe donc pas dans sa capacité à répondre à un schéma préétabli, dans lequel on le forcer d'entrer. Il est très politiquement incorrect en ces temps gouvernés par le seul aspect commercial ("combien de temps pour faire ceci ou cela", avec comme prérequis "le temps, c'est de l'argent") de déclarer cela, mais il ne faut pas oublier que le métier de développeur est celui de l'artisan. On peut tout à fait faire des choses et des bidules correspondant à des exigences précises mais que l'on qualifiera aisément d'usine à gaz tout de même (on en a quelques exemples dans le logiciel libre, et pour ne pas froisser Sophie on se contentera de citer Firefox). Un programme n'est pas une somme de fonctionnalités, c'est un tout, c'est une oeuvre (au sens juridique aussi, un bon indice !), une sculpture numérique, une composition (la musique, cette autre branche artisitque des mathématiques), ou une toile du XIXème (qui se fait par ajout successifs de couleur, par dégrossissement : il n'y a rien de mal à ne pas terminer immdiatement le codage d'une fonction quand cela s'avère nécessaire !) (je précise "XIXème" car je ne voudrais pas que l'on compare mon travail à du Picaso, Miro, ou autre horreur du genre commis le siècle suivant -- et qui se vendent aussi cher que cela aura pris peu de temps à faire, mais n'a pas son siège social à Redmond qui veut !).

Il fut un temps où la mode passa au tout-objet (en tant que méthode technique de développement, cette fois). Dijkstra avait alors déclaré : "Object-oriented programming is an exceptionally bad idea which could only have originated in California." Et pour nous convaincre qu'il n'aurait certainement pas trop aimé la tournure des choses actuelles : "Program testing can be used to show the presence of bugs, but never to show their absence!" Nous sommes toujours orientés dans cette optique, malheureusement.

Que l'on ne s'y trompe pas : le bon sens de la méthode Agile est à suivre (comme tout véritable bon sens), et l'on peut très bien arriver à des conclusions justes (du genre "on livre un programme qui marche, et dans les temps" -- qui est d'ailleurs aussi pris en hypothèse, méthode de raisonnement habituellement chère à la chimie, cette branche obscure de la cuisine) à partir d'hypothèses fausses ("la programmation n'est pas de l'artisanat et soumise à des méthodes fixes", ou autre), avec un raisonnement juste (table de vérité par ici). C'est incroyable, mais le "Release early, release often. And listen to your customers." ressemble très fortement à "Customer satisfaction by rapid, continuous delivery of useful software". Eh oui, le modèle du logiciel libre se fait pomper ! C'est peut-être parce que le logiciel libre marche extrêmement bien, non ? (dans une SSLL, ce serait un comble que de devoir convaincre son lectorat :)  ) Et que donc la méthode appliquée est certainement la meilleure qui soit ! C'est moins vendeur, c'est certain : du bazar  :). On pourrait peut-être renommer ça en "recuit simulé" ? (ah non, c'est déjà pris)

Allez, gardons le dernier mot pour feu notre Grand Gourou Dijkstra (dont il faudrait presque citer l'intégralité) :

The required techniques of effective reasoning are pretty formal, but as long as programming is done by people that don't master them, the software crisis will remain with us and will be considered an incurable disease. And you know what incurable diseases do: they invite the quacks and charlatans in, who in this case take the form of Software Engineering gurus.


update (30/10): après discussion avec Yannick, je suis totalement convaincu du bien fondé de la méthode (surtout qu'il existe à présent de vrais outils pour la mettre en place et coordonner, contrairement à ce que j'avais vécu il y a plusieurs années), même si je reste toujours sceptique vis-à-vis d'un gros développement en C, surtout embarqué/système. Mais je suis totalement ouvert à la méthode Agile en tant que gestion de projet, hors eXtreme Programming on l'aura compris  :). Ayant pu depuis tester le talent de son plus ardant défenseur à Linagora, je m'avouerais même fort intéressé : c'est bien connu, il n'y a que les imbéciles qui ne changent pas d'avis ! :)  ("cette pirouette rhétorique vous a été offerte par...")