Fixes That Fail

Beschreibung

Der Archetyp "Fixes That Fail" (Lösungen, die scheitern) ist die Blaupause für klassische technische Schulden. Ein Problem tritt auf, und in der Hektik des Betriebs wird ein "Quick Fix" (ein Pflaster) angewendet. Kurzfristig verschwindet das Symptom, alle klopfen sich auf die Schulter. Doch der schnelle Fix begradigt nicht die strukturelle Ursache, sondern greift tief ins System ein und löst unbeabsichtigte Langzeitfolgen (Nebenwirkungen) aus. Diese Nebenwirkungen feuern nach einer gewissen Zeit erbarmungslos zurück und erschaffen ein Problem, das oftmals viel schlimmer ist als der Ursprungsfehler. Daraufhin wendet man den nächsten "Quick Fix" an.

Feedback Loops

Das System besteht aus einer *Balancing Loop* (Ausgleichende Schleife) und einer bösen *Reinforcing Loop* (Verstärkende Schleife). Die Balancing Loop ist die kurzfristige Lösung: Symptom taucht auf -> Fix anwenden -> Symptom verschwindet (schnelles Feedback). Die Reinforcing Loop verbirgt sich im Dunkeln: Der gleiche Fix löst zeitverzögert (Delay) eine gewaltige Nebenwirkung aus, die das ursprüngliche Problem extrem verschärft anfeuert.

Architekturbeispiel

Eine In-Memory-Datenbank-Instanz (wie Redis) stürzt regelmäßig unter Last ab (Symptom). Der Quick Fix des Architektur-Teams lautet: "Wir fügen ein Auto-Restart-Skript und aggressivere Health-Checks hinzu." Das Symptom verschwindet scheinbar, da Redis nun bei Absturz in 3 Sekunden wieder da ist. Die heimliche Nebenwirkung (Delay): Die Applikation hat in Wahrheit riesige Memory-Leaks. Durch die ständigen automatischen Neustarts bemerkt niemand den schlechten Code. Zwei Monate später ist das Memory-Leak gigantisch, und Redis crasht nun jede Sekunde, löscht Caches und reißt das gesamte Backend in den Abgrund. Der Fix (Auto-Restart) hat die strukturelle Lösung (Speicheranalyse) verhindert.

Organisationsbeispiel

Ein Projekt gerät massiv in Verzug (Symptom). Das Management wendet den Standard-Fix an: Sie "werfen mehr Entwickler auf das Problem" (Mitarbeiter aus anderen Teams abziehen). Kurzfristig beruhigt das die Vorgesetzten, weil "Aktivität" sichtbar ist. Die böse Nebenwirkung: Nach Brooks's Law benötigt die Einarbeitung der neuen Leute massiv Zeit von den Bestandsentwicklern (Verzögerung). Drei Wochen später steht das gesamte Projekt völlig still, zusätzlich brennen nun auch die anderen Teams, denen man die Leute weggenommen hat.

Diagnosefragen

1.Feiern wir gerade eine "Lösung" als Heldentat, deren Architektur wir im Kern aber überhaupt nicht verstanden haben (Voodoo-Debugging)?

2.Bei welchen regelmäßig fehlschlagenden Komponenten ist unser einziger Fix, einfach nochmal härter neuzustarten, mehr Server dazuzustellen oder das Speicherlimit im Container hochzusetzen?

3.Welche "Altlast-Skripte" (Workarounds) in unserem Cluster fixen ein altes Problem zwar noch mit Mühe, generieren uns aber heute einen Albtraum an Betriebsaufwand?

Diagramm

Wie du das Muster im Alltag erkennst

Das tückische an Fixes That Fail ist das menschliche Gehirn: Da die Nebenwirkung zeitverzögert (Stichwort: Delay) auftritt, stellen Teams oft gar keine mentale Verbindung mehr zwischen ihrem super-smarten Fix von vor drei Monaten und der riesigen Katastrophe von heute her. Sie behandeln die Katastrophe als "neues" Problem. Systemdenker erzwingen eine Kultur der Root-Cause Analysis. Quick Fixes (Tape und Pflaster) sind in der Notfall-Chirurgie eines Incident erlaubt, aber das Ticket gilt erst als geschlossen, wenn die Operation (Root Cause refactoring) drei Tage später am offenen Herzen erfolgreich durchgeführt wurde.

Wodurch sich das Muster von ähnlichen Dynamiken unterscheidet

*Fixes that Fail* ähnelt *Shifting the Burden*. Der entscheidende Unterschied: Bei *Fixes that Fail* verursacht der Fix die direkte bösartige Nebenwirkung auf das exakt gleiche System (wie ein Jojo-Effekt der Symptome). Bei *Shifting the Burden* verursacht der schnelle Fix eher eine psychologische Abhängigkeit vom Heiler, während das ursprüngliche Problem mangels Beachtung langsam wegfault.

Wie du vom Muster zur Reaktion kommst

Anerkenne die Notwendigkeit von Quick Fixes, weil Systeme nicht permanent brennen dürfen. Dokumentiere aber jeden dieser Fixes schonungslos als "Toxische Schulden" (nicht nur als technische Schulden). Jede Architektur-Entscheidung, die ein *Fixes That Fail*-Muster ist, erfordert die unmittelbare Erstellung einer hochpriorisierten Story für den darauffolgenden Sprint, die die echte strukturelle Lösung fordert. Wenn das Management diese Root-Cause-Geschichten konsequent de-priorisiert, bereitet ihr den Systemkollaps vor.

Erste nächste Schritte

Verwende Retrospektiven, um zeitverzögerte Nebenwirkungen rückwirkend auszugraben. Frage aktiv: "Das Feature, das uns heute um die Ohren flog – welchen Quick-Fix haben wir dafür vor 3 Monaten gefeiert?"

Woran du das Muster sicher erkennst

Wird in "High-Severity Incidents" exakt protokolliert, was das "Pflaster" (Mitigation) und was das "Heilmittel" (Remediation) ist, und werfen wir das Pflaster weg, sobald das Heilmittel wirkt?

Quellen

The Systems Thinker: Fixes That Fail

Donella Meadows — Thinking in Systems, Kap. 5: System Traps

Wikipedia: System Archetypes