Wenn Stille lauter ist als ein Alarm: Über Fehlerkultur in Softwaresystemen

Die teuerste Fehlermeldung meiner Laufbahn ist eine, die es nie gegeben hat. Kein roter Text, kein Alarm, kein Eintrag im Protokoll. Nur ein System, das bei einem Problem die Schultern zuckte und so tat, als wäre nichts. Das Aufräumen danach hat Tage gekostet und mehrere Kunden getroffen. Und es hat meine Haltung zu Fehlerkultur nicht nur bestätigt, sondern noch einmal deutlich verschärft.

Ein Fehler in der Software gilt meistens als etwas Negatives. Als Störung, als Makel, als etwas, das am besten gar nicht erst passieren sollte. Dieser Blick greift aber zu kurz. Eine Fehlermeldung ist kein Problem, sie ist ein Hinweis. Sie zeigt dir, dass etwas nicht so funktioniert wie erwartet, und darin liegt ihr Wert. Wer einen Fehler nicht sehen kann, sucht die Lösung nämlich am falschen Ort.

Für dich als Softwareentwickler ist das vermutlich naheliegend. Für dich als Entscheider vielleicht schon weniger, und wenn du gerade mit viel Begeisterung deine ersten Programme mit Hilfe von KI zusammenklickst (dazu weiter unten mehr), wahrscheinlich noch gar nicht. Trotzdem betrifft dieses Thema alle drei Gruppen gleichermaßen, denn im Kern geht es um eine einzige Frage: Wie geht ein System, und die Menschen dahinter, mit dem Umstand um, dass etwas nicht funktioniert?

Gerade in komplexen Softwaresystemen ist das entscheidend. Schnittstellen, Datenflüsse und externe Abhängigkeiten können nie vollständig fehlerfrei sein. Die Qualität eines Systems zeigt sich nicht darin, dass nie Fehler auftreten, sondern darin, wie transparent und nachvollziehbar es mit ihnen umgeht. Dass das keine theoretische Überlegung ist, sondern echte Konsequenzen hat, zeigt eine persönliche Erfahrung aus meiner eigenen Praxis als Entwickler eines PIM Systems für den E-Commerce.

Eine Geschichte, die zeigt, warum Schweigen teurer ist als jede Fehlermeldung

Alles begann damit, dass sich selten, aber wenn dann gleich mehrere Kunden gleichzeitig mit demselben Phänomen meldeten: Aufträge, die nachweislich im Warenwirtschaftssystem (kurz WaWi, also der Software für Lagerhaltung, Bestellungen und Buchhaltung) existierten, schienen in unserem System plötzlich abgebrochen zu sein. Keine Fehlermeldung, kein Hinweis.

Die Analyse erwies sich als extrem schwierig. Denn wo kein Fehler sichtbar ist, sucht man an der falschen Stelle. Wir überprüften Schnittstellen, Protokolle, Datenbestände, doch nichts lieferte einen klaren Hinweis. Am Ende blieb uns nur der mühsame Weg: Ein Datenbank Backup wiederherstellen und dann, Minute für Minute, über die sogenannten Binary Logs (ein fortlaufendes Protokoll aller Datenbankänderungen) die Zwischenzustände der betroffenen Aufträge rekonstruieren. Quasi wie ein Video, das man Frame für Frame zurückspult. Ein aufwendiges Spektakel, das erst nach und nach ein Bild ergab.

Die Auflösung kam erst ganz zum Schluss. Wenn das Warenwirtschaftssystem intern auf ein seltenes Verbindungsproblem zur eigenen Datenbank stieß, wurde dieser Fehler einfach geschluckt. Der betroffene Endpunkt tat dann so, als gäbe es den Auftrag gar nicht. Kein Fehler, keine Warnung, nur ein stilles „nicht gefunden“.

Was lehrt dieser Fall?

Dieses Erlebnis zeigt, worum es hier eigentlich geht. Nicht die Fehlermeldung ist das Problem, sondern ihr Fehlen. Ein klarer Hinweis hätte den Aufwand massiv reduziert, das Schweigen dagegen führte dazu, dass die Folgen viele Kunden trafen und die Ursache lange unentdeckt blieb.

