Discussion :

[Michael Guilloux]

ClusterHQ : 43 % des développeurs passent entre 10 et 25 % de leur temps à déboguer des erreurs
détectées dans des applications en production

ClusterHQ a mené une enquête qui a permis de révéler que 43 % des développeurs d'applications passent entre 10 et 25 % de leur temps à déboguer des erreurs découvertes dans les applications en production. Il s’agit donc d’une bonne partie de leur temps perdue qui aurait pu servir à développer de nouvelles fonctionnalités pour les utilisateurs.

Cette enquête de ClusterHQ a enregistré la participation de 386 professionnels de l’IT, dont des membres d’équipes DevOps (41 %), des développeurs (37 %), des ingénieurs assurance qualité (QA : 5 %) ou encore des professionnels de la sécurité informatique (2 %), entre autres.

La majorité des personnes interrogées a affirmé que la production est l’environnement où la correction de bugs s’avère la plus coûteuse. Au cours de l’enquête, 62 % des répondants ont en effet choisi la production comme l'étape la plus coûteuse pour corriger les erreurs. Ensuite viennent la phase de développement (18 %), la pré-production (7 %), l’étape de contrôle qualité (7 %) et la phase des tests (6 %).

Il a ensuite été demandé aux répondants la fréquence à laquelle des bugs sont rencontrés en production. À cette question, 11 % ont répondu qu’ils rencontrent des bugs en production tous les jours, alors que 13 % disent en rencontrer deux à trois fois par semaine. Autrement dit, près d’un quart (24 %) des répondants rencontrent des bugs en production plusieurs fois dans la semaine.

On note encore que 12 % de ceux qui ont été interrogés rencontrent un bug en production en moyenne une fois par semaine, ce qui porte à un tiers (36 %), le nombre de développeurs qui rencontrent un bug en production au moins une fois dans la semaine.

Avec la fréquence des bugs rencontrés, ClusterHQ s’est également intéressé au temps que les développeurs consacrent au débogage des erreurs découvertes dans les applications en production. Ici, 34 % des personnes interrogées ont répondu qu’ils y consacrent moins de 10 % de leur temps, alors que 43 % disent passer entre 10 et 25 % de leur temps à déboguer les erreurs dans les applications en production.

Dans un effort pour découvrir pourquoi les bugs dans la production sont si courants, les personnes interrogées ont été également invitées à identifier les causes les plus courantes. D’après les résultats, l’incapacité à recréer parfaitement les environnements de production lors des tests était la principale cause des bugs découverts en production avec 33 %. Ensuite viennent les causes suivantes :

• l’interdépendance avec les systèmes externes, rendant les tests d'intégration difficiles : 27 % ;
• tester avec des données irréalistes avant de passer à la production : 26 % ;
• la difficulté à partager les données de tests entre différentes équipes : 10 % ;
• la difficulté à créer des environnements de pré production pour le test : 4 %.

Commentant les derniers résultats, ClusterHQ explique que le fait que recréer des environnements de production a été cité comme la principale cause de bugs apparaissant en production montre que faire « les tests sur un ordinateur portable est comme ‘‘voler’’ dans un simulateur de vol - l'expérience peut être très différente lorsque vous vous élevez dans les hauteurs », explique la société, qui justifie également la deuxième place de l'interdépendance avec les systèmes externes par le fait que cela rend les tests d’intégration plus lourds.

Source : ClusterHQ, Market Wired

Et vous ?

Que pensez-vous de ces résultats ?
Dans quel environnement rencontrez-vous les bugs les plus coûteux à corriger ?
Quelle est la fréquence à laquelle vous rencontrez des bugs dans des applications en production ? Quelles en sont les causes ?
Pensez-vous que vous passez trop de temps à déboguer ces erreurs ?

[el_slapper]

Je suis surpris de la faiblesse de ces chiffres. Les bugs de production sont légion pour tout un tas de raison, qui n'ont pas toutes de coupables. Bon, certaines en ont(J.S.C., si tu nous lis, tu aurais pu tester au moins une fois ta correction du nombre de factures par jour, qui n'a jamais marché).

Pour le reste, euh, le ciel est bleu, mais il est bon de le rappeler à certains.

[Luckyluke34]

J'aurais tendance à dire que plus on s'éloigne de la phase de dev, plus les bugs sont longs à réparer puisqu'il faut que le développeur se remette dans le contexte en question, éventuellement se remonte un environnement pour débugger, relivre, etc.

