Tout le monde cite que “les bugs sont 100 fois plus chers à corriger dans la recherche en production”, mais l’étude pourrait même ne pas exister

« La recherche de logiciels est un véritable désastre », déclare Hillel Wayne, un consultant en logiciels basé à Chicago et spécialisé dans les méthodes formelles, illustrant l’idée reçue selon laquelle les bogues sont beaucoup plus coûteux à corriger une fois le logiciel déployé.

Wayne a fait quelques recherches, notant que “si vous Google” le coût d’un bogue logiciel “, vous obtiendrez des tonnes d’articles qui disent” les bogues trouvés dans les exigences sont 100 fois moins chers que les bogues trouvés dans les implémentations “. Ils utilisent tous ce tableau de l’IBM Systems Sciences Institute… Il y a un petit problème avec l’étude de l’IBM Systems Sciences Institute : elle n’existe pas.”

Laurent Bossavit, expert en méthodologie Agile et conseiller technique au cabinet de conseil en logiciels CodeWorks à Paris, a consacré du temps à ce sujet et a publié un article sur GitHub intitulé “Degrés de malhonnêteté intellectuelle”. Bossavit a fait référence à un livre à succès de 1987 de Roger S Pressman intitulé Génie logiciel : une approche de praticien, qui déclare : “Pour illustrer l’impact sur les coûts de la détection précoce des erreurs, nous considérons une série de coûts relatifs basés sur les données de coûts réelles collectées pour les grands projets logiciels [IBM81].”

La référence à [IBM81] note que les informations proviennent de “notes de cours” de l’IBM Systems Sciences Institute. Bossavit a découvert, cependant, que de nombreuses autres publications ont fait référence au livre de Pressman comme source faisant autorité pour cette recherche, masquant sa nature provisoire.

Bossavit a pris le temps d’enquêter sur l’existence de l’IBM Systems Science Institute, concluant qu’il s’agissait « d’un programme de formation interne pour les employés ». Aucune donnée n’était disponible pour étayer les chiffres du graphique, qui montre 100 fois le coût de la correction d’un bogue une fois le logiciel en maintenance. “Les données originales du projet, s’il en existe, ne sont pas plus récentes que 1981, et probablement plus anciennes ; et pourraient être aussi vieilles que 1967″, a déclaré Bossavit, qui a également décrit ” vouloir ramper dans un trou lorsque je rencontre des conneries déguisées en empiriques prise en charge d’une réclamation, telle que « les défauts coûtent plus cher à réparer plus vous les réparez tard » ».

Est-ce que les défauts logiciels coûtent plus cher à corriger, plus ils sont découverts tard ? “Je pense que le corpus de recherche jusqu’à présent pointe provisoirement dans cette direction, en fonction de la façon dont vous interprétez” stade avancé “,” bogues “et” plus cher “, a déclaré Wayne. “Certains bogues prennent plus de temps à être corrigés (et causent plus de dégâts) que d’autres, et ces bugs ont tendance à être des problèmes de conception.”

Voici un article de 2016 [PDF] dont les auteurs “ont examiné 171 projets logiciels menés entre 2006 et 2014”, qui ont tous utilisé une méthodologie appelée Team Software Process. Les chercheurs ont conclu que “les moments pour résoudre les problèmes à des moments différents n’étaient généralement pas significativement différents”.

Wayne est aussi préoccupé par l’état de la recherche sur les logiciels que par la question des défauts elle-même. Il a observé que des articles tels que celui cité ci-dessus « utilisent des définitions différentes du défaut », ce qui rend difficile de tirer des conclusions. Il a déclaré qu’il était un partisan du génie logiciel empirique (ESE), utilisant des preuves pour en savoir plus sur ce qui fonctionne dans le développement de logiciels, mais a déclaré que “les structures d’incitation académique ne sont pas alignées de manière à fournir des informations exploitables à l’industrie. pour créer de nouveaux modèles et introduire de nouvelles innovations que de faire le « gros travail » nécessaire qui serait le plus utile. »

Il a suggéré de se concentrer sur ce que “la recherche empirique montre de manière écrasante”, à savoir que “la revue de code est un bon moyen de trouver des bogues logiciels et de diffuser les connaissances logicielles. Cela montre également que des cycles d’itération plus courts et des boucles de rétroaction conduisent à un logiciel de meilleure qualité que de longs délais d’exécution. .”

Le rôle de “IBM Systems Sciences Institute” dans le renforcement de l’autorité de la recherche qui pourrait ne pas exister est un rappel de l’importance des sources primaires, qui peuvent être difficiles à découvrir dans la chambre d’écho d’Internet.

Juste au bon moment, dans notre boîte de réception a surgi un peu de “recherche” d’une agence de relations publiques concernant les revenus des cinq principaux fournisseurs de cloud, sur la base d’une “enquête Statista”. Cependant, Statista n’est pas avant tout une société de recherche. Au lieu de cela, il “consolide des données statistiques sur plus de 80 000 sujets provenant de plus de 22 500 sources”, selon sa propre description.

Les recherches mentionnées ne proviennent pas de Statista, mais de Cloud Wars. Citer Statista comme source revient à attribuer une déclaration découverte dans une recherche Google comme ayant l’autorité de Google. Le risque de confusion comme celle-ci est qu’une mauvaise source peut être promue à une meilleure (et cela ne vise pas à suggérer que les données de Cloud Wars sont inexactes). ®