La vie secrète de WindowsTravaillez plus dur, pas plus intelligemment

Raymond Chen

Pour les développeurs de logiciels, l'un des principaux avantages du programme Rapport d'erreurs Windows est qu'il leur permet d'obtenir des informations réelles sur les causes des défaillances de leurs programmes. Ces rapports d'erreur sont à la disposition de tout fournisseur de logiciels qui s'inscrit en ligne à winqual.microsoft.com. Bien sûr, vous pouvez exécuter toutes sortes de tests dans vos laboratoires, mais il existe toujours des différences entre les conditions de laboratoire et la réalité. Ainsi, certains bogues qui ne sont jamais détectés par vos tests peuvent rendre vos clients fous.

Il y a quelques années, un programmeur qui effectuait un travail pour le compte de l'équipe chargée de la fiabilité de son produit m'a raconté une histoire. L'équipe voulait résoudre les principales causes des incidents et pannes qui se produisaient dans un composant particulier. Après quelques négociations, les deux parties avaient convenu d'essayer de réduire le nombre de ces défaillances par un facteur de 2. L'objectif était de corriger les bogues responsables d'au moins 50 % des incidents et pannes dans le composant, tels qu'ils étaient mesurés par le programme Rapport d'erreurs Windows.

Nous savons tous que les pannes ne sont pas distribuées de manière uniforme. Certaines sont rares, d'autres courantes, et d'autres encore sont endémiques (relativement parlant). L'ingénierie est un jeu de compromis ; vous considérez vos ressources (temps, argent et ressources intellectuelles) et les injectez là où elles auront le plus grand effet. Puisque l'objectif, dans ce cas, était de réduire le nombre d'incidents et de pannes, il était raisonnable d'étudier les problèmes les plus fréquemment signalés par le programme Rapport d'erreurs Windows, d'en comprendre les causes et d'essayer ensuite de les résoudre.

fig00.gif

Le Rapport d'erreurs Windows fournit des informations réelles sur les défaillances des programmes (cliquez sur l'image pour l'agrandir)

Lorsque le programmeur a examiné les données liées aux pannes, il s'est avéré que plus de 60 % des rapports étaient consacrés à cinq incidents et pannes particuliers. Si le programmeur arrivait à corriger les bogues qui causaient ces cinq défaillances, il réduirait le nombre d'incidents et de pannes par un facteur de 2,5, bien au-delà du facteur cible original qui était de 2.

L'analyse par Microsoft des données du Rapport d'erreurs Windows montre que le principe de Pareto est remarquablement approprié dans le cas des incidents et pannes de Windows : 80 % des défaillances sont causées par environ 20 % des bogues. La même étude a révélé un résultat encore plus étonnant : 50 % des erreurs sont causées par seulement 1 % des bogues. Les bogues ne sont pas tous égaux bien entendu, mais une telle inégalité dans leur distribution est surprenante.

Après avoir étudié ces cinq défaillances un peu plus en détail, le programmeur s'est rendu compte que toutes avaient la même cause. Les incidents et pannes n'étaient que des manifestations différentes d'un même bogue. Il a donc développé et testé un correctif et, en collaboration avec le personnel de l'assurance qualité, l'a inclus dans le jeu de correctifs suivant. Avec ce seul correctif, le taux de défaillance théorique du composant a immédiatement diminué d'un facteur de 2,5. Il a accompli sa mission d'un seul... code !

Ce qui m'a surpris dans cette histoire, c'est que la courbe de distribution d'erreurs pour le composant était encore plus prononcée que pour Windows. Plus de la moitié de tous les incidents et pannes étaient causés par un seul bogue. Une telle compréhension de votre code n'est pas possible sans les données recueillies par un programme tel que le Rapport d'erreurs Windows.

Vous penseriez que les membres de l'équipe chargée de la fiabilité des produits étaient aux anges lorsqu'ils ont appris que leur objectif avait été atteint aussi rapidement. En effet, l'objectif convenu avait été dépassé en seulement deux semaines, avec un seul correctif. Eh bien, non ! Ils étaient furieux !

« C'est inacceptable ! Ca devait prendre deux mois ! C'était trop facile ! » Apparemment, ils voulaient que le programmeur travaille plus dur, et pas plus intelligemment.

Le site Web de Raymond Chen, The Old New Thing, et son livre du même titre traitent de l’historique de Windows et de la programmation Win32. 20 % de ses vêtements sont responsables de 80 % de sa lessive !