Darin liegt auch die Parallele zum echten Leben. Warnsignale zu übersehen, oder bewusst zu ignorieren, mag kurzfristig bequem erscheinen. Doch die Probleme verschwinden dadurch nicht. Sie wachsen im Verborgenen weiter, bis sie irgendwann viel schwieriger zu lösen sind. Dafür musst du kein Techniker sein, um das Prinzip zu verstehen. Wer kleine Hinweise ernst nimmt und offen damit umgeht, kann rechtzeitig reagieren. Wer sie verdrängt, steht irgendwann vor einem viel größeren Problem, ganz gleich ob in der Software, im Unternehmen oder im privaten Alltag.

Interessanterweise (weil ich das Wort „leider“ nicht gerne benutze) tragen in solchen Fällen oft auch unbeteiligte Personen die Folgen. Wenn ein Hinweis fehlt, verlagert sich die Last ungewollt auf Kunden, Kollegen oder andere Systeme, die mit dem eigentlichen Problem gar nichts zu tun haben.

Warum Menschen Fehler verstecken, wenn Ehrlichkeit bestraft wird

Die Wurzel des Problems liegt selten im System selbst, sondern in der Kultur drumherum. Ein Endpunkt, der einen Auftrag lieber verschwinden lässt, als einen Fehler zu melden, hat das nicht aus eigenem Antrieb getan. Irgendjemand hat einmal so eine Fehlerbehandlung geschrieben, vermutlich mit der besten Absicht, ein System möglichst robust wirken zu lassen.

In der Luftfahrt hat man dieses Muster schon vor Jahrzehnten erkannt. Das Aviation Safety Reporting System, betrieben von der NASA, sammelt seit den 1970er Jahren freiwillige und anonyme Meldungen über Beinahe-Zwischenfälle, ausdrücklich ohne Konsequenzen für den Meldenden. Die Idee dahinter: Wer Angst vor Strafe hat, meldet Fehler nicht, und gerade die unentdeckten Fehler werden irgendwann zu echten Unfällen. In der Medizin gibt es mit den sogenannten Morbidity and Mortality Konferenzen ein ganz ähnliches Prinzip, offene Besprechung von Komplikationen, ohne dass es um Schuldzuweisung geht. Auch in der klassischen Arbeitssicherheit gilt dasselbe Prinzip: Beinaheunfälle, also Situationen, die beinahe zu einem Arbeitsunfall geführt hätten, werden bewusst dokumentiert und ausgewertet, nicht um jemanden zu belangen, sondern weil sie oft die einzige Chance sind, ein Muster zu erkennen, bevor tatsächlich jemand zu Schaden kommt.

In der Softwarebranche hat sich daraus der Begriff der blameless Fehlerkultur etabliert, unter anderem geprägt durch Unternehmen wie Etsy und durch Googles Praxis rund um sogenannte Postmortems nach Störungen. Der Kern ist immer derselbe: Wenn das Aufdecken eines Fehlers zu Ärger führt, werden Fehler versteckt statt gemeldet, in der Software genauso wie im Team dahinter. Wenn du also als Entscheider willst, dass dein System (und deine Mitarbeiter) offen mit Problemen umgehen, dann fängt das nicht beim Code an, sondern bei der Frage, was passiert, wenn jemand einen Fehler zugibt.

Warum „die KI wird’s schon lösen“ ein gefährlicher Trugschluss ist

Jetzt zu einem Thema, das die eingangs erwähnte dritte Zielgruppe direkt betrifft. Wer heute eine Idee für eine Software hat, muss kein Studium mehr absolvieren, um innerhalb weniger Stunden etwas Lauffähiges auf dem Bildschirm zu sehen. Eine KI schreibt bereitwillig Code, und oft funktioniert das Ergebnis auf den ersten Blick sogar erstaunlich gut. Das klingt nach einer kleinen Revolution, und in vielerlei Hinsicht ist es das auch.

