Un post de Nicolas Martignoles a récemment attiré mon attention sur un article comparant les coûts de maintenance des logiciels en fonction des langages

L’article évoque en substance des coûts élevés pour les applications Java (un facteur 4,3) par rapport aux applications Cobol. Le tout basé sur une étude de 745 applications. C# semble nager dans les mêmes eaux que Java (cela semble logique). Pire: C++ semble mieux loti que Java ! J’aime bien le C++, mais cela devient franchement troublant.

En réalité l’étude fait état d’une réalité sous-jacente bien différente.

La maturité d’une application est un facteur important !

Eh oui, une application “neuve” n’est pas forcément la meilleure sous seul prétexte qu’elle a été écrite à partir d’une feuille blanche ! Cette application est surtout plus “verte”. Je pense qu’il y a différents facteurs jouant sur l’aspect maturité:

• Une application mature est souvent plus stable. On passe au bout d’un certain temps de demandes de changements de type évolutif à des correctifs ou de ajustements liés à des conditions d’utilisation métier qui ont évolué. Ce facteur va dans le sens d’une maintenance moins chère. Hélas ce facteur de stabilité est aussi souvent le signe d’une transition de l’application vers une phase de fin de vie.
• Un refactoring applicatif intégrant une flexibilité liée aux évolution. Au delà du design initial d’une application parfois liminaire, les changements demandés sur une application peuvent amener les développeurs à raffiner la conception pour en rendre les changements moins douloureux. Cette approche va souvent de pair avec une amélioration de la couverture de tests. Cela ne concerne hélas qu’une minorité d’application car elle nécessite des développeurs chevronnés sensibles à ce facteur. La majorité des applications se trouve plutôt dans la seconde catégorie.
• Une entropie des applications suite à des modifications / corrections successives. les applications qui ne sont pas vraiment sous contrôle en terme de tests ont tendance à faire l’objet de “patch”, de correctifs dits chirurgicaux sans en raffiner la conception. Au contraire cela augmente la fameuse “entropie du logiciel”, c’est à dire une dégradation de son design qui augmente la crainte des développeurs d’y toucher, augmentant à son tour les pratiques accélérant l’entropie du logiciel ! Cette spirale se termine finalement par une sclérose totale du code conduisant à la réécriture complète de celui-ci.

L’expérience des développeurs

L’article insiste à juste titre sur les pratiques managériales privilégiant une équation économique court terme. En clair: on embauche des développeurs inexpérimentés à bas salaires pour réduire les coûts. Advienne que pourra de la maintenance ultérieure !

Effectivement les équipes de développement Java sont des équipes jeunes. Il est rare d’y croiser des développeurs de plus de 10 ans d’expérience. On parle déjà de développeur sénior pour des jeunes ayant 5 ans de pratique professionnelles dans les pattes. Il est vrai que le développeur armé de 15 ans d’expérience est d’une part plus cher que son homologue Coboliste et d’autre part qu’il cherchera plutôt une position d’architecte, de team leader ou d’expert technique. Nous avons là deux cultures différentes.

En contrepartie, il n’existe probablement plus de développeur Cobol débutant. Il ne faut pas se leurre, Cobol n’est probablement pas le language le plus sexy, mais la communauté des développeurs n’est pas nécessairement formée d’idiots (en fait, il y a probablement la même proportion d’idiots chez les Cobolistes que chez les Javanais) et les 20 ou 30 ans d’expérience de ces développeurs s’ils ne sont pas un facteur linéaire de compétence les aident produire du logiciel de qualité.

java le nouveau  Cobol ?

Java est le langage majeur des nouvelles applications de gestion. Il absorbe une quantité très importante de la profession avec une disparité de qualification très importante et globalement une population peu expérimentée. A ce titre, il ressemble à ce qu’était Cobol dans les années 80. Il est d’ailleurs devenu un lieu commun de dire que Java est le Cobol des années 2000 (ou 2010 maintenant). L’article avance sans doute avec raison l’existence d’une population importante de développeur Java sans formation solide. C’est aussi ce que j’ai pu voir en entretien de recrutement.

Et C++ ?

Je persiste à dire que C++ a un coût de développement, donc de maintenance potentiellement plus élevé que Java:

• Le langage est difficile, beaucoup plus difficile et piégeux.
• Le langage est de bas niveau et ne possède pas l’écosystème de librairies et frameworks s’assemblant rapidement pour adresser certaines problématiques. Pour ne pas parler des outillages et de la communauté open-source…

Mais voilà, beaucoup de développeurs “moyen” ont déserté C++ dans les années 2000, la population C++ est essentiellement constituée de développeurs aguerris, expérimentés sur le langage, voir d’amoureux de ce langage ! Bref la communauté s’est professionnalisée ! Il n’est pas étonnant de constater que la qualité des conceptions et du code produit en C++ soit supérieure, moins sujette au bugs. Cela n’a rien à voir directement avec le langage, mais avec la communauté.

Un jour peut-être…

L’article est trompeur sur son affirmation, mais pas sur son contenu. Les deux facteurs premiers avancés sont réels:

• Réécrire sans cesse les applications n’est pas une solution. Une application “verte” est toujours plus baguée. De bonne pratiques de maintenance incluant une couverte de tests unitaires et une utilisation agressive du refactoring étendent de manière très importante la durée de vie des applications jusqu’à leur réelle obsolescence technologique (au lieu de la limite de sclérose).
• L’expérience et la compétence sont des facteurs clé. Ils prédominent largement les aspects de contexte technologiques. On le sait depuis longtemps, mais le management classique reste imperméable à ces assertions.

Ma conclusion n’est pas que Java est un mauvais langage. Sans doute en existe-t-il de meilleurs et je sais qu’il il y en a de moins bon. En fait, peu importe. Je conclue surtout que les valeurs agiles et le Software Craftmanship vont dans la bonne direction: du logiciel de qualité développé avec rigueur et compétence.