Le monde est plein de logiciels mal conçus qui exposent les entreprises à beaucoup de risque, selon une analyse réalisée sur 745 applications. Ces problèmes sont issus de la programmation qui ne se conforme pas aux bonnes pratiques de codage et d'architecture. Cette pratique est aussi appelée « dette technique ». Un code de mauvaise qualité, fruit d'un manque d'investissement ou d'une faible compétence, peut-être le responsable d'un arrêt du SI, d'une faille de sécurité, d'une performance médiocre ou d'une corruption des données. La réparation de chaque ligne de code a un coût, ou une « dette technique » qui s'accumule. Le meilleur exemple de cette « dette technique » est le fameux bug de l'an 2000. De nombreuses applications étaient prêtes à représenter le millénaire en 00, mais en l'interprétant comme étant 1900. Les entreprises ont dépensé des sommes astronomiques pour mettre à jour leurs applications.
Cast Software, éditeur d'outils testant la qualité des logiciels en matière de codage et d'architecture, a analysé les 745 applications (issues de 160 entreprises de 12 secteurs industriels) qui combinent 365 millions de lignes de code. L'analyse a recensé1800 types d'erreurs de développement dans les applications écrites en Java EE, Cobol,. Net, C, C + + et d'autres langages de programmation.
Java coûte plus cher à réparer que Cobol
Cast a compté le nombre d'erreurs et a évalué la dette technique moyenne à 3,61 $ pour réparer chaque ligne de code. Ce chiffre est basé sur ce qu'il en coûterait pour réparer chaque erreur à hauteur de 75 $ de l'heure. En regardant les différents langages de programmation, Java EE est le plus onéreux à 5,42 $ par ligne de code, tandis qu'une erreur sur Cobol ne coûte que 1,26 $. Bill Curtis, ingénieur en chef chez Cast, estime que « Cobol est mieux fait parce que le code est plus âgé. Les programmeurs « se sont battus dessus depuis 30 ans » et ont réussi à corriger les erreurs les plus critiques ». En ce qui concerne Java, Bill Curtis, explique qu'il ne peut que spéculer sur les problèmes, mais déclare qu '«il y a beaucoup de gens qui font du Java aujourd'hui et qu'ils n'ont pas vraiment de solide formation en informatique. »
L'étude menée par Cast intéresse beaucoup d'entreprises et d'université qui se penchent avec intérêt sur ce concept de dette technique. Ainsi, le cabinet Gartner a renchérit sur ce sujet en parlant de « dette IT » et en estimant le coût de cette maintenance a posteriori à 500 milliards de dollars en 2010. Elle devrait même atteindre 1000 milliards de dollars dans quelques années.
Erreurs de programmation : Java coûte plus cher que Cobol
5
Réactions
Cast Software a réalisé une étude sur le coût des erreurs de programmation. Le langage Java serait plus onéreux à corriger que le Cobol.
Newsletter LMI
Recevez notre newsletter comme plus de 50000 abonnés
La dette technique s'évalue à partir de règles de contrôle sur le code source ou le code binaire.
Signaler un abusLe nombre de règles et donc points de contrôle a donc une très forte influence sur son évaluation sur une technologie donnée.
Java notamment bénéficie d'une forte activité avec de nombreuses solutions Open Source ou commerciales. Par exemple si on additionne les solutions open source (utilisées par Cast Software je crois, et réalisateur de l'étude) on arrive à plusieurs centaines de règles (CheckStyle, PMD, Findbugs, etc.).
En COBOL, il existe à contrario peu d'outils et un nombre réduit de règles.
Donc la comparaison entre 2 technologies peut-être largement faussée. A voir comment CAST a pris cela en compte dans son étude ?
Ou si on est dans du marketing ...
Il semble que la "dette IT" croisse à raison des quantitées de code crées exactement de la même façon que certains économistes corrèlent l'augmentation de la dette souveraine et de la consommation d'énergie fossile.
Signaler un abusLes coûts cachés s'accumulent jusqu'au moment ou on ne peut plus se voiler la face...
Oui c'est énervant cette manie de ne pas citer les sources. Est-ce que c'est un passant sur le parvis de la Défense qui vous en a parlé ? Autrement on comprend que l'information viendrait de Cast Software qui est l'entreprise qui vend les outils de mesure, ce qui est du coup déonthologiquement limite.
Signaler un abusD'autre part je suis d'accord avec Fabien comparer des ligne de COBOL et des lignes de Java n'a pas de sens en soi. Pour cela il faudrait comparer la même application écrite en COBOL puis écrite en Java avec strictement la même méthode de développement, évidement dans la vraie vie personne ne fait ça, le développeur à horreur de faire deux fois la même chose il factorise !!!!
Le langage futur sera le Ruby... Les plateformes de développement de ce langage permettent d'industrialiser le développement et éliminent toute la dette technique, car à chaque spécification définie la totalité du code est recalculé. Les team de dév deviennent alors hyper agile et productive, car chacun travail en même temps sur sa partie sans avoir à se soucier des effets de bord que ça pourrait générer.Certaines permettent en plus de faire du retro engeniring et de reconstruire des applications entières très rapidement en RUBY; pour les rendre beaucoup plus performante, secure et très évolutive. Cette techno, dont certaine Franciase mérite d’être prise en compte...
Signaler un abusBonjour,
Signaler un abusen remarque liminaire : il s'agit de COBOL et non Cobol.
Sur le fond, en premier lieu, pourriez-vous citer le lien vers la source originale?
Ensuite, en soi, le coût de correction d'une ligne n'est pas vraiment représentatif ni de la qualité d'un programme, ni du coût même de sa maintenance, qui sont deux notions plutôt liées à la conception même d'un logiciel.
Comparer COBOL et Java et dire que COBOL est mieux fait parce que plus âgé est un peu comme comparer un moteur diesel 2 temps et un moteur Hybride nouvelle génération et dire que le moteur diesel 2 temps est mieux fait car plus âgé. Il est certain que le premier ne coûte pas cher à réparer, mais qui en veut aujourd'hui? Et cette comparaison a-t-elle un sens?
Une ligne de COBOL contient environ 6 fois moins d'information qu'une ligne Java (voir la verbosité des langages), il n'est donc pas étonnant que le coût même de correction soit plus élevé.
Ensuite, il serait intéressant de pouvoir comparer plutôt deux systèmes équivalents, en terme de périmètre fonctionnel, l'un écrit en COBOL et l'autre en Java.
Sans doute est-ce la synthèse qui éclipse certains points pourtant cruciaux de l'analyse, et la conclusion parait être inverse de ce que les faits en entreprise avèrent : on garde COBOL car on repousse souvent le passage à Java ou autre, mais ce faisant on laisse ouvert un gouffre financier en maintenance.
Cordialement,
Fabien Crépin