Meine eigene Praxis dazu: Alles, was bei uns inzwischen neu an Software entsteht, entwickle ich zu 100 Prozent mit KI, nicht nur gelegentlich, sondern durchgängig. Trotzdem verbringe ich oft deutlich mehr Zeit mit dem Review als mit dem Schreiben selbst, und ich akzeptiere das erste Ergebnis eher selten.

Der Grund: KI behandelt sehr gerne Symptome, statt das Problem an der Wurzel zu lösen, und das selbst dann, wenn der Kontext sehr gut ist, etwa durch feste, ausformulierte Projektregeln, an die sich die KI halten soll. 

Ein Fehler taucht auf, die KI baut eine Abfangroutine drumherum, und die Meldung verschwindet, das dahinterliegende Problem aber nicht. Für jemanden mit Erfahrung ist sofort ersichtlich, ob damit tatsächlich die Ursache behoben oder nur das Symptom kaschiert wurde. Dieses Gespür fehlt aber, wenn man selbst keine Ahnung von Softwareentwicklung hat.

„Vibecoded“ Software, also Software, die entsteht, indem man einer KI Anweisungen gibt und das Ergebnis übernimmt, ohne es wirklich zu verstehen, wird in vielen Fällen tatsächlich funktionieren. Zumindest fürs Erste. Und darin liegt der Unterschied zu einer Software, die jemand mit Verständnis für die Materie entwickelt oder zumindest begleitet hat. Beides sieht zunächst gleich aus. Der Unterschied zeigt sich erst später, dann nämlich, wenn ein Fall eintritt, an den beim Bauen niemand gedacht hat, oder den die KI stillschweigend unter den Teppich gekehrt hat, so wie in meiner Anekdote oben das Warenwirtschaftssystem.

Und damit spart man sich unterm Strich keine Zeit, sie verlagert sich nur. Weg von der Entwicklung, hin zum Support. Jeder Fehler, der es bis zum Support schafft, kostet ungleich mehr Aufwand als in einem System, das dieses Problem von vornherein weitgehend verhindert. Ein Support Fall bedeutet immer, dass bereits ein Kunde betroffen ist, dass jemand sich die Zeit nehmen muss den Fall zu melden, dass jemand ihn entgegennehmen, einordnen, reproduzieren und analysieren muss, oft ohne die Zusammenhänge zu kennen, die beim ursprünglichen Bauen noch präsent waren.

Damit will ich KI nicht schlechtreden, im Gegenteil. Aber ein Werkzeug ersetzt kein Verständnis, so gut es auch geworden ist. Wer weiß, wonach er sucht, kann eine KI hervorragend einsetzen, um schneller ans Ziel zu kommen, und zwar selbst bei sehr gutem Kontext. Wer dagegen selbst keine Erfahrung mitbringt, bekommt vielleicht ein Ergebnis, das zunächst funktioniert, skaliert damit aber vor allem eines sehr effizient: Probleme, nur eben deutlich schneller als früher.

Je später ein Fehler auffällt, desto teurer wird er

Dass verlagerter Aufwand kein Randphänomen ist, sondern ein altbekanntes Muster, zeigt schon die Software Engineering Forschung der 1980er Jahre. Barry Boehm hat in seinem Werk „Software Engineering Economics“ anhand realer Projektdaten gezeigt, dass ein Fehler, der erst nach der Auslieferung gefunden wird, um ein Vielfaches teurer ist als derselbe Fehler während der Entwicklung. Die genauen Multiplikatoren schwanken je nach Studie und Projektkontext, mal ist von Faktor 10 die Rede, mal deutlich mehr, aber der grundsätzliche Trend gilt bis heute als unbestritten: Je später ein Problem auffällt, desto mehr Kontext ist bereits verloren gegangen, desto mehr Personen sind involviert, und desto teurer wird die Behebung.

Das ist der eigentliche Denkfehler bei "schnell mal mit KI zusammengeklickt". Die eingesparte Zeit beim Bauen steht in keinem guten Verhältnis zu dem, was ein Fehler kostet, der erst beim Kunden auffällt.

