Nützliches Scheitern: IT-News kritisch lesen, Teil 2

Einleitung

Willkommen zum zweiten Teil unserer dreiteiligen Auseinandersetzung damit, wie man IT-News kritisch liest. Für alle, die erst jetzt dazustoßen: In Teil 1 ging es um verschiedene Formen illusorischen Erfolgs, die sich großartig lesen und trotzdem nichts zu den Problemen deiner Projekte beitragen. Konkret um Selection Bias, Regression zur Mitte (Coach’s Fallacy, jemand?) und das zu klein bemessene Sampling-Fenster.

Den berühmten Survivorship Bias habe ich dort nur angerissen und eine ausführlichere Diskussion versprochen. Die zusätzliche Zeit war mir das wert, weil dahinter ein größeres Bild steht: Die Fixierung auf Erfolg begrenzt, was wir lernen könnten. Es gibt eine psychologische Vorliebe für Erfolg, und die lohnt sich auseinanderzunehmen. Darum geht es hier.

Survivorship Bias

Im Wikipedia-Artikel zum Survivorship Bias steckt eine hervorragende Illustration. Hervorragend deshalb, weil sie gleichzeitig eindrücklich und manipulativ ist. Wer sich dieses Bild anschaut, macht den Survivorship Bias an sich selbst durch.

Zeichnung: Martin Grandjean (Vektor), McGeddon (Bild), US Air Force (Konzept des Trefferplots), Own work, CC BY-SA 4.0, File:Survivorship-bias.svg

Der Kontext ist der Zweite Weltkrieg, genauer die Frage, welche Teile eines Flugzeugs verstärkt werden mussten, damit die Bomberbesatzungen sicherer sind. Verstärkung kostet Gewicht, deshalb ist das ein kniffliges Problem.

Das Rot, das ein bisschen wie Blut ausschaut, obwohl Flugzeuge nicht bluten, zieht den Blick sofort auf die Stellen, an denen die Flak getroffen hat. Das Bild sammelt alle bekannten Schadensbereiche. Als Engineer ist mein erster Impuls: “Genau die Teile müssen wir verstärken!”

Der Witz am Survivorship Bias ist natürlich, dass Flugzeuge, die getroffen wurden und es zurück zur Analyse geschafft haben, ein irreführendes Bild von den Schwachstellen liefern. Flugzeuge, die in den weißen Bereichen getroffen wurden, sind nicht zurückgekommen und fehlen deshalb in der Stichprobe. Auch wenn das Rot nach Aufmerksamkeit schreit, brauchen die ungepunkteten Teile die Verstärkung am dringendsten. Das ist der Survivorship Bias auf den Punkt gebracht.

Abraham Wald, der Statistiker, dessen Arbeit von 1943 dahintersteht, wusste das. Wald gehörte während des Zweiten Weltkriegs zur Statistical Research Group an der Columbia University. Bemerkt hat er den Survivorship Bias nicht als Erster. Sein Beitrag waren statistische Schätzer, die die Verzerrung in der Stichprobe ausgleichen. Damit konnten die Verantwortlichen berechnen, wo sie ihr kostbares Verstärkungsgewicht einsetzen sollten. Unten ein Screenshot aus Walds Bericht A Method of Estimating Plane Vulnerability based on Damage of Survivors, S. 65, in der Nachdruckfassung aus den 1980ern. Während der Kriegsjahre war der Bericht als geheim eingestuft.

Kurz gesagt: Wald hat die Verteilung der Ausfälle rekonstruiert, weil die Ausfälle das Aufschlussreichste waren.

Die Vorliebe für Erfolg

Für die Konzentration auf Erfolg statt auf Scheitern gibt es zwei gängige Begründungen.

Die pragmatische: Wir sind Engineers und müssen Dinge fertig bekommen. Ein Scheitern warnt zwar davor, was man meiden sollte, sagt aber wenig darüber, was man stattdessen tun soll. Also halten wir es für Best Practice, Listen von Best Practices zu führen. Dabei geht die Lehre unter, die seit 1943 bei Wald steht: Auch eine rekonstruierte Ausfallverteilung sagt dir klar, was als Nächstes zu tun ist.

