La qualité logicielle, c'est aller vite, longtemps
Nombreux sont les partisans du quick and dirty, le dirty étant la contrepartie nécessaire d’un excellent Time to Market. Autrement dit, advienne que pourra ensuite ! Sauf que cette opposition est fallacieuse – et sert trop souvent à masquer un simple manque de savoir-faire : qualité et rapidité ne s’excluent pas, bien au contraire.
Mieux : nous allons montrer que la qualité est une notion temporelle par essence. Pour cela, raisonnons par l’absurde.
Produire de la qualité en un temps infini ?
Supposons que vous n’ayez aucun test automatisé. Le comportement de la nouvelle fonctionnalité devra être testé à la main, c’est faisable, et de toute façon il faut toujours le faire. En revanche, vous devrez également tester à la main la non-régression suite à ces nouveaux développements.
Cela implique, selon la complexité de votre application, de tester des centaines ou des milliers de combinaisons possibles. Sauf qu’ici, contrairement à des tests unitaires, chaque micro-variation par rapport au test précédent vous obligera à répéter l’intégralité du parcours utilisateur. Faisable en théorie, impossible en pratique.
Ainsi, produire du logiciel de qualité n’a de sens que si l’on peut le produire vite, en tout cas raisonnablement vite. La qualité est donc une notion profondément inscrite dans le temps.
Il est facile de produire vite, au début
Dans les premiers temps de vie d’un produit, il est assez facile de produire du logiciel rapidement et sans bug. D’autant plus rapidement qu’on prend tous les raccourcis possibles dans le code, d’autant plus rapidement que l’on s’endette techniquement. Pour l’œil non averti, cette dette est invisible, la seule chose visible étant le logiciel qui fonctionne.
Mais la dette technique ainsi accumulée finit par se payer, soit en temps, soit en bugs, et plus généralement les deux :
-
En bugs, parce que des couplages indus se sont installés dans le code, parce que ce dernier est difficilement compréhensible, parce qu’aucun test automatique n’est là pour vous « rattraper » ;
-
En temps : dans le meilleur des cas, parce que les développeurs ont conscience de la dette et font du refactoring avant d’ajouter de nouvelles fonctionnalités et multiplient les tests de non-régression. Sinon, juste du temps perdu à tenter de stabiliser une application qui leur échappe.
Une définition de la qualité logicielle intégrant la dimension temporelle
À ce stade, la métaphore du marathon devrait vous paraître assez intuitive : vous devez adopter dans le développement comme dans la course une allure que vous pourrez soutenir. Démarrer 1 km/h au-dessus de votre allure cible, c’est obérer vos chances de finir dans le temps que vous visez, voire de finir tout court. Développer à toute vitesse, écrire du code qui fonctionne maintenant mais sans considération d’architecture ou de test, c’est obérer vos chances de sortir des fonctionnalités complexes sur le long terme.
La qualité ne pouvant s’évaluer que sur le long terme, il faut en proposer une nouvelle définition :
La qualité, c’est la capacité à produire du logiciel utile et utilisable à un rythme soutenu sur le long terme.
Au final, il est amusant de voir que cette définition de la qualité intègre pleinement la notion de vitesse, quand beaucoup se plaisent à les opposer.
Dans un prochain article, j’utiliserai cette définition pour éclairer un sujet difficile : comment mesurer la qualité logicielle ?