On entend souvent dire que les gens veulent des projets qui aillent vite, qui ne coûtent pas cher et qui soient de qualité, mais qu’on n’a droit d’avoir que deux de ces qualités à la fois. Ce dicton s’applique très bien aux produits matériels, qu’il s’agisse de construire une maison ou d’acheter une voiture. C’est une simple question de bon sens : des matériaux de qualité coûtent cher, un travail de qualité nécessite de prêter attention aux détails, ce qui prend du temps, et le temps, c’est de l’argent…
Penser long terme
Ce slogan atteint ses limites lorsqu’on réfléchit à plus long terme : si on choisit un article de faible qualité, il sera peut-être rapide et pas cher à produire, mais il ne durera probablement pas très longtemps, ce qui impliquera le besoin de refaire l’achat. La qualité, à l’inverse, est à l’épreuve du temps. Elle demande un investissement initial plus grand, mais celui-ci finit rentabilisé avec le temps. Le monde qui nous entoure est rempli d’exemples de villes ou d’entreprises qui ont dû débourser bien plus que prévu parce qu’après avoir choisi le prix le plus bas, elles ont dû tout reconstruire après un échec cuisant (imaginez la perte si on parle de payer deux fois pour un projet énorme comme construire un pont ou concevoir un avion). Ça coûte cher d’être radin.
Au final, cette opposition entre temps, argent et qualité ne marche que pour les dépenses unitaires. Si vous voulez investir dans quelque chose qui dure (parce qu’une panne entraînera forcément une réparation ou un remplacement), alors il est plus judicieux de payer davantage dès le début pour ne pas avoir à faire la dépense plusieurs fois.
Maintenant, imaginons autre chose : supposons que nous voulions construire un bureau. Cela pourra être un projet rapide et pas cher en collant vite fait quelques planches. A première vue, le bureau est aussi fonctionnel que n’importe quel autre bureau. Ça n’est peut-être pas le plus joli, mais vous êtes satisfait du résultat : il n’a pas coûté une fortune ni pris énormément de temps à assembler. Mais avec le temps, vous allez commencer à réaliser que même s’il remplit sa fonction basique, en passant un peu plus de temps à réfléchir à toutes les utilisations que vous comptiez en faire, vous auriez probablement fait un peu différemment. Ou vous allez remarquer une petite erreur de conception qui nécessite de tout démonter pour être corrigée. Ou peut-être que vos besoins ont simplement évolué avec le temps : le bureau est devenu une table sur laquelle s’accumulent des charges de plus en plus lourdes. Bref, quelle que soit la raison, le résultat initial ne fait plus tout à fait l’affaire. Il est temps de prendre en compte de nouvelles exigences. A cause des décisions de la première version (comme utiliser de la colle pour assembler le tout plutôt que d’autres méthodes moins définitives), il est impossible de simplement démonter le meuble pour le modifier. Il va falloir repartir de zéro, et faire face aux même coûts que la première fois. D’un autre côté, en prenant plus le temps d’assembler les éléments d’une manière plus évolutive la première fois, on aurait pu récupérer les matériaux d’origine en se contentant d’apporter quelques modifications mineures à la conception initiale pour prendre en compte les nouveaux besoins, ce qui aurait réduit considérablement le montant dépensé.
« Une fois pour toutes » n’existe pas dans l’informatique
Quel lien pouvons-nous donc faire avec le développement logiciel ? Il faut reconnaître que nous avons parfois du mal à définir ce que nous appelons la qualité logicielle. A cause de cette idée que quelque chose de rapide et pas cher a une qualité moindre, nous avons tendance à baisser nos standards pour respecter des échéances trop courtes. Ce qui pourrait en partie se justifier si notre vision de la qualité se limitait à des caractéristiques visibles extérieurement (comme une belle interface graphique ou une expérience utilisateur soignée) et que nous pensions livrer notre logicielle une bonne fois pour toutes. Le problème est que c’est rarement le cas.
Premièrement, un développement de qualité implique moins de bugs. Comme nous le savons bien, plus tôt un bug est identifié, moins il sera cher à corriger. Les bugs identifiés en production seront les plus coûteux à éliminer, sans même parler des pertes potentielles en termes d’image pour l’entreprise (d’autant plus importantes quand on travaille sur du logiciel critique, dans le domaine de l’aviation, de la banque ou de la santé par exemple).
Deuxièmement, les exigences fonctionnelles évoluent continuellement. Une fois la première livraison passée, vous allez immédiatement commencer à travailler sur les prochaines évolutions. Ajouter des fonctionnalités, corriger des bugs… La mécanique interne du projet va forcément en être impactée. C’est là que la qualité du code va faire une différence essentielle : une conception propre et une architecture flexible vont largement contribuer à la réutilisation de l’existant à moindre coût. D’un autre côté, si vous préférez assembler quelques lignes de code de la plus rapide des manières pour faire des économies de bouts de chandelles, les bugs les plus simples vont prendre une éternité à investiguer et à corriger.
Certains pensent que cette phase de maintenance est encore suffisamment lointaine pour ne pas à avoir à s’en préoccuper, et qu’il y aura largement assez de temps pour remédier à ces problèmes d’ici-là. En faisant quelques concessions avec la qualité maintenant, on pourra gagner un peu de vitesse de développement et on améliorera les choses lorsque le besoin s’en fera sentir. C’est la définition même du concept de dette technique : réduire la qualité dans l’immédiat pour livrer plus vite, et rembourser la dette plus tard, avant que les intérêts (la perte de productivité découlant d’une mauvaise conception) n’explosent.
Mais là aussi, cette idée est biaisée parce que les changements d’exigences n’attendront pas la première livraison. Les PO peuvent changer d’avis régulièrement, les spécifications évoluent avant qu’on ait fini de les implémenter, et la conception est remise en question avant même qu’une première version de l’application ne voit le jour. Cela implique que le coût de la dette technique va commencer à se faire sentir bien plus vite qu’on ne le croie. Martin Fowler estime que quelques semaines suffisent pour en sentir les effets, et voir à quel points les conséquences des choix techniques impactent la vélocité d’une équipe.
Passer le mot
Je reconnais avoir fait beaucoup de suppositions et de conjectures jusqu’ici sans fournir de chiffres précis pour appuyer mes dires. Puisque notre instinct, même en tant qu’ingénieurs expérimentés, nous pousse souvent à baisser nos exigences de qualité pour accélérer la cadence, quelques chiffres seraient les bienvenus pour appuyer cet article. Malheureusement, les vrais éléments de comparaison sont difficiles à trouver dans le monde réel, en partie parce que nous avons rarement affaire à un même projet construit deux fois à l’identique, si ce n’est le niveau de qualité, pour comparer quelle implémentation s’est terminée en premier et laquelle a fourni les meilleurs résultats ou a eu le moins de bugs.
Un petit exercice de mathématiques pourra au moins permettre d’appréhender des tendances, mais cet article est déjà suffisamment long en l’état. En attendant de se livrer à cet exercice, on pourra cependant retenir que nos managers ont souvent entendu la règle des trois contraintes, qui comme on l’a vu, reposent sur des principes erronés lorsqu’on l’applique au monde du logiciel. Il en va donc de notre responsabilité, en tant que développeurs, de les éduquer et de leur expliquer pourquoi repousser l’écriture de tests automatiques au dernier moment par exemple est contre-productif, aussi bien pour eux que pour nous.
« Il n’y a pas de compromis entre qualité et rapidité dans le monde du logiciel. Il n’y en a jamais eu. Une faible qualité implique une faible vitesse. Toujours. La seule façon de coder vite, c’est de coder bien. » Robert “Oncle Bob” Martin