Die zweite: Scheitern kann aus einer ganzen Reihe von Ursachen kommen. Oder wie es bei Leo Tolstoi im berühmten Anfangssatz von Anna Karenina heißt: “Alle glücklichen Familien gleichen einander, jede unglückliche Familie ist auf ihre eigene Weise unglücklich.”

Seit dem letzten Post über das kritische Lesen von IT-News argumentiere ich, dass das zu einfach ist. Erfolg ist genauso kompliziert wie Scheitern und hat genauso viele Ursachen. Manche davon sind so spezifisch, dass sich der Erfolg nicht zur Best Practice erheben lässt, siehe den Dream-Team-Selection-Bias. Weil uns Erfolg interessiert, der unser eigenes Handeln leiten kann, müssen wir die Unterscheidung Erfolg und Scheitern mit einer zweiten Achse kreuzen: aufschlussreich oder nicht.

Aufschlussreicher Erfolg treibt Best Practices an und lädt zur Nachahmung ein. Erfolg, den wir nicht replizieren können, weil die Belege zu dünn sind oder die Voraussetzungen nicht passen, ist nicht aufschlussreich. Das war das Argument aus Teil 1.

Zugegeben, Scheitern ist oft genauso wenig aufschlussreich wie nicht replizierbarer Erfolg. Aber es gibt eine Kategorie aufschlussreichen Scheiterns, die sich aufzuspüren lohnt.

Anti-Patterns und Post-Mortems

Als Branche ist Software Engineering besser darin geworden, Fehlererfahrung zu organisieren. Die Pattern-Bewegung der 1980er hat auch die Gegenbewegung hervorgebracht, nämlich Anti-Patterns zu sammeln. Also alles gut? Nicht ganz. Anti-Patterns sind ein gutes Lehrmittel, und es ist sinnvoll, Patterns und Anti-Patterns zusammen zu lernen, weil sie einander erklären.

Nur hat dieser Lehrmittel-Charakter eine soziale Nebenwirkung: Wer ein Anti-Pattern anwendet, schaut aus wie ein Anfänger. Es ist die Sorte Hinweis, die der erfahrene Engineer dem Sommer-Intern gibt. Es ist schon schwer genug, Leute über Fehler reden zu lassen, und jetzt sollen sie auch noch zugeben, dass sie ein Anti-Pattern verwendet haben. Außerdem kennen wir das doch alles schon. Wir haben ihm sogar einen Namen gegeben.

Und Post-Mortems? Sind die nicht genau das aufschlussreiche Fehlerreporting, für das ich hier plädiere? Teilweise. Es gibt Post-Mortems, die veröffentlicht werden, damit die Branche etwas daraus lernt. Fred Brooks’ Klassiker The Mythical Man Month gehört in diese Kategorie, und genau deshalb wird er in Software-Engineering-Kursen immer noch gelesen, obwohl die beschriebenen Ereignisse über fünfzig Jahre zurückliegen.

Die Sorte Post-Mortem dagegen, die herauskommt, wenn ein großer Softwareanbieter beinahe die Welt zum Stillstand gebracht hat, ist absichtlich nicht aufschlussreich. Viele davon sind Übungen in Schadensbegrenzung. Ihr Zweck ist, die Branche und die Öffentlichkeit zu beruhigen, dass es sich um einen Edge Case unter einer Million gehandelt hat. Frei nach Tolstoi: Das Post-Mortem will uns überzeugen, dass dieses Problem auf seine ganz, ganz eigene Weise unglücklich war.

Und ehrlicherweise ist nützliche Forschung wie die Analyse des jüngsten ChainDrop-Supply-Chain-Angriffs auch eine Erfolgsgeschichte, nämlich die des Security Labs, das sie veröffentlicht. Damit hängt sie an allen Komplikationen von Erfolgsgeschichten, über die wir seit zwei Posts nachdenken.

Ein Blick über den Zaun

As a community, we have come to value findings that are novel and eye-catching over those that are true, incentivising a host of questionable practices that twist the evidence to suit the narrative. -Chris Chambers, 2013

Zum Glück ist die IT nicht das einzige Feld, dem dokumentiertes, aufschlussreiches Scheitern fehlt. Ein Blick zu den Nachbarn liefert also durchaus ein paar Ideen.

