Warum ich keine Workarounds in Architektur akzeptiere

Ich habe nichts gegen pragmatische Entscheidungen. Ich habe etwas gegen Workarounds, die sich als Pragmatismus verkleiden. Das ist ein Unterschied.

Ein Workaround ist für mich nicht einfach eine kleine Zwischenlösung. Ein Workaround ist eine Struktur, die ein Problem umgeht, statt es zu verstehen. Er hilft lokal und beschädigt global. Er erzeugt Bewegung, aber keine Klärung.

Warum lehne ich das in Architektur so deutlich ab? Weil Architektur genau der Ort ist, an dem lokale Bequemlichkeit schnell zu systemischer Unruhe wird. Ein einzelner Workaround ist selten das Problem. Das Problem ist die Gewohnheit, auf diese Weise zu arbeiten.

Wenn ein System an einer Stelle falschen Zustand transportiert, eine API unklar ist, ein Build unstabil wird oder eine Renderstrecke nicht sauber zwischen leerem Zustand und Ladezustand unterscheidet, dann interessiert mich nicht zuerst die schnelle Beruhigung. Mich interessiert zuerst die Ursache.

Das klingt strenger, als es ist. In Wirklichkeit ist es fürs Team oft entlastender. Denn wenn wir die Ursache wirklich verstehen, müssen wir das gleiche Problem nicht an fünf anderen Stellen erneut zähmen.

Genau das ist der Grundgedanke hinter einer einfachen Regel wie dieser hier aus meinem Arbeitskontext:

1. keine Workarounds
2. Ursachen sauber verstehen
3. richtig lösen

Diese Haltung ist nicht dogmatisch. Sie schützt die Form des Systems. Ein Workaround ist oft attraktiv, weil er Konflikt verschiebt. Eine saubere Lösung tut etwas Schwierigeres: Sie trennt Symptom und Ursache.

Nehmen wir ein harmlos wirkendes Beispiel aus einer UI-Strecke. Wenn ein Grid im leeren Zustand dauerhaft „Loading“ anzeigt, gibt es viele schlechte Lösungen. Man könnte Text austauschen. Man könnte Timer einbauen. Man könnte an der Page-Komponente herumtricksen, bis es visuell ruhig aussieht. All das wären Workarounds.

Die bessere Frage lautet: Wo entsteht der falsche Zustand wirklich? In unserem Fall lag die Ursache in der Grid-Infrastruktur selbst und nicht in der Blog-Seite. Erst dort war der Zustand korrekt zu korrigieren.

Das ist ein kleines Beispiel. Aber kleine Beispiele sind architektonisch oft aufschlussreicher als große. Denn sie zeigen, ob ein Team gelernt hat, die Form eines Problems wirklich zu lesen.

Ich akzeptiere Workarounds deshalb nicht als architektonische Lösung, weil sie die falsche Art von Geschwindigkeit erzeugen. Sie machen heute etwas grün und lassen morgen die Struktur teurer werden. Das System bekommt dann Schichten aus stillschweigenden Sonderregeln, die niemand mehr richtig verantwortet.

Es gibt natürlich Situationen, in denen man Übergänge braucht. Ein Hotfix ist nicht automatisch ein architektonischer Verrat. Aber dann muss der Charakter der Maßnahme ehrlich benannt werden:

1. Was ist das eigentliche Problem?
2. Warum lösen wir es gerade nicht vollständig?
3. Wo liegt die technische Schuld jetzt konkret?
4. Wann und wie wird sie abgetragen?

Wenn diese Antworten fehlen, ist der Workaround fast immer nur ein verschobenes Problem.

Mich interessiert an Architektur nicht die Illusion von Perfektion. Mich interessiert, dass Entscheidungen sauber lesbar bleiben. Ein Workaround verschlechtert genau diese Lesbarkeit. Er baut eine zusätzliche Erzählung ins System ein: „Eigentlich sollte es anders sein, aber hier mussten wir mal kurz…“

Aus vielen dieser Sätze entsteht irgendwann ein System, das nicht mehr aus klaren Entscheidungen besteht, sondern aus Entschuldigungen.

Deshalb bin ich an dieser Stelle streng. Nicht aus Starrheit, sondern aus Respekt vor Folgekosten. Gute Architektur schützt ein System auch vor den Entscheidungen, die kurzfristig sehr vernünftig wirken und mittelfristig alles vernebeln.

Eine saubere Ursache zu verstehen, kostet manchmal mehr Zeit als eine Umgehung. Aber sie ist fast immer billiger als Jahre stiller Unordnung.