Die Softwarebranche liebt es, von „neuen Herausforderungen“ zu sprechen. Seien es Cloud-native Architekturen, Microservices, Machine Learning oder Edge Computing: Jede Technologiewelle bringt ihre eigenen Buzzwords und vermeintlich einzigartige Probleme mit sich. Doch wer die großen Softwarekatastrophen der letzten Jahrzehnte studiert, erkennt schnell: Deren Muster sind zeitlos.

Teil 10: Von Wiederholungstätern zu lernenden Organisationen: Wie die Softwarebranche ihre Lektion lernt

Der Mars Climate Orbiter verglühte 1999, weil Einheiten verwechselt wurden. Die Ariane 5 explodierte 1996 wegen eines Überlaufs. Knight Capital verlor 2012 440 Millionen Dollar durch einen fehlerhaften Deployment-Prozess. Der Therac-25 tötete in den 1980er-Jahren Menschen durch Race Conditions. Diese Vorfälle liegen Jahrzehnte auseinander, stammen aus völlig unterschiedlichen Domänen und basieren doch auf denselben fundamentalen Fehlern.

Das wirft eine unbequeme Frage auf: Wenn wir die Ursachen kennen, die Lösungen dokumentiert sind und die Werkzeuge existieren, warum passieren diese Fehler dann immer noch? Die Antwort ist ernüchternd: Weil technisches Wissen allein nicht ausreicht. Die Wiederholung bekannter Fehler ist kein technisches, sondern ein organisatorisches und kulturelles Problem.

Die Illusion der technischen Lösung

Nach jedem spektakulären Softwarevorfall folgt dasselbe Ritual: Analysen werden geschrieben, Lessons-Learned dokumentiert, neue Tools entwickelt. Nach Heartbleed gab es bessere Fuzzing-Tools. Nach Knight Capital wurde über Deployment-Automatisierung diskutiert. Nach dem Mars Climate Orbiter sprach man über Typsysteme und Einheiten-Bibliotheken. All diese technischen Verbesserungen sind wertvoll und notwendig. Doch sie fokussieren stets nur auf die Symptome, behandeln allerdings nicht die Ursache:

• Die Ariane 5 hatte Tests, sie deckten nur nicht die relevanten Szenarien ab.
• Knight Capital hatte Deployment-Prozesse, sie wurden unter Zeitdruck nur nicht befolgt.
• Der Therac-25 galt als modernes, softwaregesteuertes System, und genau das wurde zum Problem, weil Hardware-Interlocks eingespart wurden.

Die technische Ebene ist zweifellos die einfachste. Moderne Programmiersprachen bieten starke Typsysteme, die Einheitenfehler zur Compile-Zeit erkennen. Linter und statische Analysetools finden potenzielle Null-Pointer-Exceptions, bevor der Code läuft. Property-based-Testing deckt Grenzwertprobleme auf. Fuzzing findet Memory-Corruption-Bugs. All diese Werkzeuge sind mächtig – aber nur, wenn sie auch eingesetzt werden. Und genau hier beginnt das eigentliche Problem: die organisatorische Ebene.

Jedes Softwareteam kennt die gut gemeinten Prozesse. Code-Reviews, bei denen mindestens zwei Entwicklerinnen oder Entwickler draufschauen. Pair-Programming für kritische Codepfade. Ausführliche Testabdeckung, Blameless-Postmortems nach jedem Vorfall, Feature-Flags mit dokumentiertem Lifecycle, Deployment-Pipelines mit automatischen Rollback-Mechanismen und so weiter. All das sind bewährte Praktiken: Sie stehen in unzähligen Best-Practice-Guides, werden auf Konferenzen besprochen und in zahlreichen Stellenausschreibungen gefordert. Doch wenn der Termin näherrückt, der Kunde drängt oder der Wettbewerber schneller ist, sind genau diese Prozesse das erste Opfer.

„Wir reviewen das später“ wird zu „Wir haben es nie reviewed“. „Das testen wir noch ausführlich“ wird zu „Hat im Happy-Path funktioniert“. „Wir dokumentieren das Feature-Flag“ wird zu „Irgendwo steht bestimmt was dazu“. Dieser Mechanismus ist so vorhersagbar, dass er fast schon ein Naturgesetz der Softwareentwicklung ist: Nicht technisch erzwungene Prozesse erodieren unter Zeitdruck. Das Knight-Capital-Desaster ist dafür ein Paradebeispiel. Das Unternehmen hatte Prozesse für Deployments. Doch als es das neue Release ausrollte, blieb ein Server zurück. Ein einzelner vergessener Server mit einem alten Feature-Flag – und 45 Minuten später waren 440 Millionen Dollar vernichtet. Die Ursache war nicht fehlendes Wissen, sondern fehlende Disziplin in der Ausführung.

Hier zeigt sich ein grundlegendes Muster: Organisationen, die Qualitätssicherung als nice to have behandeln, weil sie vermeintlich zu teuer ist, bezahlen den Preis dennoch – nur später und dafür meist deutlich teurer. Um dem entgegenzuwirken, ist Automatisierung der Schlüssel. Was technisch erzwungen wird, kann nicht vergessen werden. Was hingegen von Hand geprüft werden muss, wird früher oder später übersehen oder vergessen. Das bedeutet zum Beispiel:

• Atomare Deployments, bei denen entweder alle Server aktualisiert werden oder keiner.
• Compiler, die Code ohne explizite Null-Behandlung ablehnen.
• CI/CD-Pipelines, die bei fehlenden Tests den Build abbrechen.
• Typsysteme, die Einheiten überprüfen.

Diese Mechanismen sind keine Schikane, sondern Lebensversicherungen für Software. Doch selbst die beste Automatisierung hilft nichts, wenn die dritte Ebene fehlt: die kulturelle – also die Art, wie eine Organisation mit Fehlern umgeht.

Die unterschätzte Dimension: Fehlerkultur und psychologische Sicherheit

Die technische und prozessuale Ebene lässt sich vergleichsweise einfach messen und verbessern. Doch die kulturelle Ebene ist subtiler und gleichzeitig entscheidender. In vielen Organisationen herrscht noch immer eine Kultur der Schuldzuweisung. Wenn etwas schiefgeht, wird nach dem Schuldigen gesucht. „Wer hat das deployed?“, „Wer hat das reviewed?“ oder „Wer hätte das sehen müssen?“. Diese Fragen sind menschlich verständlich, aber nicht zielführend, sondern kontraproduktiv.

Der Grund dafür ist einfach: Wenn Fehler mit Konsequenzen für Einzelne verbunden sind, werden sie verschleiert statt offen besprochen. Entwicklerinnen und Entwickler trauen sich nicht mehr, Bedenken zu äußern. Code-Reviews werden oberflächlicher, weil niemand als Bremser gelten will. Probleme werden vertuscht, bis sie eskalieren. Die Alternative sind Blameless Postmortems: Eine Praxis, die aus der Kultur des Site-Reliability-Engineering kommt. Die Grundidee ist, dass nach einem Vorfall nicht nach Schuldigen gesucht wird, sondern nach Systemschwächen. Also nicht „Wer hat den Fehler gemacht?“, sondern „Welche Umstände haben dazu geführt, dass dieser Fehler möglich war?“

Diese Haltung klingt weich, ist aber knallhart pragmatisch. Denn die Wahrheit ist: Fast jeder schwerwiegende Softwarefehler ist ein System- und kein individuelles Versagen. Wenn ein einzelner Developer einen Bug einbaut, ein Reviewer ihn übersehen, ein Test ihn nicht finden und ein Deployment ihn in Produktion bringen kann, dann ist das Problem das System, nicht der Mensch. Der Therac-25 ist dafür ein erschütterndes Beispiel. Die Race Condition, die Menschen tötete, war subtil und schwer zu reproduzieren. Sie trat nur auf, wenn Anwender sehr schnell Eingaben tätigten. Wäre es fair, den Entwicklern vorzuwerfen, sie hätten diesen Spezialfall testen müssen? Oder ist es nicht vielmehr ein Versagen des Designs, das sicherheitskritische Hardware-Interlocks durch Software-Checks ersetzt, ohne formale Verifikation, ohne unabhängiges Audit, ohne redundante Sicherungsebene?

Organisationen mit guter Fehlerkultur dokumentieren ihre Vorfälle detailliert, machen sie dem gesamten Team zugänglich und leiten konkrete Verbesserungen ab. Sie feiern es, wenn jemand einen potenziellen Fehler frühzeitig meldet. Sie reservieren explizit Zeit für technische Schulden und Refactoring. Sie nehmen Warnungen von Expertinnen und Experten ernst, auch wenn diese unbequem sind. In der griechischen Mythologie gab es Kassandra, die stets die Wahrheit sah, der aber niemand glaubte. Jede Organisation hat ihre Kassandras: Entwicklerinnen und Entwickler, die vor Risiken warnen, die auf technische Schulden hinweisen, die sagen „Das wird irgendwann schiefgehen“. Ob die Organisation diese Warnungen ernst nimmt, ist ein Gradmesser für ihre Reife.

Diese kulturelle Dimension wirkt sich direkt auf die Kosten aus. Die spektakulären Fälle zeigen drastisch, was es kostet, nicht aus Fehlern zu lernen. Diese Zahlen sind eindrücklich, aber sie zeigen dennoch nur die Spitze des Eisbergs. Die meisten Softwarefehler führen nicht zu spektakulären Katastrophen, sondern zu schleichendem Schaden: ständiges Feuerlöschen statt planvoller Entwicklung, frustrierte Teams mit hoher Fluktuation, Vertrauensverlust bei Kundinnen und Kunden, verpasste Marktchancen, technische Schulden, die sich exponentiell aufbauen. Zahlreiche Studien beziffern die Kosten schlechter Softwarequalität auf Hunderte Milliarden bis Billionen Dollar jährlich. Das ist keine abstrakte Zahl, sondern die Summe aus Millionen kleiner und großer Fehler, die täglich auftreten.