Publié le

L'importance de la bonne conception logicielle

4 min lecture - 733 mots
Auteurs
  • avatar
    Nom
    Cédric RIBALTA
    Twitter

Introduction

Ici nous allons voir pourquoi la bonne conception logicielle est importante.
Dans cete étude de cas, les données que je vais présenter sont issues d'une vraie société.

La taille de l'équipe de développement

Ce 1er graphique montre l'évolution des itérations de développement en fonction de la taille de l'équipe de développement.
Lorsqu'on l'observe, on peut se dire que c'est super encourageant de voir l'équipe de développement grandir au fur et à mesure des releases.

Visual representation of software development team growth over time, showing increasing team size.

Le nombre de lignes de code

Le 2ème graphique montre l'évolution des itérations de développement en fonction du nombre de lignes de code.
Au tout début, on peut observer une croissance exponentielle, mais on atteint rapidement un plateau avant de stagner.

Visual representation of software development team growth over time, showing stagnation of code lines.

Le coût par ligne de code

Ce graphique n°3 devient inquiétant.
Ici on observe le coût de chaque ligne de code en fonction de la release.

Pourquoi observe-t-on un tel changement dans la productivité de l'équipe de développement ?
Pourquoi le code est 40 fois plus cher entre la release 1 et la release 8 ?

Visual representation of software development team growth over time, showing rising cost per line of code.

La productivité

Le graphique n°4 montre une diminution importante de la productivité des développeurs au fil des releases. Plus les releases avancent, plus la productivité chute.

Du point de vue des développeurs, c'est très frustrant car ils ont l'impression de travailler de plus en plus pour obtenir de moins en moins.

Visual representation of software development team growth over time, showing decreasing productivity.

La masse salariale

Si vous pensiez que c'était mauvais, imaginez à quoi cela ressemble pour les managers qui voient les coûts augmenter de manière exponentielle.
Ce 5ème graphique montre l'envolée de la masse salariale au fur et à mesure des releases.

Visual representation of software development team growth over time, showing increasing payroll costs in a timeline format.

La release n°1 a été effectuée avec une masse salariale de quelques centaines de milliers de dollars.
Mais une fois arrivé à la release n°8, la masse salariale est passée à 20 millions de dollars, et ça continue d'augmenter.

Ce graphique tout seul est déjà effrayant, mais si on le compare avec le nombre de lignes de code produit du graphique n°2.
On peut voir qu'au début on avait beaucoup de fonctionnalités pour un coup de quelques centaines de milliers de dollars.

Mais pour la 8ème release, on dépense 20 millions de dollars pour quasiment aucune nouvelle fonctionnalité.

Donc la 1ère question qui me vient à l'esprit est : "quelle action peut-on prendre pour stopper cette spirale infernale ?"

Que s'est-il passé ?

La réponse à cette question est dans la fable du lièvre et de la tortue :

  • Le lièvre est le développeur qui court très vite, qui code très vite, qui ajoute des fonctionnalités très vite.
  • La tortue est le développeur qui prend son temps, qui réfléchit à la conception, qui fait des choix techniques judicieux.

Au début, le lièvre est en avance, il a déjà ajouté plein de fonctionnalités.
Mais à un moment donné, il se rend compte qu'il a fait des choix techniques qui ne sont pas bons, et il doit revenir en arrière pour corriger ses erreurs.

Le lièvre croit dans ce mythe connu, qui est :

Je pourrais nettoyer le code plus tard, la priorité est de livrer le produit.

Bien entendu, le code ne sera jamais nettoyé parce que le marché est très compétitif.
Une fois le produit disponible, la concurrence est déjà en train de travailler sur la prochaine version et il faut les garder à distance en ajoutant de nouvelles fonctionnalités le plus vite possible.

Tout comme le lièvre qui était trop confiant sur sa vitesse, le développeur qui code trop vite est trop confiant sur sa capacité à nettoyer le code plus tard.

Conclusion

Dans cette étude de cas, le plus gros mensonge concerne le fait qu'écrire du code sale est plus rapide dans l'immédiat, et les ralentissements ne se verront que plus tard.

Dans les faits, faire les choses à la va-vite sera toujours plus lent que de les faire correctement dès le début.

The only way to go fast is to go well - Robert C. Martin

Moralité : la bonne conception logicielle est un investissement à long terme.