Überraschend ist das nicht. Erfolg als Kriterium für den eigenen Aufstieg ist in Wissenschaft und Technik gleichermaßen verbreitet. Weil die Belohnungsstrukturen in der Wissenschaft Richtung “publish or perish” verzerrt sind, schafft es schon der bloße Anschein von Erfolg in die Literatur. John Ioannidis hat 2005 in seinem vieldiskutierten Essay Why Most Published Research Findings Are False genau wegen dieses Trends in der Medizin Alarm geschlagen.

In der Psychologie hat Theodore Sterling seinen empirischen Übersichtsartikel von 1959 (cf JASA 54(285):30) mit einer Beobachtung eingeleitet, aus der sich bequem ein Gedankenexperiment bauen lässt. Nimm eine ansprechende Forschungsfrage, deren wahre Antwort null ist. Wer das Experiment durchführt, wird es mit diesem Ergebnis vermutlich nicht veröffentlichen. Es gibt also weder einen positiven Befund noch einen Hinweis auf die gescheiterten Versuche, und damit nichts, was die Stelle markiert. Regelmäßig stolpert der nächste Wissenschaftler in dasselbe Zeitgrab und probiert es noch einmal. Irgendwann rutscht das Experiment wegen Fehlerbalken, kleiner Stichprobe oder schlichtem Zufall in eine scheinbare Signifikanz, einen Type-I-Fehler. Jetzt wird es endlich veröffentlicht und wandert in die allgemeine Mythologie, womöglich um den Preis von sehr viel vergeudeter Mühe in der ganzen Forschungsgemeinschaft.

Gut fünfzig Jahre später hatte sich daran wenig gebessert. Chris Chambers kam 2013 zu dem Schluss, dass die Wurzel des Übels “schlicht die Tatsache, dass redaktionelle Entscheidungen oft auf den Ergebnissen beruhen” sei. Genau daraus entstehen das Verbiegen von Evidenz, p-Hacking und selektives Berichten. Chambers hat außerdem über die absurde Ausbildung angehender Forscher gespottet: Als Undergraduates müssen sie zuerst ihre Theorien aufstellen. Als Graduates und Post-Graduates, wenn Publizieren plötzlich zählt, besteht die Forschungspraxis darin, Theorien nachträglich aus gesammelten Fakten zurückzugewinnen.

Bei der Fachzeitschrift Cortex, in deren Redaktionsteam Chambers sitzt, hat man daraufhin einen Vorregistrierungsprozess für das Studiendesign eingeführt, die Registered Reports. Chambers’ Argument: Experimente sollten aufgrund ihres Designs angenommen werden und nicht aufgrund ihrer Ergebnisse. Wenn ein Studienvorschlag methodisch valide ist, detailliert und replizierbar, und wenn er eine wichtige wissenschaftliche Frage behandelt, dann verdient er die Veröffentlichung, ganz gleich wie das Ergebnis ausfällt.

Denn wenn ein hochwertiges Design keinen Effekt zeigt, ist genau das aufschlussreiches Scheitern.

Transfer Learning

Wie viele Softwarefirmen hat Posedio eine strenge Methodik, die das Gute und das Schlechte gleichermaßen mitschreibt. Jede Iteration im Deming-Shewhart-Zyklus aus Plan, Do, Check, Act hält fest, was gut lief, was nicht und was sich verbessern ließe. Das Design entsteht vorab und wird anschließend gegen die Implementierung geprüft, was beide Seiten besser macht.

Auf eine Forschungsregistrierung im Stil der Registered Reports läuft das in unserer Branche trotzdem nicht hinaus. Die Teile wären alle da, aber die Erkenntnisse aus PDCA bleiben intern. Aus der Introspektion wird kein Know-how, das sich über Firmengrenzen hinweg teilen lässt. Es gibt kein Register und kein Repository für die aufschlussreichen Fehlschläge. Diese Stellen auf der Architekturkarte der Branche bleiben weiß. Scheinbar unerforscht.

