[new:30/08/2015]TDD j’en ai déjà parlé, depuis certains l’ont dit mort. Tout ça pour ça ?
Utopie, géniale avancée ou coup d’épée dans l’eau ?
Début 2008, une saison humide et froide, perdu dans mes pensées lors d'une pause amplement méritée je pensais à la méthode TDD et j'avais eu envie de vous livrer le fruit de mes réflexions.
Il y a quelques temps je repensais à tout ça et à un article de 2014 de David Heinemeier Hansson intitulé “TDD is dead. Long live testing” qui avait beaucoup agité le petit monde du TDD. Et je m’interrogeais à nouveau sur toutes ces méthodes dites agiles et leur véritable utilité (en dehors de faire couler de l’encre).
Le TDD
Le Test-Driven Development ou développement piloté par les tests, est une méthode dérivée du concept "tester en premier" de l'Extreme programming, lui même une forme dérivée de l'Agile Software Development datant de 1996, dans la même veine que Scrum ou RAD en 1991, ce qui ne nous rajeunit pas.
Tout cela pouvant remonter certainement au néolithique de proche en proche. Par exemple taper sur la tête de son voisin avec la massue toute neuve qu'on vient de fabriquer histoire de tester si elle sera assez solide pour aller à la chasse était certainement le grand début de l'Agile ou piquer un silex tout taillé à un copain est finalement le début de la réutilisation voire du RAD. Dieu lui-même en reprenant les plans de fabrication et une côte d'Adam pour faire Eve faisait de la réutilisation et du design pattern. Confondre grand ordonnateur et grand ordinateur est un exercice de style osé, j'en conviens.
Bref le TDD, comme toute méthodologie, n'est que le fruit d'une lente maturation au fil des ans. Et parmi toutes celles proposées ces 20 dernières années c'est celle qui apparaissait la plus sage, la mieux adaptée. Elle recentrait le développement sur l'essentiel : le besoin réel et donc l'utilisateur. Techniquement elle prônait une économie de mouvement évitant les errances : on ne code que ce qui est nécessaire pour que ça marche et surtout pas plus. On s'éloigne ainsi des grandes généralisation, fantasme d'informaticien, donnant lieu à des développements complexes et couteux qui, une fois terminés, sont déjà obsolètes. C’était merveilleux, une sorte de recette miracle ou bien un “snake oil” de charlatan passant de village en village pour vendre une potion qui soigne tout (et qui ne revient jamais deux fois dans le même village pour ne pas se faire lyncher…).
Un doute…
Lorsque je présentais ainsi TDD je m’interrogeais déjà :
Mais est-ce une nouvelle utopie et subira-t-elle le même sort que toutes les autres méthodes de développement (à savoir se limiter à quelques termes pompeux sur les propositions commerciales et à quelques discussions autour des machines à café) ?
UML est un bon exemple du triste sort réservé aux meilleures idées de nos têtes pensantes. Même si cette mode est passée (remplacée par d'autres) il fut un moment ou toute "propal" de SSII se devait de faire apparaitre ce terme comme toute lessive se doit au minimum d'avoir la mention "deux en un" (voire plus) sur son emballage pour se vendre.
Avant que d'excellentes méthodes comme TDD puissent s'imposer, elles sont finalement déjà mortes… Il serait donc nécessaire de changer les mentalités, celles des dirigeants de SSII et de leurs commerciaux qui se retranchent souvent derrière la loi du marché et de la concurrence pour offrir au client ce qu'il demande au lieu de lui conseiller ce dont il a besoin, et celle des clients qui ne peuvent continuer à se dédouaner de leur ignorance s'ils désirent obtenir des logiciels fiables, maintenables et adaptés à leurs besoins et ce au meilleur prix (mais pas en dessous, la qualité se paye).
Je pensais alors qu’un long voyage nous attendait et qu’avant qu'un tel bouleversement se produise de l’eau passerait sous les ponts.TDD, comme l'XP ou l'Agile development et bien d'autres dont nous avons tous oublié les noms, finirait peut-être aussi dans les nimbes brumeuses où s'évanouissent les idées trop en avance sur les mentalités... ou tout simplement inadaptées !
Et avec le recul ?
Le même auteur a écrit ensuite un article intitulé “test-induced design damage” dont le titre en dit long sur son jugement.
Petite querelle entre experts ? Ou éternel recommencement de ce jeu de montagnes russes que sont toutes ces modes en matière de développement ?
UML nous a amené la conscience qu’un petit dessin valait cent pages de charabia. Même mal appliqué, ce fut une avancée. Mais les méthodes Agiles ont-elles apporté quelque chose ?
Je n’en ai pas l’impression. Pour moi l’Agile a toujours sonné comme une sorte de papier cadeau pour emballer un truc qu’on veut cacher : développer sous pression c’est le bordel. Un point c’est tout. Agile c’est renoncer à mettre de l’ordre, à faire de l’analyse le cœur d’un développement. C’est tout simplement appeler “femme légère” (joli terme) une nana qui trompe honteusement son mari (nota: on peut le faire en version masculine pour les féministes aussi). C’est plus élégant, plus vendeur. Comme dire c’est un Don Juan d’un type qui trompe sa femme sans vergogne (je fais plaisir à tout le monde vous remarquerez l’effort). Ca reste un salaud sans morale même si l’appellation est romanesque. Faire de l’Agile c’est se tromper de méthode tout simplement, c’est croire qu’en donnant un joli nom au bordel il en sera plus acceptable.
Pour moi aujourd’hui l’Agile ce n’est plus que ça. Bavardage sans intérêt qui se limite à un cache-misère.
Y-a-t-il eu un “apport” de l’Agile ? non. En reste-t-il quelque chose ? non.
Et TDD ?
Personne ne l’a appliqué vraiment à part quelques types ici ou là, du genre de ceux à s’enrôler dans une secte.
Personnellement je n’y ai jamais vu qu’une approche, parmi d’autres, qui enrichit le débat en forçant la réflexion. Trop de développeurs ne se questionnent pas assez. Alors TDD a au moins laissé ça derrière lui, la nécessité de s’interroger sur la façon dont on doit s’y prendre pour faire un bon développement. Mais à part quelques déjantés de mon genre, est-ce que TDD a réellement forcé à la réflexion ? je n’y crois pas non plus.
Design first !
Après toutes ces années à réfléchir, à écrire des articles, à tenter moi-même avec des clients certaines expériences, j’en suis venu à la seule conclusion qui s’impose : un bon soft est un soft qui plait aux utilisateurs.
Plante-t-il quelques fois ? Si l’utilisateur l’aime ce n’est pas si grave. Mieux vaut ça qu’un truc qui croit atteindre une illusoire perfection technique (ça finit toujours par planter quelque part) et qui a totalement zappé l’utilisateur dans sa démarche.
Notre vrai souci en informatique c’est l’entre-soi. Nos petites méthodes entre amis, nos trolls entre connaissances, nos méthodes géniales que personnes n’applique mais dont on sait parler si doctement avec plein d’acronymes nouveaux pour faire passer les autres pour des crétins… Et l’utilisateur dans tout ça ? Qui défend son point de vue ?
C’est pour cela que je ne prône plus aucune méthode de développement en dehors des bonnes pratiques de l’instant selon l’environnement technique. La seule méthode qui marche c’est l’expérience. Le développement est bien plus un art qu’une science. Tous les arts reposent sur la science, mais ils ajoutent une couche de plus : la créativité et des valeurs humaines.
On ne peut pas créer de la musique sans avoir un certain gout ou talent pour les mathématiques et sa rigueur, même inconscient. On se repose sur cette rigueur. Mais une musique transporte des valeurs humaines, des sentiments, des sensations, ce qui est hors de la science. Idem en peinture. Les lois de l’optique, les reflets, traiter le mouvement, tout cela est de la science. Mais un tableau réussi ajoute une dimension humaine absente de la science.
L’informatique il faudra l’admettre, c’est pareil : il y a un solide background scientifique, mais si on se limite à cette froide approche on échoue. Car l’informatique est conçue pour des humains, pas des machines. Elle doit comme toute forme d’art s’appuyer sur des techniques, sur la science, mais elle doit absolument amener sa “couche humaine” : la compassion, la compréhension de l’autre et de ses besoins, le confort de l’autre, son plaisir même.
Et le seul moyen de rendre sa noblesse à l’informatique c’est de laisser tomber toutes ces approches qui ne sont que bricolage pour se recentrer sur les bénéficiaires de notre travail : l’utilisateur.
Dès lors seule une approche “design first”, c’est à dire la prise en compte de l’utilisateur, ses besoins, son profile, son confort, peut servir de guide à concevoir de “bons” logiciels.
Les utilisateurs ne liront jamais votre code, mais ils vivront avec ce que ce code fait voir… Se concentrer sur l’invisible en oubliant le visible est une erreur d’approche (visible = UI mais aussi UX donc fonctionnement). Agile, XP, TDD, RUP, appelez ça comme vous le voulez, c’est une erreur de placer ces méthodes comme seule et unique moyen d’aborder la conception d’un logiciel.
Conclusion
Remettre l’humain au centre de nos préoccupations, dans nos villes, notre politique, nos lois est devenu indispensable. La même chose apparait comme une évidence en informatique.
Il faut que l’informaticien sorte de sa coquille, et comme un artiste qu’il sache maitriser la technique de façon parfaite pour être capable de l’oublier et de se concentrer sur son art : réaliser un logiciel utile, plaisant, ergonomique destiné à créer du plaisir chez des humains. Certes pour les rendre plus productifs, mais l’un n’interdit pas l’autre, bien au contraire.
Un soft bien pensé pour l’utilisateur sera toujours meilleurs qu’un soft couvert à 100% en unit testing mais qui n’a fait l’objet d’aucune étude de Design. Je vous l’assure.
Pensez Humain, pensez design-first, et appliquez des techniques éprouvées que vous maitrisez pour la réalisation. C’est la seule voie qui mène à la réussite d’un projet informatique.
Stay Tuned !
(alors vous avez installé Windows 10 ?)