Fehler ohne Schuldfrage, Systeme ohne Übergewicht

Eine gute Fehleranalyse sucht die Systembedingung, nicht die schuldige Person. Und nicht jede Wiederholung im Code braucht sofort eine Abstraktion. Dieser Beitrag zeigt, wie beides zusammenhängt.

Situation

Nach einem Ausfall sucht ein Team entweder eine verantwortliche Person, die den Fehler ausgelöst hat, oder beschließt im Schock des Vorfalls, das betroffene System komplett neu zu bauen, weil es sich plötzlich unsicher anfühlt. Beide Reaktionen fühlen sich nach Handeln an und lösen trotzdem selten das eigentliche Problem. Parallel dazu wird in der laufenden Entwicklung jede Wiederholung im Code sofort in eine allgemeine Abstraktion überführt, „damit es sauber bleibt” oder „damit wir es später nicht doppelt pflegen müssen”. Nach einigen Monaten versteht niemand mehr, wofür die ganzen Parameter der Abstraktion eigentlich gedacht waren, und jede Änderung an einer Stelle erfordert erst, die Abstraktion zu verstehen, bevor man den eigentlichen Fall anfassen kann. Beide Muster, Schuldsuche nach einem Ausfall und vorsorgliche Abstraktion im Code, haben denselben Kern: Sie reagieren auf ein unangenehmes Gefühl, nicht auf einen belegten Bedarf.

Taktik

1. Schreibe die Fehleranalyse ohne Namen von Personen im Text. Frage nach der Systembedingung, die den Fehler ermöglicht hat, nicht danach, wer ihn ausgelöst hat.
2. Rekonstruiere zuerst die Zeitlinie der Ereignisse, bevor über Ursachen gesprochen wird.
3. Priorisiere Maßnahmen aus der Analyse danach, wie wahrscheinlich sich der Fehler wiederholt, nicht danach, wer am lautesten eine Maßnahme fordert.
4. Führe eine Abstraktion erst ein, wenn eine zweite oder dritte tatsächliche Wiederholung vorliegt, nicht vorsorglich für einen angenommenen Zukunftsfall.
5. Fasse ein funktionierendes Altsystem erst an, wenn ein konkretes, benennbares Problem vorliegt, etwa eine bekannte Sicherheitslücke oder nicht mehr vertretbare Wartungskosten, nicht weil es alt oder unmodern wirkt.

Beispiel

Ein Team legt für zwei Umgebungen zunächst zwei eigenständige, leicht redundante Terraform-Konfigurationen an, weil die Unterschiede zwischen beiden Umgebungen noch unklar sind und sich im Projektverlauf noch verändern können. Erst als eine dritte Umgebung dieselben Muster zeigt und die Unterschiede zwischen allen drei Konfigurationen tatsächlich gering ausfallen, wird daraus ein gemeinsames Modul mit klar benannten Variablen gebaut. Die Redundanz vorher war kein Versäumnis, sie hat verhindert, dass ein zu früh generalisiertes Modul die eigentlichen Unterschiede verdeckt und bei der zweiten Umgebung schon falsche Annahmen in Beton gegossen hätte. Dieselbe Zurückhaltung gilt für ein funktionierendes Altsystem: Ein Legacy-Dienst, der seit Jahren stabil läuft, wird nicht ersetzt, weil ein neueres Werkzeug gerade im Trend liegt, sondern wenn ein konkretes Problem ihn nicht mehr tragbar macht, etwa eine nicht mehr gepflegte Abhängigkeit mit bekannten Schwachstellen.

Typische Fehler

• Eine Fehleranalyse, die auf eine einzelne Person zeigt, statt auf die Systembedingung.
• Maßnahmen aus der Analyse nach Lautstärke statt nach Wiederholungswahrscheinlichkeit umsetzen.
• Eine Abstraktion einführen, bevor ein zweiter realer Anwendungsfall sie rechtfertigt.
• Ein Altsystem ablösen, ohne ein konkretes Problem benennen zu können, nur weil ein neueres Werkzeug verfügbar ist.