The .Net frog

On a trop souvent tendance à opposer rapidité de développement et qualité. Ces 2 caractéristiques ne sont en fait pas situées sur le même axe : faire diminuer la qualité n'implique pas une accélération du temps de développement. Bien au contraire.

Le raisonnement est généralement le suivant : il faut implémenter le plus rapidement une solution qui "fonctionne", pas besoin de faire quelque chose de spécialement brillant ou "beau techniquement". Malheureusement, c'est oublier une vérité fondamentale du développement logiciel :

Le coût total d'un projet est égal à la somme du coût de développement et du coût de maintenance.

Il se trouve que dans notre industrie, le coût de maintenance représente généralement plusieurs fois le coût de développement d'une solution. Chaque ligne de code sera lue plusieurs dizaines de fois après son écriture, chaque classe sera modifiée par plusieurs développeurs, des fonctionnalités devront être ajoutées dans chaque couche, sur chaque écran... La nature changeante des besoins des utilisateurs d'un produit font que ce dernier est systématiquement amené à évoluer.

Il est alors intéressant de pousser l'analyse un cran plus bas... En effet, un projet est lui même une suite de mini-projets qui, bout-à-bout, forment un tout cohérent et utilisable. Par exemple, pour implémenter une fonctionnalité on aura besoin d'aller préciser le besoin auprès du business, de réfléchir à l'implémentation, de réaliser l'implémentation, de tester la solution développée, ou de la documenter. Il faudra la débugger plusieurs fois et de la modifier pour faire face à de nouveaux besoins... Ces différentes étapes s'étalent dans le temps et peuvent impliquer une ou plusieurs personnes. Un projet peut donc être découpé en plusieurs dizaines ou centaines de mini-projets.

Or la définition du coût total d'un projet est aussi applicable pour l'ensemble de ces mini-projets. Autrement dit, chaque fois que la qualité est mise de coté dans un mini-projet, on augmente de façon significative le coût de maintenance pour ce dernier. Par conséquent, on augmente également la durée et le coût de développement pour le projet parent de manière générale (la maintenance d'un mini-projet faisant parti du coût de développement du projet parent). La vision court-termiste consistant à sacrifier la qualité sur l'hôtel de la rapidité de développement revient à se tirer une balle dans le pied.

Pour s'en convaincre, il suffit de prendre un exemple très simple :

Considérons un projet X constitué de 10 mini-projets. Dans un scénario idéal ou la qualité interne de mon projet reste élevée, chaque mini-projet nécessite un temps de développement de 3 (jours, mois, points, patates, peut importe :-)) et un temps de maintenance de 7. La durée totale du projet X est donc de 100.

Admettons maintenant qu'en sautant les étapes permettant de garder une qualité élevée, j'arrive à faire baisser le temps de développement initial de chaque mini-projet à 2. "Hourra ! Je viens de gagner 10 sur la durée totale, mon patron va me féliciter ! Mais? Mais? pourquoi mes développeurs ont de plus en plus de mal à modifier et debugger l'application? Damn it !" Mon coût de maintenance vient en fait de passer à 10 pour chaque mini-projet, soit un coût total de 120. On commence à comprendre pourquoi la plupart des projets informatiques sont en retard voir annulés...

Une fois que l'on est convaincu par cette analyse, il devient très simple de comprendre une autre vérité fondamentale du développement logiciel :

L'augmentation de la qualité interne d'une solution provoque une augmentation de la rapidité de développement.

Et non pas l'inverse !

Par conséquent, il est important de prendre le temps nécessaire pour refactoriser sa solution logicielle, sous peine de voir la dette technique exploser. Cet investissement est systématiquement bénéfique !

Edit : Scott bellware nous présente une excellente métaphore sur la qualité logicielle et pourquoi elle est primordiale. Je garde son exemple basé sur la colonne vertébrale en tête !