Les douze principes

L'excellence technique et la simplicité

Deux principes voisins portent sur la qualité du travail lui-même. Le neuvième affirme qu'une attention continue à l'excellence technique et à une bonne conception renforce l'agilité. Le dixième tient la simplicité pour essentielle et la définit comme l'art de ne pas faire le travail inutile. Tous deux répondent à un malentendu fréquent, qui confond aller vite et bâcler.

Dix-huit mois plus tard

Une jeune entreprise vend un logiciel de prise de rendez-vous à des salons de coiffure. Les premiers mois, l'équipe livre une nouveauté par semaine. Pour gagner chaque nouveau client, elle ajoute son cas particulier en recopiant un morceau de code existant et en le modifiant un peu. Les vérifications automatiques sont remises à plus tard. Dix-huit mois passent, puis la dirigeante vient poser une question à Samuel, le développeur le plus ancien.

« Combien de temps pour proposer le paiement en trois fois ? »

« Trois semaines, répond Samuel. Le calcul du prix est recopié à onze endroits, avec de petites différences. Je dois les retrouver tous, et rien ne me préviendra si j'en casse un. »

« Il y a un an, vous m'auriez répondu deux jours. »

« Il y a un an, le calcul n'existait qu'à un seul endroit. »

Personne n'a décidé de ralentir. Chaque raccourci paraissait raisonnable le jour où il a été pris. Leur accumulation a rendu le logiciel rigide, et l'entreprise a perdu son agilité, c'est-à-dire sa capacité à changer de direction rapidement.

Ce que disent les deux principes

Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité.

Manifeste agile, principe 9

La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.

Manifeste agile, principe 10

Dans le neuvième principe, les mots « attention continue » écartent deux pratiques : la grande phase de conception placée au début du projet et le grand nettoyage repoussé à la fin. La conception, c'est-à-dire la manière dont le logiciel est découpé en parties et dont ces parties dépendent les unes des autres, se soigne tous les jours. Le verbe « renforce » donne la raison. La qualité technique y est présentée comme un moyen : elle conditionne la capacité à accueillir un changement tardif (principe 2) et à livrer souvent (principe 3).

Le dixième principe contient sa propre définition. Le texte anglais dit « the art of maximizing the amount of work not done », littéralement l'art de maximiser la quantité de travail que l'on ne fait pas. La traduction française officielle a préféré « minimiser la quantité de travail inutile », plus claire, mais qui perd une nuance. L'anglais invite à chercher activement ce dont on peut se passer, y compris parmi les travaux qui paraissent utiles. Le mot « art » signale qu'il s'agit d'un jugement et qu'aucune règle mécanique ne le remplace.

La dette technique, une métaphore de Ward Cunningham

En 1992, Ward Cunningham, futur signataire du Manifeste, présente un retour d'expérience sur WyCash, un logiciel de gestion de portefeuilles financiers. Il y compare le fait de livrer un premier code imparfait à un emprunt. Un peu de dette accélère le développement, à condition d'être remboursée rapidement par une réécriture. Le danger vient de la dette qui n'est pas remboursée : chaque minute passée sur un code qui n'est pas tout à fait juste compte comme un intérêt. Cunningham cherchait une image qui parle à son responsable, dans une entreprise de logiciels financiers, pour justifier le temps passé à reprendre le code.

La dette technique désigne depuis l'ensemble des défauts de conception d'un logiciel qui rendent chaque modification future plus longue et plus risquée. Un exemple chiffré en montre le mécanisme. Un raccourci fait gagner deux jours aujourd'hui. Chaque modification ultérieure de cette partie du code demande ensuite une demi-journée de plus. À la quatrième modification, l'avance est consommée, puisque quatre demi-journées font deux jours. Chaque modification suivante est une perte nette. Les onze copies du calcul de prix, dans la scène, sont une dette de ce genre.

La métaphore a été souvent mal comprise, et Cunningham l'a précisée dans une vidéo de 2009. Il n'a jamais voulu justifier un code mal écrit. La dette dont il parlait vient d'une compréhension encore partielle du problème : on écrit le code selon ce que l'on sait aujourd'hui, puis on le reprend à mesure que l'on comprend mieux. Martin Fowler a proposé la même année de classer les dettes selon deux questions : la dette est-elle délibérée ou involontaire, et est-elle prudente ou imprudente ?

La comparaison a ses limites. Une dette financière a un montant et un taux connus, alors que personne ne peut lire le solde exact d'une dette technique. Les intérêts ne se paient par ailleurs que sur le code que l'on modifie : un défaut situé dans une partie que personne ne touche ne coûte rien.

Le refactoring : rembourser un peu chaque jour

Le refactoring consiste à améliorer la structure interne d'un code sans changer ce qu'il fait pour l'utilisateur. Le terme vient de la thèse de William Opdyke (1992), et Martin Fowler l'a fait connaître avec Refactoring (1999). Extreme Programming (XP) en a fait une pratique quotidienne : on procède par très petites étapes, et des tests automatisés vérifient à chaque étape que le comportement n'a pas changé. Sans ces tests, modifier la structure d'un code revient à travailler sans filet, ce qui explique la réponse de Samuel.

