Qualité vs. portée


Si vous avez déjà été développeur de logiciels, peu importe où et quand, il est probable qu’à un moment donné, vous ayez dû travailler avec un code mal écrit (lire cauchemar). Pour une raison quelconque, le code a cessé de fonctionner ou doit être amélioré et vous avez été le pauvre bougre qui doit trouver pourquoi le codeur initial a écrit le programme de cette façon. Si beaucoup d’entre nous, dans le domaine des technologies de l’information, sont attachés aux normes, beaucoup d’autres considèrent la qualité comme un moyen facile de réduire le budget des LLL.

Si j’avais un dollar pour chaque fois que j’ai entendu la phrase « si le code fonctionne, alors c’est la qualité elle-même », je serais…eh bien vous connaissez la suite… Le code pourrait fonctionner et tout semble bien aller maintenant, mais à long terme, le logiciel sera de plus en plus difficile à maintenir. Une fois que les codeurs d’origine sont partis ou ne sont pas disponibles, les problèmes ne peuvent plus être résolus facilement et sont souvent transmis au service d’assistance technique. Il se peut que le logiciel doive éventuellement être redéveloppé à partir de zéro. Produire des logiciels de qualité est un investissement.

Si un projet est conçu avec soin et que la qualité du code est continuellement examinée et les normes respectées, il est probable qu’il créera une situation stable où l’ajout de nouvelles fonctionnalités ou l’incorporation de certains changements n’auront pas été plus coûteux et plus longs au fil du temps. En bref, un logiciel de meilleure qualité est synonyme de satisfaction accrue de l’utilisateur final, de moins d’appels au support technique et de meilleures perspectives commerciales en général. Ayant moi-même été développeur, je sais combien il est facile, sous la pression des entreprises et des développeurs individuels, de faire le travail le plus rapidement possible, la qualité passant après la vitesse et le coût.

Cependant, mon expérience me dit aussi que, quelle que soit la pression que vous subissez, il vaut toujours la peine de considérer qu’il vaut mieux réduire la portée du projet plutôt que de compromettre la qualité du logiciel. À long terme, cette stratégie devrait vous rapporter beaucoup d’argent.