Back to Top
  • Boulevard de France, 9 bât A 1420 Braine l'Alleud
  • +32 (0) 2 318 83 22

Le logiciel, un équilibre à maintenir

Nous avons beau répéter sans cesse que dans une entreprise, il faut toujours se concentrer sur ce qui ne marche pas, et ne jamais toucher à ce qui tourne bien ... nous ne sommes jamais à l'abri d'une erreur de jugement.

Dans ce monde connecté où 95% du code source fini par être écrasé par de nouveaux morceaux de codes, nous savons qu'il ne faut pas risquer de casser ce qui fonctionne - et pourtant ... nous répétons encore cette erreur.

Plusieurs facteurs peuvent amener à ré-écrire un code malgré le bons sens. Certains sont louables, d'autres beaucoup moins.

1 - L'orgueil du programmeur et le besoin de tout contrôler

Faites entrer un nouveau programmeur dans votre entreprise, et fort à parier que si il n'est pas directement guidé, il souhaitera installer son propre environnement de développement avec son propre framework, ses propres librairies etc. C'est une réaction tout à fait logique, car le programmeur souhaite avant tout être performant et se sentir bien avec ses propres outils. Mais cela mène hélas souvent à le laisser préférer ré-écrire de l'ancien code pour se conformer à ses propres habitudes. Plutôt que d'analyser le code existant, il pourrait préférer le ré-écrire pour être certain de garder le contrôle. Après tout, il devient responsable du code qu'il écrit, alors autant qu'il le connaisse parfaitement ?

2 - Une technologie obsolète ? Nos clients utilisent des logiciels programmés dans des langages en voie d'extinction ? Oui, il serait en effet plus sage de penser à migrer - mais si ces langages sont toujours maintenus ? Saviez-vous que Delphi permettait la programmation en 64 bits et en multicœurs ? Bien sûr, il devient plus rare de trouver les programmeurs maîtrisant cette technologie. Il faut penser à migrer pour les bonnes raisons - souvent, les programmeurs préfèrent les nouveautés, pour ne pas s'enliser dans des technologies obsolètes. C'est une sorte de course en avant à laquelle il est difficile de ne pas participer.

3 - Nous pensons mieux savoir que le client lui-même

Voici sans doute le pire des réflexes. Combien de fois pouvons-nous avoir une idée et se dire que d'office le marché ou le client l'adoptera ? L'informaticien doit avant tout être à l'écoute - le client connait son métier, il ressent ses besoins - à nous de les traduire en fonctionnalités respectant ses contraintes (budgétaires, délais et qualité souhaitée).

4 - La poursuite de la performance

Un code peut toujours être amélioré - on peut le rendre plus rapide, plus flexible, plus clair, plus performant, plus court, mieux documenté etc. La perfection est un ennemi de la productivité. Get the job done!

5 - Plus de budget

Malheureusement, il est parfois plus facile de vendre un nouveau code à un client que d'améliorer un ancien. Certaines méthodologies, mal utilisées, peuvent amener un projet à ne jamais se terminer non plus, avec une meute de consultants payés en régie et des itérations successives qui ne convergent jamais vers une solution ... le temps passe et les managers changent, on repart de zéro, et on consomme du budget. Dans certaines grandes structures, on se demande même si ce n'est pas une maladie, une espèce de développement continu où, vu de loin, on sait que le code est totalement remplacé tous les deux ou trois ans.

6 - S'éloigner des standards

Avant de vouloir écrire un code, mieux vaut sans doute regarder si celui-ci n'existe pas déjà quelque part - pouvons-nous contribuer à un code open source existant ? Pouvons-nous acheter une librairie maintenue par une communauté de développeurs ? Ré-écrire la roue est un moyen sûr qu'un jour son code soit remplacé par un autre.

 

Finalement, on en arrive à la conclusion qu'il vaut mieux rester dans des environnements les plus standards, produire le moins de code sur mesure possible, et surtout, surtout, toujours écouter les besoins du client et ne jamais s'attaquer à quelque chose qui fonctionne sans une excellente raison.