La qualité logicielle, c'est aller vite, longtemps.

Et je vais vous le prouver.

Produire de la qualité en un temps infini ?

On pourrait être tenté de définir la qualité logicielle en partant des pratiques : test, modularisation, clean code, refactoring etc. Cela parle de qualité mais cela ne la définit pas. Alors, qu'est-ce qu'un logiciel de bonne qualité ?

D'après Chat GPT, "la qualité logicielle désigne l'ensemble des caractéristiques d'un logiciel qui lui permettent de répondre aux besoins des utilisateurs, d'être fiable, performant, sécurisé et maintenable tout en respectant les exigences spécifiées".

Cette définition a du bon, car elle met au centre la satisfaction de l'utilisateur, critère ultime et peut-être plus pertinent que l'absence de bugs. Elle évoque d'autre part la maintenabilité, terme connoté projet qui a quand-même le mérite d'introduire la dimension temporelle. Que serait en effet la qualité s'il fallait un temps infini pour produire le prochain incrément de logiciel ?

Supposons que vous n'ayez aucun test automatisé. Le comportement de la nouvelle fonctionnalité devra être testé à la main, c'est généralement faisable. En revanche, la non-régression devra également être faite à la main, ce qui 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, mais dans quel délai ?

Ainsi, produire du logiciel de qualité n'a de sens que si l'on peut le produire vite, en tout cas raisonnablement vite.

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 tout œil non averti, cette dette est invisible, la seule chose visible étant le logiciel qui fonctionne.

Mais la dette technique finit par se payer, soit en temps, soit en bugs, et plus généralement les deux :

• En temps, par un allongement des délais, quand les développeurs ont conscience de la dette et font du refactoring avant d'ajouter de nouvelles fonctionnalités. Sans oublier la non-régression, à la main mon cousin.

• 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".

Une définition de la qualité logicielle intégrant la dimension temporelle

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.

Cela n'est pas sans évoquer les DORA metrics, bien que ces dernières ne suffisent pas à mesurer la qualité du développement. Par exemple, le lead time est le temps moyen qui s'écoule entre un commit et son déploiement en production. Tout ce qui se passe en amont du commit (développement en tant que tel, mais aussi la phase de conception fonctionnelle) n'est pas comptabilisé dans ce délai.

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 – notamment parce que cela permet de justifier leur sacro-saint "quick and dirty" et de cacher leur manque de savoir-faire…