Das heißt nicht, dass ein schnelles Time to Market grundsätzlich falsch wäre, im Gegenteil, oft ist es goldrichtig, und Agilität lebt sogar davon, bewusst nicht sofort jedes Detail zu perfektionieren. Der Unterschied liegt darin, woran man spart. Funktionsumfang zu reduzieren oder Features zu verschieben ist eine legitime, oft sogar kluge Entscheidung. Grundlegende Softwarequalität einzusparen ist etwas anderes, das rächt sich ab einem gewissen Punkt zuverlässig. Dieses Gespür für den Unterschied gehört für mich zum Grundverständnis, das ein Softwareentwickler mitbringen sollte, unabhängig davon ob agil gearbeitet wird oder nicht. Das eine widerspricht dem anderen nämlich nicht.

Wie wir mit TRADElube ganz konkret mit Fehlern umgehen

Nach so viel Theorie ein Blick in die Praxis, nämlich wie wir das beschriebene Prinzip in unserem eigenen Produkt TRADElube umsetzen. TRADElube ist eine Software, die verschiedene Systeme im E-Commerce miteinander verbindet, zum Beispiel ein Warenwirtschaftssystem mit einem Onlineshop. Gerade in diesem Umfeld, wo mehrere fremde Systeme zusammenspielen müssen, ist Fehlerkultur kein akademisches Thema, sondern tägliches Geschäft.

Der zentrale Baustein dafür ist die sogenannte Nachverfolgung. Für jede Aufgabe, die Daten ausliest, verarbeitet oder überträgt, protokolliert TRADElube genau, was wann passiert ist. War ein Objekt neu, wurde es geändert, gelöscht, oder blieb es unverändert? War die Übertragung erfolgreich, oder ist sie fehlgeschlagen? All das lässt sich im Nachhinein einsehen, mitsamt den konkreten Inhalten, die tatsächlich übertragen wurden.

Warum ist das wichtig? Weil sich damit die allermeisten Fragen selbst beantworten lassen, ohne Rückfrage bei uns als Hersteller. Warum steht im Shop plötzlich ein anderer Preis? Ein Blick in die Nachverfolgung zeigt sofort, welcher Wert tatsächlich aus der WaWi geliefert wurde. Warum wurde ein Lagerbestand nicht aktualisiert? Auch das lässt sich nachvollziehen, ohne tiefes technisches Wissen. Man muss die zugrundeliegenden Datenformate nicht im Detail verstehen, um die enthaltene Information sinnvoll zu deuten.

Aus der eingangs beschriebenen Anekdote heraus haben wir die Nachverfolgung übrigens um eine Historie erweitert. Damals mussten wir die Zwischenzustände mühsam über ein Backup und die Binary Logs rekonstruieren. Heute reicht dafür ein Blick in die Historie der Nachverfolgung selbst, dieser Umweg entfällt.

Das ist letztlich dieselbe Haltung wie in der Anekdote von vorhin, nur konsequent zu Ende gedacht. Ein System, das seine eigenen Vorgänge transparent offenlegt, verhindert die Art von stillem Versagen, die so teuer wird. Es ersetzt Rätselraten durch Nachvollziehbarkeit, und das kommt allen zugute: Kunden, die selbst nachschauen können, und uns, weil wir uns dadurch auf die Fälle konzentrieren können, bei denen unsere Hilfe tatsächlich gebraucht wird.

Wann ist ein Fehler wirklich ein Fehler?

Bei allem Plädoyer für Fehlermeldungen als wertvollen Hinweis: Natürlich gibt es auch echte Fehler, sogenannte Bugs, die ein System tatsächlich beeinträchtigen. Diese offensichtlichen Fehler fallen in der Regel schneller auf, vorausgesetzt, sie werden nicht verschluckt, sondern sichtbar gemacht.

