Windows ConfidentialArbeiten Sie härter, nicht intelligenter

Raymond Chen

Für Softwareentwickler besteht einer der großen Vorteile der Windows-Fehlerberichterstattung darin, dass sie reale Informationen dazu erhalten, welche Fehler in ihren Programmen auftreten. Diese Fehlerberichte sind für jeden Softwarehersteller verfügbar, der sich online unter winqual.microsoft.com registriert. Natürlich können Sie alle Arten von Tests in Ihren Testumgebungen ausführen, aber es gibt immer eine Lücke zwischen den Bedingungen in der Testumgebung und den realen Bedingungen. Dies kann zu Fehlern führen, die bei Ihren Tests nie auftreten, aber Ihre Kunden zur Verzweiflung bringen.

Vor einigen Jahren hat mir ein Programmierer, dem vom für die Zuverlässigkeit zuständigen Team seines Produkts eine Aufgabe übertragen wurde, eine interessante Geschichte erzählt. Das Team wollte die wichtigsten Gründe für Abstürze und Blockaden in einer bestimmten Komponente beseitigen. Nach einigen Verhandlungen einigten sich beide Parteien auf das Ziel, die Anzahl dieser Arten von Fehlern um den Faktor 2 zu reduzieren. Sie wollten Fehler beheben, die laut Windows-Fehlerberichterstattung für mindestens 50 Prozent der Abstürze und Blockaden in dieser Komponente verantwortlich waren.

Wir wissen alle, dass Fehler nicht gleichmäßig verteilt sind. Einige sind selten, andere treten häufig auf und wieder andere sind allgegenwärtig (relativ betrachtet). Der Entwicklungsprozess ist von Kompromissen geprägt: Angesichts begrenzter Ressourcen (Zeit, Geld und Personal) müssen Sie Ihre Ressourcen an den Stellen einsetzen, an denen sie die größte Wirkung haben. Da das Ziel lautete, die Anzahl der Abstürze und Blockaden zu verringern, bestand ein vernünftiger Ansatz darin, die von der Windows-Fehlerberichterstattung am häufigsten gemeldeten Fehler zu untersuchen, die zugrunde liegenden Ursachen zu verstehen und dann zu versuchen, diese häufig auftretenden Fehler zu beheben.

Die Windows-Fehlerberichterstattung bietet reale Informationen zu Programmfehlern (zum Vergrößern auf das Bild klicken)

Als der Programmierer die Fehlerdaten analysierte, wurde klar, dass mehr als 60 Prozent der Berichte auf fünf speziellen Abstürzen und Blockaden beruhten. Wenn der Programmierer die Programmfehler beheben könnte, die diese fünf Fehler verursachten, würde er die Anzahl der Abstürze und Blockaden um den Faktor 2,5 – deutlich über dem Zielfaktor von 2 – reduzieren.

Microsofts eigene Analyse der Windows-Fehlerberichterstattungsdaten zeigt, dass das Pareto-Prinzip eine erstaunlich gute Faustregel für Windows-Abstürze und -Blockaden ist: etwa 20 Prozent der Bugs verursachen 80 Prozent der Fehler. Dieselbe Studie führte zu einem noch überraschenderen Ergebnis: Nur 1 Prozent der Bugs verursacht 50 Prozent der Fehler. Nicht alle Programmfehler sind gleich, aber es ist wirklich eine Überraschung, wie hochgradig schief die Verteilung ist.

Nach der eingehenderen Untersuchung dieser fünf Fehler erkannte der Programmierer, dass ihnen allen dieselbe Ursache zugrunde lag. Die Abstürze und Blockaden waren nur verschiedene Erscheinungsformen desselben zugrunde liegenden Fehlers. Daher entwickelte und testete er eine Problembehebung und leitete in Zusammenarbeit mit den Mitarbeitern der Qualitätssicherungsabteilung die Schritte für die Aufnahme der Problembehebung in den nächsten Patch ein. Mit dieser einen Programmfehlerbehebung sank die theoretische Fehlerrate für die Komponente augenblicklich um den Faktor 2,5. Er hatte seine Aufgabe mit einer ziemlich einfachen Codefehlerbehebung erfüllt.

Als ich diese Geschichte hörte, war ich überrascht, dass die Fehlerverteilungskurve für die Komponente sogar noch steiler war als für Windows. Deutlich mehr als die Hälfte aller Abstürze und Blockaden wurde durch einen einzigen Programmfehler verursacht. Diese Art von Einblick in Ihren Code ist ohne die Daten, die von einem Dienst wie der Windows-Fehlerberichterstattung gesammelt werden, nicht möglich.

Man sollte meinen, dass das Zuverlässigkeitsteam hocherfreut war, sein Ziel so schnell erreicht zu haben. Das vereinbarte Ziel wurde in nur zwei Wochen mit einer einzigen Problembehebung übertroffen. Stattdessen war man aufgebracht.

„Das ist nicht akzeptabel – wir haben erwartet, dass es zwei Monate dauert. Das war zu einfach!“ Offensichtlich sollte der Programmierer härter und nicht intelligenter arbeiten.

Raymond Chen befasst sich auf seiner Website „The Old New Thing“ und in seinem gleichnamigen Buch mit der Geschichte von Windows und mit der Win32-Programmierung. Zwanzig Prozent seiner Kleidungsstücke sind für achtzig Prozent seiner Schmutzwäsche verantwortlich.