L'« attention continue » du neuvième principe correspond à cette pratique. Robert C. Martin, autre signataire, la résume par la « règle du scout » : laisser le code un peu plus propre qu'on ne l'a trouvé. Dans notre scène, il aurait suffi de regrouper le calcul du prix en un seul endroit le jour où il a été recopié pour la deuxième fois. L'opération aurait pris une heure. Le grand chantier de remise à plat, que les équipes réclament quand la dette est devenue trop lourde, coûte bien plus cher et se heurte presque toujours aux urgences du moment.

Hors du logiciel : deux cuisines de restaurant

La simplicité : ne pas faire le travail inutile

XP a donné au dixième principe une formule devenue célèbre, YAGNI, pour « You Aren't Gonna Need It » : vous n'en aurez pas besoin. Selon Martin Fowler, elle vient d'une conversation entre Kent Beck et Chet Hendrickson sur le projet C3 de Chrysler. Hendrickson énumérait des capacités dont le système aurait bientôt besoin, et Beck répondait à chacune qu'on n'en aurait pas besoin. La règle qui en découle est de réaliser une chose quand le besoin est là, et non quand on le prévoit.

Cette règle repose sur deux constats. Les prévisions sont souvent fausses, et le besoin arrive rarement sous la forme attendue. Le code écrit par avance n'est pas gratuit pour autant : il faut le tester et le maintenir, et il retarde ce qui est demandé aujourd'hui. Beck donnait en 1999 quatre critères d'une conception simple : le code passe tous ses tests, il ne contient pas de logique en double, il exprime clairement l'intention du programmeur et il compte le moins d'éléments possible.

La simplicité vaut aussi pour le produit. Un chiffre circule beaucoup à ce sujet : 64 % des fonctions d'un logiciel seraient rarement ou jamais utilisées. Il vient d'une présentation de Jim Johnson, du Standish Group, à la conférence XP 2002, et portait sur quatre applications internes d'entreprise. On ne peut pas le généraliser à tous les logiciels. L'idée qu'une part des fonctions livrées ne sert à personne reste une expérience courante, et le Lean la range parmi les gaspillages sous les noms de surproduction et de sur-traitement (voir Les sept gaspillages).

Le principe se transpose sans peine. Le formulaire d'inscription d'un centre de loisirs demande quarante renseignements aux familles, et la secrétaire en utilise douze. Les vingt-huit autres ont été ajoutés au fil des ans « au cas où ». Ils coûtent du temps à chaque famille, chaque année, et personne ne les lit.

Faire simple demande plus de travail que faire compliqué. Pascal s'en excusait déjà à la fin de la seizième Provinciale : « Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le loisir de la faire plus courte. »

La qualité interne fait-elle vraiment gagner du temps ?

On distingue la qualité externe d'un logiciel, que l'utilisateur perçoit, et sa qualité interne, que seuls les développeurs voient : la clarté du code et la présence de tests, par exemple. Le neuvième principe affirme que la seconde finit par accélérer le travail. Martin Fowler a formulé cette idée en 2007 sous le nom d'« hypothèse de l'endurance de la conception ». Négliger la conception fait gagner du temps au début, puis ralentit de plus en plus. Passé un certain seuil, le projet bien conçu a livré davantage que l'autre. Fowler estime que ce seuil est atteint en quelques semaines plutôt qu'en quelques mois. Il précise lui-même qu'il s'agit d'une conjecture et qu'il n'en existe pas de preuve objective.

Les enquêtes rassemblées dans Accelerate (Forsgren, Humble et Kim, 2018) vont dans le même sens : les équipes qui appliquent le plus de pratiques techniques déclarent livrer à la fois plus vite et avec moins d'incidents. Ces données sont déclaratives. Le principe repose donc sur une expérience de praticiens largement partagée et sur des indices, sans démonstration formelle (voir Que valent les preuves ?).

Limites et pièges

Les deux principes se surveillent l'un l'autre. Au nom de l'excellence, une équipe peut bâtir des mécanismes très généraux pour des besoins qui ne viendront jamais, ce que l'on appelle la sur-ingénierie et que le dixième principe interdit. Au nom de la simplicité, elle peut refuser toute réflexion préalable. Fowler a précisé en 2015 la portée de YAGNI : la règle vise les fonctions construites pour un besoin supposé, et non les efforts qui gardent le logiciel facile à modifier, comme les tests et le refactoring.

Certaines décisions sont par ailleurs coûteuses à reprendre. La sécurité, la structure des données et les contraintes réglementaires méritent d'être pensées tôt, et la simplicité ne consiste pas à les ignorer.

Le mot « dette » sert aussi à tout. On l'emploie pour désigner n'importe quel code qui déplaît, ou pour excuser un travail bâclé que l'on ne reprendra jamais. Une dette prise en connaissance de cause, pour tenir une échéance importante, peut être un choix raisonnable si son remboursement est prévu.

La qualité interne est enfin invisible pour ceux qui financent le projet. Ils voient les fonctions livrées et ne voient pas l'état du code. L'équipe doit donc expliquer ses choix dans leur langage, ce qui était le but premier de la métaphore de Cunningham. Beaucoup d'organisations ont adopté les réunions de l'agilité sans ses pratiques techniques. Fowler a décrit le résultat en 2009 : au bout de quelque temps, le projet ralentit parce que le code est devenu inextricable (voir Être agile ou faire de l'agile).