Ein Bug, der verschluckt oder als „so ist das eben gedacht“ schöngeredet wird, ist schlichtweg ein Fehler im Umgang mit Fehlern. Ich muss an dieser Stelle deutlich werden: Solche Praktiken erschweren die Analyse, verzögern die Behebung und können unbeabsichtigte Folgen für Nutzer und andere Systeme haben. Sie sind weder ratsam noch professionell, weder bei klassisch entwickelter, noch bei KI unterstützt entwickelter Software.

Dennoch bleibt die Kernaussage gültig. Entscheidend ist nicht, ob eine Meldung erscheint, sondern dass sie überhaupt sichtbar wird. Eine sichtbare Fehlermeldung, ob echter Bug oder bloßer Hinweis auf einen ungewöhnlichen Zustand, ist immer wertvoller als ein stilles Verschlucken. Sie ist ein Werkzeug, das hilft, Systeme frühzeitig zu verstehen und Probleme zu beheben, bevor sie kritisch werden.

Was bedeutet das für dich?

Egal ob du selbst Code schreibst, Software für dein Unternehmen einkaufst, oder gerade dabei bist, mit KI dein erstes eigenes kleines Tool zu bauen: Achte darauf, wie ein System mit dem Fall umgeht, dass etwas nicht funktioniert. Schweigt es, oder meldet es sich?

Ein paar Fragen, die sich lohnen, wenn du das nächste Mal ein System beurteilen musst, unabhängig davon ob du es selbst baust oder einkaufst:

• Was passiert, wenn eine Schnittstelle nicht antwortet? Wird das sichtbar, oder einfach ignoriert?
  
• Lässt sich im Nachhinein nachvollziehen, was ein System wann getan hat?
  
• Wurde ein Fehler wirklich behoben, oder nur so lange umgangen, bis er nicht mehr auffällt?
  
• Was passiert in deinem Team, wenn jemand einen eigenen Fehler zugibt? Wird das offen besprochen, oder folgt darauf Ärger?

Diese Fragen zu stellen kostet ein paar Minuten. Sie nicht zu stellen, kann dich später sehr viel mehr Zeit kosten, meistens genau dann, wenn du sie am wenigsten übrig hast.

Fazit: Stille ist keine gute Nachricht

Ein Alarm ist unangenehm, aber ehrlich. Er sagt dir sofort, wo das Problem liegt. Stille dagegen fühlt sich im ersten Moment nach Ruhe an, und genau das macht sie so gefährlich. Sie bedeutet nicht, dass alles gut ist, sie bedeutet nur, dass du noch nichts davon weißt.

Fehlerkultur in der Softwareentwicklung, ob mit oder ohne KI, ob im eigenen Team oder beim eingekauften System, entscheidet sich genau an diesem Punkt: Wird ein Problem sichtbar gemacht, oder wird es weggeschluckt? Die Antwort darauf sagt mehr über die Qualität einer Software aus, als jede Feature Liste es je könnte.

FAQ

Was bedeutet Fehlerkultur in Softwaresystemen?

Wie transparent und nachvollziehbar ein System mit Problemen umgeht, statt sie stillschweigend zu verschlucken. Nicht das Auftreten von Fehlern entscheidet über Qualität, sondern der Umgang damit.

Warum ist eine fehlende Fehlermeldung gefährlicher als eine sichtbare?

Ein stilles System täuscht Ruhe vor, während das Problem im Verborgenen weiterwächst. Wird ein Fehler nicht sichtbar gemacht, sucht man bei der Analyse an der falschen Stelle und die Behebung wird deutlich teurer.

Warum ist blameless Fehlerkultur für Software wichtig?

Wenn das Aufdecken eines Fehlers zu Ärger führt, werden Fehler versteckt statt gemeldet. Prinzipien aus Luftfahrt und Medizin zeigen: Ohne Konsequenzen für den Meldenden kommen Probleme früher ans Licht.

Warum reicht KI-generierter Code allein nicht für gute Fehlerkultur in Softwaresystemen?

KI behandelt oft Symptome statt Ursachen und kaschiert Fehlermeldungen, statt sie sichtbar zu machen. Ohne Verständnis der Materie bleibt das unentdeckt, bis ein Fall auftritt, an den beim Bauen niemand gedacht hat.