Après, je n'ai jamais remarqué de pattern dans la complexité de résolution intrinsèque des bugs selon leur environnement de détection.

[abriotde]

Certes les bug en productions coûtent plus cher à corrigé mais surtout peuvent provoquer d'autres coûts. Et ce sont ces autres coûts qui déterminent de l'importance de les détecter avant la mise en productions. Si l'on peux se permettre de mettre en production (ou preprod) une solutions pas trop tester (pour un environnements peu critique), on fait de sérieuses économies. Et ce car les bugs sont beaucoup plus visible sur le terrain et surtout une applications est en pratique évolutive. La livrer non-fini permet de l'adapter facilement aux besoin qui apparaissent sur le terrain.

Et il est là le chalenge, livré fini ou presque livré évolutif. Plus l'environnement est critique et pus le processus de mise en prod est complexe et plus l'on doit tester mais moins on sera évolutifs. Je ne suis pas en train de me faire l'avocat du travail baclé mais l'avocat du compromis afin de ne pas tomber dans les raccourcis "Tester toujours plus pour faire du travail propre".

Un logiciel est comme un maison ou un jardin. On veux bien faire mais ce n'est jamais fini cela évolue sans cesse. Il y a un moment ou il faut en profiter même si tout n'est pas parfait.

[martopioche]

Rien d'étonnant en soi, pour peu qu'on s'intéresse un peu à la qualité (oui je sais, c'est pas le lieu…*:p ). Paradoxalement, c'est peut-être justement en ayant une politique qualité qu'on risque de voir ce schéma là. C'est quand même une certaine culture de mener un projet destiné à la mise en prod' et non à l'AQ…

[marsupial]

Après, je n'ai jamais remarqué de pattern dans la complexité de résolution intrinsèque des bugs selon leur environnement de détection.

Je ne sais si je vais réussir à faire passer mon avis sur la question car cela demande un changement complet de mentalité dans la manière d'aborder la réalisation d'un projet.
La philosophie habituelle et classique a toujours été de réaliser le cahier des charges puis de traiter les erreurs. C'est-à-dire :

try

le code qui fonctionne

catch

les erreurs


Alors que vue de la sécurité, la problématique est de traiter tous les bogues sans exception. C'est-à-dire :

try

les erreurs

catch

le code qui fonctionne


Cela reste un avis à moduler suivant les contraintes de rendement, restant conscient du besoin de productivité et de fournir un code fonctionnel et optimisé. Cela demande une évidente maîtrise de la technologie utilisée dans l'environnement donné. Donc un degré d'expertise élevé.

edit : moralité, choisir une technologie open source et documentée permet d'accéder plus facilement au degré d'expertise nécessaire.

[wolinn]

Un logiciel contrôlant des aiguillages ferroviaires n'a pas tout à fait les mêmes contraintes qu'un logiciel grand public de retouche de photos...
On ne sait même pas de quel type de logiciel parle cette étude. Si les sondés représentent tous les secteurs d'activités et des logiciels absolument pas comparables, la valeur informative de l'étude ne me parait pas évidente.

[marsupial]

Un logiciel contrôlant des aiguillages ferroviaires n'a pas tout à fait les mêmes contraintes qu'un logiciel grand public de retouche de photos...

+1 car très bon exemple de besoin à comparer.

[ManusDei]

En général je perd un temps fou à corriger les bugs en prod, mais c'est parce que le client me donne que la moitié du contexte d'exécution.
Donc je passe beaucoup de temps à chercher, expliquer qu'il me manque des infos, récupérer un bout des infos qui manquent, et on recommence.

[Jitou]

Le plus souvent le développeur qui a développé la fonction fautive n'est plus dans l'entreprise depuis plusieurs mois (la prestation n'a pas que du bon ... :o)) donc il faut pour l'équipe de TMA beaucoup de temps pour comprendre quelle était le besoin métier et ce qu'à voulu faire le développeur pour y répondre. Ensuite lorsque tout se passe bien il faut encore du temps pour trouver une solution qui ne va pas mettre en péril d'autres fonctionnalités qui ne présentent pas de pb de fonctionnement (du moins pas encore !). Bon en réalité comme personne ne comprend ce que fait l'équipe technique en mesure de résoudre le pb, celle ci fait ce qu'elle peut avec les connaissances et les moyens du bord.