Too Young to Die, Too Old for Programming?

"Too Old to Rock 'n' Roll: Too Young to Die!" est un disque publié en 1976 par le groupe anglais Jethro Tull. C'est à ce titre que je pense lorsque je me sens déconnecté de l'évolution actuelle du génie logiciel. J'ai l'impression qu'une partie de la communauté avance en ignorant ou rejetant le passé. Si l'Agile Manifesto déclare "bien que les éléments sur la droite soient importants, nous attribuons plus de valeurs aux éléments sur la droite ("while there is value in the items on the right, we value the items on the left more"), il me semble que seuls les gens ont tendance à nier les approches précédentes, ou alors à leur attribuer un label "agile", comme si c'était le seul moyen d'être accepté ou acceptable. Des interventions sur le Web qui déclarent l'inutilité de la modélisation ou qui doutent de l'utilité d'un AGL renforcent cette impression. Ruby on Rails est un excellent concept, mais je considère comme un pas en arrière le fait que le seul outil initial ait été un éditeur de texte.

La problématique du développement du logiciel n'a pas changé et les solutions proposées partagent de nombreuses ressemblances. Je vais prendre comme exemple le modèle de maturité du logiciel (Capability Maturity Model ou CMM) et ses objectifs expliqués dans le document initial de 1987. Les objectifs des niveaux de maturité étaient les suivants : gérer les coûts, le calendrier et les modifications des spécifications, évaluer la conception et le code, favoriser la quantification du processus et l'amélioration. Je ne suis pas un expert en approches agiles, mais il me semble que ces objectifs partagent les mêmes préoccupations que les activités comme la gestion de projet avec Scrum, la programmation en binôme, l'importance des tests unitaires ou les rétrospectives. On peut discuter de la valeur respective de la programmation en binôme par rapport aux inspections de code, mais ces deux pratiques ont leur place dans la boîte à outils du développeur.

Si vous pensez que le CMM a été créé uniquement pour un cycle de vie en cascade qui produit une lourde documentation, le document de 1991 qui décrit les pratiques importantes stipule que le CMM n'implique aucun cycle de vie, structure d'organisation ou ensemble de document particulier. L'importance des métriques est le seul aspect du CMM qui n'est pas autant visible dans les pratiques agiles. Il existe de nombreux exemples de mauvaise adoption d'une approche de développement. Si l'on ne comprend pas ses principes de base d'une approche et si on l'adopte sans l'adapter au contexte, on rencontre naturellement des problèmes. Lorsque les pratiques agiles vont se généraliser, elles vont rencontrer les mêmes obstacles que les approches antérieures et vont générer leurs propres "récits d'horreur". Ceci ne doit pas masquer les apports positifs des approches agiles... ni les éléments bénéfiques apportés par Merise, le CMM, RUP ou le RAD.