Der Grund ist oft rechtlich und nicht nur kulturell. Uns gehört der Rechenkontext nicht, auch nicht Netzwerk, Stack, Hardware oder Konfigurationen, und die Daten, die darauf laufen, erst recht nicht. Unsere Aufgabe ist, Dinge innerhalb der Setups zum Laufen zu bringen, die unsere Kunden gebaut haben. Dieses Setup ist Teil ihres IP, steht unter ihrer Kontrolle und drückt ihre Vision aus. Ohne diese Konstruktion ist jedes Software-System-Design unterspezifiziert.

Nur setzt uns diese berechtigte Sorge um IP und Wettbewerbsvorteil genau der Falle aus, die Sterling beschrieben hat: Jeder für sich von einer vielversprechend wirkenden Architektur angelockt, probieren und scheitern wir gemeinsam, wieder und wieder, weil niemand über den Schmerz reden darf.

Ausblick

Jeder Projektmanager sucht die eine Softwarekomponente, das eine Datenmanagementsystem, den einen Algorithmus, der den Stolperstein wegräumt und das Projekt freisetzt. Auf der Suche nach diesem fehlenden Glied wühlen wir uns durch Geschichten von Erfolg und Empfehlung.

Im ersten Teil habe ich argumentiert, dass Erfolg komplizierter ist. Manche Geschichten sind nicht aufschlussreich, sie übertragen sich nicht, sie skalieren nicht, sie haben nicht gezeigt, was sie zeigen wollten. Biases. Fata Morganas. Sampling-Fenster. Red Flags.

Diesmal haben wir uns in die Fehlschläge gegraben und die aufschlussreichen Fälle wieder herausgezogen. Abraham Wald hat uns daran erinnert, dass wir die vollständige Verteilung brauchen. Der Blick auf Anti-Patterns und Post-Mortems zeigt, dass wir gut gestartet sind und trotzdem noch ein Stück Weg vor uns haben. Und die Nachbarn in Medizin und Psychologie haben uns gewarnt: Über Scheitern zu reden braucht Infrastruktur, Konventionen und Orte, an denen das Benennen und Teilen überhaupt möglich ist. PDCA bringt der Branche nichts, solange die Erkundungen hinter einer Firewall liegen.

Das war eine anstrengende Wanderung, danke fürs Durchhalten. Aber wir sind Engineers, wir arbeiten, indem wir Vor- und Nachteile gegeneinander abwägen. Dieser Balanceakt geht nur mit einem vollständigen Bild von Erfolg und Scheitern, von aufschlussreich und nicht aufschlussreich.

Also mache ich mich an Teil 3. Dort schauen wir uns ein paar Erfolgsgeschichten aus der freien Wildbahn an, bringen alles zusammen und machen es konkret.

Und falls du enttäuscht bist, dass ich dir keine fertige Lösung verkauft habe: Lies den Beitrag noch einmal 😉

PS: Wen eine Analyse von Abraham Walds Schätzarbeit interessiert, dem sei die oft zitierte Erläuterung von Marc Mangel und Francisco Samaniego empfohlen, Abraham Wald’s Work on Aircraft Survivability, Juni 1984, Journal of the American Statistical Association 79(386):259-267. Eine Kopie des PDF liegt auf ResearchGate.

Anhang

Bewusste Auslassungen

Hier Informationen, die ich weggelassen habe, weil sie vom Gesamtargument ablenken. Für die Gesamtgestalt der Diskussion sind sie aber durchaus relevant.

Wie sein Vorbild Ronald Fisher hat Theodore Sterling ab Mitte der 1960er für die Tabakkonzerne als Sachverständiger gearbeitet und die wachsende Evidenz zu Tabakkonsum und Gesundheitsrisiken heruntergespielt. Ende der 1980er flog auf, dass er von der Tabakindustrie bezahlt wurde, und als Zeuge in der Tabakdebatte wurde er danach nicht mehr ernst genommen. Sein Paper von 1959, das wir hier zitieren, entwertet das nicht.

Die Registered-Reports-Initiative von 2013 hat die psychologische Forschung in der westlichen Tradition grundlegend umgestellt. Als Chris Chambers 2017 seine Forschungskritik The Seven Deadly Sins of Psychology, [Google Books], schrieb, boten bereits 40 Zeitschriften Registered Reports an. Bis zur Taschenbuchausgabe 2019 waren es 150. Aus dem Vorschlag ist also eine Bewegung geworden.