Change it, like it or leave it

Nach zwölf Artikeln könnte man erwarten, dass sich der Big Ball of Mud irgendwann auf eine einfache Ursache reduzieren lässt.

Vielleicht auf schlechte Architektur. Auf zu wenig Refactoring. Auf fehlende technische Führung. Auf Zeitdruck. Auf Legacy. Auf Managemententscheidungen. Auf Entwickler, die über Jahre zu viele Ausnahmen eingebaut haben.

Und wenn die Ursache erst gefunden ist, müsste sich daraus eigentlich auch eine eindeutige Lösung ableiten lassen.

Genau das ist in dieser Serie nicht passiert.

Je länger wir den Big Ball of Mud betrachtet haben, desto mehr scheinbare Widersprüche sind sichtbar geworden. Systeme können technisch hochproblematisch und operativ stabil sein. Experten können gleichzeitig enorme Probleme lösen und strukturelle Abhängigkeiten verstärken. Organisationen können unter einer schlechten Architektur leiden und trotzdem vollkommen rational entscheiden, sie nicht grundlegend zu verändern. Menschen können dieselbe Arbeitsumwelt als interessante Herausforderung, akzeptable Realität oder kaum noch tragbaren Konflikt erleben.

Das wirkt nur so lange widersprüchlich, wie man versucht, den Big Ball of Mud ausschließlich als Codeproblem zu erklären.

Der Big Ball of Mud ist voller Widersprüche, die nur dann widersprüchlich wirken, wenn man ihn ausschließlich als Codeproblem betrachtet.

Schon die Definition des Big Ball of Mud hat deshalb eine wichtige Grenze gezogen: Ein Big Ball of Mud ist weder einfach ein Monolith noch ein altes oder großes System. Entscheidend ist ein struktureller Zustand, in dem die sichtbare oder beabsichtigte Architektur immer weniger zuverlässig erklärt, wie das System tatsächlich organisiert ist.

Am Ende dieser Serie lohnt es sich, diese Perspektive noch einmal zu erweitern.

Denn ein langlebiger Big Ball of Mud besteht irgendwann nicht mehr nur aus Code und Abhängigkeiten. Um ihn herum entstehen Prozesse, Wissen, Rollen, wirtschaftliche Entscheidungen und menschliche Anpassungsstrategien. Diese Ebenen reagieren aufeinander. Sie kompensieren Schwächen, erzeugen neue Abhängigkeiten und können einen Zustand stabilisieren, der aus rein technischer Sicht erstaunlich instabil wirken müsste.

Er funktioniert – und kann trotzdem strukturell erodiert sein

Eine der wichtigsten Unterscheidungen dieser Serie war zugleich eine der einfachsten.

Ein Big Ball of Mud muss nicht aufhören zu funktionieren.

Das Produkt kann Umsatz erzeugen, Kunden bedienen, regulatorische Anforderungen erfüllen und zuverlässig betrieben werden. Releases können stattfinden. Neue Features können ausgeliefert werden. Incidents können beherrschbar bleiben. Die Software kann über viele Jahre einen erheblichen Geschäftswert liefern.

Genau deshalb ist die Reaktion „Aber es funktioniert doch“ nicht naiv. Aus Sicht eines Stakeholders ist sie zunächst vollkommen legitim.

Der strukturelle Zustand beantwortet jedoch eine andere Frage als der gegenwärtige Produktzustand.

Ein Softwaresystem kann heute zuverlässig Wert liefern und gleichzeitig immer schlechter darin werden, morgen verändert zu werden.

Funktionalität und Änderbarkeit sind unterschiedliche Qualitätsdimensionen.

Ein System ist deshalb nicht einfach „kaputt“, nur weil seine Architektur schlecht geworden ist. Es kann seine aktuelle Aufgabe weiterhin gut erfüllen. Problematisch wird die Struktur dort, wo der heutige Erfolg verdeckt, welchen Aufwand und welche Unsicherheit zukünftige Veränderungen inzwischen erzeugen.

Gerade das macht einen Big Ball of Mud so langlebig. Der unmittelbare Beweis, dass etwas grundsätzlich geändert werden müsste, fehlt häufig. Was sichtbar ist, funktioniert. Was schlechter wird, ist die Fähigkeit, auf eine Zukunft zu reagieren, die noch nicht eingetreten ist.

Niemand hat ihn gebaut – und trotzdem haben viele an ihm mitgebaut

Ebenso wenig beginnt ein Big Ball of Mud normalerweise mit einer Entscheidung:

Wir bauen jetzt schlechte Architektur.

Der Artikel „Niemand hat ihn gebaut“ hat genau deshalb nicht nach einem Schuldigen gesucht. Ein langlebiges System sammelt über Jahre lokale Entscheidungen: Proofs of Concept werden zu Produkten, Ausnahmen bleiben bestehen, Konsolidierungen werden verschoben, Anforderungen ändern sich, Teams wechseln, Zuständigkeiten werden neu geschnitten und unter Zeitdruck entstehen Lösungen, die für den jeweiligen Moment nachvollziehbar sind.

Keine einzelne dieser Entscheidungen muss den späteren Zustand erklären können.

Erst ihre Geschichte tut es.

Architektur entsteht nicht nur durch das, was wir bewusst entwerfen. Sie entsteht auch durch das, was wir über Jahre nicht mehr zurücknehmen.

Darin liegt ein weiteres Paradox: Niemand muss den Big Ball of Mud geplant haben, obwohl viele Menschen an seiner Entstehung beteiligt waren.

Das löst Verantwortung nicht auf. Entwickler treffen technische Entscheidungen. Architekten setzen oder unterlassen Grenzen. Führung schafft Rahmenbedingungen. Product Ownership priorisiert. Organisationen verteilen Budgets und Zuständigkeiten.

Aber Schuldzuweisung erklärt wenig darüber, warum sich bestimmte Entscheidungen über viele Jahre gegenseitig verstärken konnten.

Auf Schuldzuweisungen zu verzichten bedeutet nicht, Verantwortung aufzulösen. Es bedeutet lediglich, ein systemisches Problem nicht auf einzelne Personen zu reduzieren.

Er besitzt Struktur – aber sie erklärt ihn nicht mehr zuverlässig

Auch das Wort „Mud“ kann in die Irre führen.

Ein Big Ball of Mud ist nicht notwendigerweise eine vollkommen formlose Codebasis. Es können weiterhin Module, Layer, Ordner, Services, Komponenten und detaillierte Architekturdiagramme existieren. Das System kann sogar ausgesprochen ordentlich aussehen, wenn man nur auf seine Verzeichnisstruktur blickt.

Entscheidend ist, ob diese Struktur noch trägt.

Im Artikel „Habe ich im Frontend einen Big Ball of Mud?“ ging es deshalb nicht um einzelne große Komponenten oder einen schlecht geschnittenen Service. Kritisch wird der Zustand dort, wo die vorgesehenen Grenzen selbst ihre Wirkung verlieren.

Ein fachlicher Slice kann existieren, während andere Slices direkt auf seine internen Services zugreifen. Ein Domain-Layer kann vorhanden sein, während Business Rules gleichzeitig in Components, Effects, Mappern und HTTP-Services reproduziert werden. Eine öffentliche API kann definiert sein, während sie bei Bedarf jederzeit umgangen wird.

Eine Grenze, die jeder beliebig überschreiten kann, ist irgendwann nur noch ein Ordnername.

Ein Big Ball of Mud verliert also nicht zwangsläufig jede Struktur. Er verliert die Verlässlichkeit dieser Struktur als Erklärung des Systems.

Genau dadurch wird Architektur weniger nützlich. Ihre Aufgabe besteht schließlich nicht nur darin, Dateien ordentlich anzuordnen. Sie soll den Raum möglicher Abhängigkeiten einschränken. Sie soll dabei helfen vorherzusagen, wo eine Verantwortung liegt, welche Teile voneinander wissen dürfen und welcher Kontext für eine Änderung relevant ist.

Wenn diese Vorhersagekraft verloren geht, bleibt Architektur sichtbar, ohne noch ausreichend Orientierung zu geben.

Änderungen werden klein beschrieben – und groß im System

Eine User Story kann aus drei Sätzen bestehen. Der eigentliche Patch kann wenige Zeilen umfassen. Das fachliche Verhalten kann vollkommen überschaubar sein.

Und trotzdem kann eine sichere Änderung einen großen Teil des Systems berühren.

Im Artikel „Wenn jede Änderung überall weh tut“ haben wir dafür drei unterschiedliche Radien betrachtet: den fachlichen Radius, den technischen Änderungsradius sowie den Verständnis- und Regressionsradius.

In einem gut abgegrenzten System liegen diese Radien häufig vergleichsweise nah beieinander. Eine lokale fachliche Änderung besitzt einen hinreichend lokalen technischen Wirkungsraum.

Im Big Ball of Mud können sie auseinanderlaufen.

Im Big Ball of Mud verliert die Änderung ihre Lokalität.

Das Problem besteht dann nicht zwangsläufig darin, dass der Diff besonders groß ist.

Nicht die Größe des Diffs ist das Problem. Die Unsicherheit über seine Wirkung ist es.

Damit verändert sich auch die wirtschaftliche Bedeutung einer Änderung. Der sichtbare Code ist nur ein Teil der notwendigen Arbeit. Verständnis, Koordination, Regression und Absicherung können einen wesentlich größeren Anteil einnehmen.

Eine kleine Anforderung ist dann noch immer eine kleine Anforderung.

Das System macht sie groß.

Der Experte rettet das System – und macht es dadurch weiter betreibbar

Wo explizite Struktur weniger Orientierung liefert, gewinnt implizites Wissen an Wert.

In langlebigen Systemen entstehen deshalb häufig Menschen, die Zusammenhänge verstehen, die sich aus der Codebasis allein nur mit erheblichem Aufwand rekonstruieren lassen. Sie kennen historische Entscheidungen, versteckte Sonderfälle, gefährliche Bereiche, Release-Rituale und jene Abhängigkeiten, die in keinem Architekturdiagramm stehen.

Diese Menschen sind wertvoll.

Der Artikel „Der Architekt, ohne den nichts mehr geht“ war deshalb ausdrücklich keine Kritik an Expertise. Schwierige Systeme benötigen erfahrene Menschen, und außergewöhnliche technische Kompetenz ist kein Architekturproblem.

Problematisch wird die Konzentration.

Der Experte wird unverzichtbar, weil das System schlecht ist. Und das System kann schlecht bleiben, weil der Experte unverzichtbar ist.

Wenn schwierige Aufgaben immer bei denselben Personen landen, lernen diese Menschen noch mehr über die kritischen Bereiche. Die Organisation vertraut ihnen stärker. Beim nächsten Problem werden sie früher hinzugezogen. Andere Entwickler erhalten weniger Gelegenheit, dasselbe Wissen aufzubauen.

Damit kann sich eine Abhängigkeit selbst stabilisieren, obwohl niemand sie bewusst erzeugen wollte.

Die Schlüsselperson kann gleichzeitig einer der wertvollsten Menschen im System und eines seiner größten Risiken sein.

Die richtige Konsequenz daraus ist nicht, Expertise abzuwerten oder den Experten aus dem System zu entfernen.

Das Problem ist nicht der Experte.

Das Problem ist das Monopol.

Mehr Absicherung hilft – und kann strukturelle Probleme gleichzeitig verdecken

Ein schwer veränderbares System muss nicht permanent ausfallen.

Organisationen können ausgesprochen gut darin werden, seine Risiken zu kompensieren.

Sie ergänzen Regressionstests. Sie etablieren zusätzliche Reviews. Sie lassen kritische Änderungen von erfahrenen Personen freigeben. Releases erhalten besondere Abläufe. Testphasen werden länger. Bestimmte Bereiche werden nur von bestimmten Entwicklern angefasst. Workarounds werden dokumentiert. Für bekannte Fehlermuster entstehen Incident-Prozesse.

Keine dieser Maßnahmen ist automatisch schlecht.

Viele von ihnen sind unter den gegebenen Bedingungen notwendig. Zusätzliche Tests können reale Fehler verhindern. Reviews verteilen Wissen. Ein vorsichtiger Release-Prozess kann für ein geschäftskritisches System vollkommen angemessen sein.

Der interessante Effekt entsteht erst auf der Gesamtebene.

Je erfolgreicher eine Organisation die Folgen struktureller Unsicherheit auffängt, desto weniger unmittelbar muss diese Unsicherheit als technisches Problem sichtbar werden.

Ein Big Ball of Mud kann technisch chaotisch und operativ erstaunlich stabil sein.

Das war bereits eine zentrale Beobachtung im ersten Artikel über die Architektur, über die niemand sprechen möchte.

Das System funktioniert dann nicht einfach trotz der zusätzlichen Kompensation. Ein Teil seiner Stabilität kann gerade daraus entstehen, dass Menschen und Prozesse die fehlende strukturelle Vorhersagbarkeit auffangen.

Das ist eine reale Leistung, verschiebt aber zugleich Kosten in Prozesse, Wissen, Koordination und zusätzliche Absicherung.

Die Entwickler wirken langsamer – obwohl genauso viel gearbeitet wird

Von außen ist diese Verschiebung nicht immer leicht zu erkennen.

Ein Team kann genauso konzentriert und engagiert arbeiten wie früher und trotzdem weniger neuen fachlichen Produktumfang ausliefern. Ein wachsender Teil seiner Kapazität kann inzwischen für Tätigkeiten benötigt werden, die die sichere Veränderung des bestehenden Systems erst ermöglichen: bestehendes Verhalten verstehen, Auswirkungen rekonstruieren, Sonderfälle prüfen, andere Teams koordinieren, Regression verhindern, Fehler nacharbeiten oder Schlüsselpersonen einbeziehen.

Der Output sinkt nicht zwingend, weil weniger gearbeitet wird. Ein wachsender Anteil der Arbeit kann notwendig werden, um die Änderbarkeit des bestehenden Systems zu kompensieren.

Damit entsteht ein gefährlicher Perspektivwechsel.

Was innerhalb des Entwicklungsteams als wachsender Verständnis- und Absicherungsaufwand erlebt wird, kann außerhalb wie ein Leistungsproblem wirken.

Die fachliche Anforderung ist schließlich nicht größer geworden.

Warum dauert sie dann länger?

Wenn die strukturellen Kosten nicht sichtbar sind, liegt eine personelle Erklärung nahe: Entwickler seien langsamer geworden, das Team sei zu groß, die Schätzungen seien schlecht oder es werde zu viel Zeit mit „Technik“ verbracht.

Manchmal kann all das tatsächlich der Fall sein.

Aber in einem Big Ball of Mud existiert noch eine andere Möglichkeit:

Das Team arbeitet nicht weniger. Das System verlangt inzwischen mehr Arbeit für dieselbe Veränderung.

Das System kann wirtschaftlich rational sein – und trotzdem ein Risiko darstellen

Aus dieser Diagnose folgt dennoch nicht automatisch die wirtschaftliche Entscheidung, das System grundlegend zu verändern.

Der Artikel über die Ökonomie eines Big Ball of Mud hat bewusst mit der Gegenposition begonnen: Ein technisch stark erodiertes System kann wirtschaftlich vollkommen rational sein.

Ein Produkt am Ende seines Lebenszyklus benötigt möglicherweise nur noch wenige Änderungen. Die Maintenance-Mannschaft ist klein. Eine Ablösung ist beschlossen. Neue Integrationen sind nicht vorgesehen. Eine umfassende Rekonstruktion würde erhebliche Investitionen und zusätzliches Übergangsrisiko erzeugen, ohne sich innerhalb der verbleibenden Lebensdauer noch zu amortisieren.

Dann kann die vernünftige Entscheidung lauten, mit der bestehenden Struktur weiterzuarbeiten.

Architektur besitzt schließlich keinen wirtschaftlichen Wert allein dadurch, dass sie schöner wird.

Die andere Seite dieser Entscheidung bleibt jedoch bestehen:

„Wir planen keine Änderungen mehr“ ist nicht dasselbe wie „wir werden keine Änderungen mehr durchführen müssen“.

Security-Anforderungen, regulatorische Veränderungen, Betriebssysteme, Browser, Cloud-Plattformen, externe APIs und andere Abhängigkeiten besitzen eigene Lebenszyklen. Nicht jede zukünftige Änderung steht heute auf einer Roadmap.

Deshalb hängt die wirtschaftliche Bedeutung eines Big Ball of Mud nicht allein von seinem technischen Zustand ab.

Die wirtschaftliche Bedeutung eines Big Ball of Mud hängt davon ab, was die Organisation in Zukunft noch von diesem System verlangt.

Dasselbe technische System kann für ein auslaufendes Produkt tolerierbar und für ein strategisches Kernprodukt ein erhebliches Risiko sein.

Auch darin steckt kein Widerspruch.

Es sind unterschiedliche wirtschaftliche Situationen.

Menschen passen sich an das System an – und stabilisieren es dadurch mit

Software ist für Entwickler nicht nur ein technisches Artefakt.

Wenn Menschen mehrere Jahre an demselben System arbeiten, wird seine Struktur zu einem Teil ihrer Arbeitsumwelt.

Der Artikel darüber, was ein Big Ball of Mud mit Menschen macht, hat deshalb bewusst nicht nur nach Codequalität gefragt. Menschen lernen, welche Bereiche riskant sind. Sie kennen sichere Wege. Sie wissen, welche Person sie fragen müssen. Sie akzeptieren bestimmte Workarounds, entwickeln mentale Modelle für implizite Zusammenhänge oder reduzieren ihre Erwartungen daran, welche Veränderungen überhaupt noch realistisch sind.

Andere geraten stärker in Konflikt mit dieser Arbeitsweise. Sie sehen klare strukturelle Probleme, empfinden Verantwortung für ihre Verbesserung und erleben gleichzeitig, dass ihre tatsächliche Entscheidungsmacht dafür nicht ausreicht.

Keine dieser Reaktionen eignet sich als einfacher Persönlichkeitstyp.

Menschen können sich verändern. Sie können zunächst Strukturen verbessern wollen und später pragmatischer werden. Sie können als Navigator beginnen und später Veränderung anstoßen. Sie können dieselbe Umgebung zu unterschiedlichen Zeitpunkten vollkommen unterschiedlich erleben.

Entscheidend für die Systemperspektive ist etwas anderes:

Ein Big Ball of Mud kann technisch chaotisch und sozial erstaunlich stabil sein.

Irgendwann passt sich nicht mehr nur die Software an wechselnde Anforderungen und Organisationen an.

Die Menschen beginnen, sich an die Software anzupassen.

Auch diese Anpassung kann dazu beitragen, dass das System weiter funktioniert.

Man kann ihn verändern – aber nicht alleine

All diese Mechanismen bedeuten nicht, dass ein Big Ball of Mud unveränderbar wäre.

Lokales Refactoring bleibt sinnvoll. Michael Feathers’ Arbeit mit Legacy Code bleibt sinnvoll. Strangler-artige Rekonstruktion kann Grenzen schrittweise wiederherstellen. Requirements Engineering kann helfen, historische Implementierungsdetails von tatsächlich notwendigem fachlichem Verhalten zu trennen. Acceptance- und E2E-Tests können bei einer Rekonstruktion eine äußere Klammer bilden.

Der vorherige Artikel über Wege aus einem Big Ball of Mud hat diese Möglichkeiten ausführlicher betrachtet.

Seine wichtigste Aussage war jedoch keine technische Methode.

Ein Big Ball of Mud sollte niemals von einer einzelnen Person gerettet werden.

Das ist keine empirische Naturregel, sondern eine Architekturhaltung.

Ein systemischer Zustand umfasst irgendwann technische Strukturen, Fachlichkeit, Wissen, Entscheidungsrechte, Betriebsprozesse und organisatorische Rahmenbedingungen gleichzeitig. Ein einzelner Entwickler kann darin sehr viel bewegen. Er kann eine Grenze erkennen, eine bessere Lösung zeigen, Tests einführen oder eine erste Rekonstruktion ermöglichen.

Aber er kann die notwendigen Voraussetzungen nicht beliebig alleine herstellen.

Wenn die Lösung erneut davon abhängt, dass eine Person das gesamte System versteht, jede wichtige Entscheidung trifft und persönlich dafür sorgt, dass andere die neue Struktur korrekt verwenden, wurde ein Problem möglicherweise technisch verbessert und organisatorisch reproduziert.

Der Ausweg aus einem Big Ball of Mud ist keine Heldengeschichte. Er ist eine gemeinsam getragene Rekonstruktion.

Viele Eigenschaften eines Big Ball of Mud wirken widersprüchlich, solange man ihn nur als technisches Problem betrachtet. Erst die technische, organisatorische, ökonomische und menschliche Perspektive gemeinsam erklären seine Stabilität.

Ein stabilisiertes sozio-technisches Gleichgewicht

Vielleicht lässt sich die gesamte Serie deshalb in einer Beobachtung verdichten:

Ein Big Ball of Mud ist kein Zustand, in dem nichts mehr funktioniert. Er ist ein Zustand, in dem immer mehr funktionieren muss, damit das System weiterhin verändert werden kann.

Die technische Struktur wird schwerer verständlich. Darauf reagieren Menschen und Organisationen mit zusätzlichem Wissen, Tests, Prozessen, Koordination und Absicherung.

Diese Mechanismen ermöglichen weitere Änderungen.

Dadurch kann das Produkt weiterhin Wert liefern.

Der unmittelbare Druck, die technische Struktur grundsätzlich zu verändern, kann sinken.

Und genau dadurch können die Kompensationsmechanismen selbst zu einem Teil der Stabilität des Systems werden.

Als Synthese lässt sich ein langlebiger Big Ball of Mud deshalb vorsichtig als ein stabilisiertes sozio-technisches Gleichgewicht betrachten.

Das ist keine formale Theorie des Big Ball of Mud. Es ist eine Perspektive auf die Mechanismen, die wir in dieser Serie betrachtet haben.

Technische Struktur beeinflusst Arbeitsweisen. Arbeitsweisen kompensieren technische Struktur. Organisationen passen Prozesse an. Experten erwerben Wissen. Dieses Wissen macht das System weiter betreibbar. Die erfolgreiche Kompensation reduziert teilweise den unmittelbaren Handlungsdruck.

Der Big Ball of Mud überlebt nicht nur, weil niemand ihn verändert. Er kann auch deshalb überleben, weil erstaunlich viele Menschen gelernt haben, seine Folgen zu kompensieren.

Die Kosten verschwinden dadurch nicht; sie können sich lediglich in Menschen, Prozesse, Wissen, Koordination, Zeit und Risiko verlagern.

Wie stark diese Kosten wachsen und ob sie wirtschaftlich problematisch werden, hängt vom konkreten System ab. Es wäre ebenso falsch, daraus ein zwangsläufig exponentielles Kostenmodell abzuleiten wie zu behaupten, jeder Big Ball of Mud müsse irgendwann vollständig versagen.

Viele erreichen diesen Punkt nie, weil sie vorher ersetzt werden. Andere werden schrittweise rekonstruiert, wieder andere noch viele Jahre weiterbetrieben.

Keine moralische Geschichte

Damit ist diese Serie auch keine Geschichte von guten Architekten gegen schlechtes Management.

Sie ist keine Geschichte von disziplinierten Entwicklern gegen jene, die angeblich schlechte Software schreiben.

Sie ist keine Geschichte moderner Frameworks gegen Legacy und auch keine Geschichte, in der Refactoring zwangsläufig der Featureentwicklung moralisch überlegen wäre.

Ein Big Ball of Mud entsteht und überlebt in komplexeren Wechselwirkungen.

Das bedeutet nicht, dass jede Entscheidung gleich gut ist. Es bedeutet nicht, dass niemand Fehler macht. Und es bedeutet nicht, dass individuelle Interessen, Macht oder schlechte technische Entscheidungen aus der Betrachtung verschwinden sollten.

Verantwortung bleibt möglich; nur erklärt Schuldzuweisung das Phänomen schlecht.

Gerade bei langlebigen Systemen ist die interessantere Frage deshalb selten:

Wer hat das verursacht?

Sondern:

Welche technischen und organisatorischen Bedingungen führen dazu, dass dieser Zustand weiterhin reproduziert wird?

Und erst danach:

Welche dieser Bedingungen können und sollen verändert werden?

Bis hierher waren das Fragen über das System.

Am Ende dieser Serie bleibt jedoch noch eine andere Perspektive.

Die des einzelnen Menschen, der in diesem System arbeitet.

Von der Systemfrage zur persönlichen Frage

Ein erfahrener Entwickler oder Architekt kann einen Big Ball of Mud erkennen.

Er kann erklären, warum Grenzen nicht mehr tragen. Er kann Abhängigkeiten visualisieren, Change-Radien untersuchen, Wissensmonopole erkennen und wirtschaftliche Folgen beschreiben. Vielleicht kennt er sogar einen technisch realistischen Weg zu einer besseren Struktur.

Aus dieser Erkenntnis folgt jedoch noch keine persönliche Verpflichtung.

Du bist nicht verpflichtet, jeden Big Ball of Mud zu retten, nur weil du ihn erkannt hast.

Gerade Menschen mit hoher technischer Verantwortung können leicht eine andere Gleichung aufstellen:

Ich sehe das Problem. Also muss ich es lösen.

Die gesamte Serie spricht gegen diese Vereinfachung.

Eine relevante Veränderung benötigt abhängig von ihrem Umfang nicht nur technische Kompetenz. Sie benötigt Mitstreiter, fachliche Entscheidungskompetenz, organisatorischen Handlungsspielraum, Zeit, wirtschaftliche Tragfähigkeit und zumindest eine hinreichende Bereitschaft der Organisation, den entstehenden Veränderungen Raum zu geben.

Ein einzelner Mensch kann für diese Voraussetzungen werben, sie beeinflussen und manche davon selbst schaffen. Vollständig kontrollieren kann er sie jedoch nicht.

Damit verschiebt sich die persönliche Frage.

Zwei Fragen statt einer

Es reicht nicht zu fragen:

Kann dieses System verändert werden?

Eine zweite Frage ist mindestens genauso wichtig:

Kann ich unter den gegebenen Bedingungen sinnvoll an dieser Veränderung mitwirken – und will ich das?

Der erste Teil betrifft den realen Handlungsspielraum.

Werden strukturelle Verbesserungen tatsächlich akzeptiert? Existieren Mitstreiter? Können fachliche Entscheidungen getroffen werden? Gibt es zumindest begrenzte Zeit und organisatorische Legitimation? Haben technische Entscheidungen eine realistische Chance, umgesetzt und anschließend auch erhalten zu werden?

Dabei muss kein großes Modernisierungsprogramm existieren. Auch kleine Veränderungen können wirkungsvoll sein. Entscheidend ist, ob überhaupt ein belastbarer Raum für Veränderung vorhanden ist.

Der zweite Teil ist persönlicher.

Will man die dafür notwendige Energie investieren? Möchte man die technischen, fachlichen und organisatorischen Diskussionen führen? Ist dieses System für die eigene Rolle wichtig genug? Passt die Art der Arbeit zu dem, was man professionell tun möchte?

Darauf gibt es keine allgemeingültige Antwort.

Und gute Entwickler sind nicht verpflichtet, die erste Frage immer mit „ja“ und die zweite immer mit „natürlich“ zu beantworten.

Veränderung, bewusste Akzeptanz und Verlassen können je nach Kontext gleichermaßen legitime professionelle Entscheidungen sein.

Change it, like it or leave it

Der Titel dieses Artikels klingt härter, als die drei Optionen gemeint sind.

Sie sind keine Drohung. Sie sind kein Management-Mantra und keine vollständige Entscheidungstheorie.

Sie geben lediglich Namen für drei grundsätzlich unterschiedliche persönliche Haltungen gegenüber einer Realität, die man selbst nur teilweise kontrolliert.

Change it

Wenn Veränderung realistisch möglich ist und man sich bewusst dafür entscheidet, kann man daran arbeiten.

„Change it“ bedeutet dabei nicht, härter zu arbeiten, mehr Verantwortung persönlich an sich zu ziehen oder zum nächsten Menschen zu werden, ohne den nichts mehr funktioniert.

Die wichtigere Aufgabe besteht darin, die Bedingungen zu verändern, unter denen das System weiterentwickelt wird: Mitstreiter zu gewinnen, gemeinsame Architecture Guidelines zu etablieren, fachliches Verhalten abzusichern, Wissen zu verteilen und kontrollierte Rekonstruktionen dort vorzunehmen, wo sie technisch und wirtschaftlich sinnvoll sind.

Change it heißt nicht, dass das System stärker von dir abhängig werden soll. Im Gegenteil: Gute Veränderung reduziert diese Abhängigkeit.

Like it

Like it bedeutet nicht, schlechte Architektur gutzuheißen.

Es bedeutet, die vorhandenen Rahmenbedingungen bewusst zu akzeptieren.

Vielleicht steht das Produkt kurz vor seiner Ablösung. Vielleicht gibt es keinen tragfähigen Business Case für eine größere Rekonstruktion. Vielleicht priorisiert die Organisation bewusst andere Investitionen. Vielleicht existiert in der eigenen Rolle schlicht nicht genügend Handlungsspielraum.

Dann kann eine professionelle Entscheidung lauten:

Ich kenne die Grenzen dieses Systems und arbeite innerhalb dieser Realität so gut wie möglich.

Akzeptanz ist nicht dasselbe wie Resignation. Sie kann bedeuten, nicht jeden bereits entschiedenen strukturellen Konflikt täglich erneut auszutragen und die eigene Arbeit auf das zu konzentrieren, was innerhalb des vorhandenen Rahmens tatsächlich möglich ist.

Diese Akzeptanz muss allerdings für die Person selbst tragfähig bleiben. Wenn aus ihr dauerhaft Zynismus, völliger innerer Rückzug oder eine Belastung wird, mit der man nicht mehr leben möchte, beschreibt „Like it“ die eigene Situation irgendwann nicht mehr besonders gut.

Leave it

Manchmal passen drei Dinge dauerhaft nicht zusammen: die technische Realität eines Systems, die organisatorischen Rahmenbedingungen und die eigene Vorstellung davon, wie man professionell arbeiten möchte.

Wenn relevante Veränderung realistisch nicht möglich ist und bewusste Akzeptanz ebenfalls nicht trägt, kann das Verlassen eines Projekts, eines Teams, einer Rolle oder einer Organisation eine legitime professionelle Entscheidung sein.

Das ist weder automatisch die richtige Entscheidung noch eine Bewertung der Menschen, die bleiben.

Es ist auch keine Niederlage.

Nicht jedes Problem, das man erkennen kann, muss man zu seinem eigenen Lebensprojekt machen.

Die drei Optionen sind gleich legitim

Es wäre verführerisch, aus den drei Möglichkeiten eine Hierarchie zu machen.

„Change it“ wäre dann die mutige Variante. „Like it“ die schwache. „Leave it“ das Scheitern.

Genau das wäre die falsche Schlussfolgerung.

Alle drei Optionen können abhängig vom Kontext rational und professionell sein.

Wer ein strategisch wichtiges Produkt mit echtem Veränderungsmandat übernimmt, kann gute Gründe für „Change it“ haben.

Wer ein System mit begrenzter Restlebensdauer professionell bis zur Ablösung betreibt, kann mit „Like it“ genau die wirtschaftlich richtige Entscheidung unterstützen.

Und wer dauerhaft in einer Umgebung arbeitet, deren Rahmenbedingungen weder verändert noch mit den eigenen beruflichen Vorstellungen vereinbart werden können, kann gute Gründe haben, sie zu verlassen.

Menschen müssen sich auch nicht für immer einer dieser Kategorien zuordnen.

Heute kann „Change it“ richtig sein und in zwei Jahren aufgrund einer veränderten wirtschaftlichen Situation „Like it“. Umgekehrt kann eine Organisation, die einen Zustand lange bewusst toleriert hat, später ein echtes Veränderungsmandat schaffen.

Die Qualität der Entscheidung hängt nicht davon ab, welche der drei Optionen gewählt wird, sondern davon, ob sie bewusst zur tatsächlichen Situation passt.

Wenn Person und Organisation unterschiedliche Optionen gewählt haben

Besonders schwierig kann die Situation werden, wenn die eigene Entscheidung und die faktische Entscheidung der Organisation nicht zusammenpassen.

Eine Organisation kann einen Big Ball of Mud längst bewusst oder zumindest faktisch akzeptiert haben.

Sie kennt die höheren Änderungskosten. Sie kennt bestehende Risiken. Sie weiß, dass bestimmte Experten benötigt werden. Sie hat vielleicht mehrere Optionen geprüft und entschieden, dass eine größere Rekonstruktion derzeit nicht finanziert wird.

Aus ihrer Perspektive lautet die Antwort damit im Kern:

Like it.

Das muss keine begeisterte Zustimmung zur Architektur sein. Es kann schlicht bedeuten, dass die Organisation bereit ist, die bekannten Nachteile zu tragen, weil andere Investitionen im Moment wichtiger erscheinen.

Ein einzelner Architekt kann gleichzeitig weiterhin jeden Tag mit „Change it“ arbeiten.

Er schreibt das nächste Konzept. Er bereitet die nächste Analyse vor. Er erklärt erneut die Abhängigkeitsstruktur. Er nutzt das nächste Feature für ein Refactoring. Er versucht noch einmal, einen Business Case zu formulieren. Er hofft, mit der nächsten besseren Erklärung endlich das notwendige Mandat zu erzeugen.

All diese Aktivitäten können für sich genommen sinnvoll sein.

Problematisch wird die langfristige Diskrepanz.

Problematisch wird es, wenn man jahrelang glaubt, Option eins gewählt zu haben, während die Organisation längst Option zwei gewählt hat.

Dann arbeitet eine Person nicht mehr nur an einer schwierigen technischen Veränderung. Sie versucht gleichzeitig, eine organisatorische Grundentscheidung zu verändern, ohne dafür möglicherweise das notwendige Mandat zu besitzen.

Das kann auf Dauer erhebliche Frustration erzeugen, ohne dass die Person technisch falsch liegen oder die Organisation zwangsläufig recht haben muss.

Beide können dasselbe System korrekt beurteilen und trotzdem zu unterschiedlichen Entscheidungen darüber kommen, wie viel Veränderung wirtschaftlich, organisatorisch und persönlich sinnvoll ist.

Gerade deshalb ist es wichtig, diese Ebenen auseinanderzuhalten.

Manchmal fehlt nicht das bessere Architekturargument.

Manchmal wurde die Entscheidung bereits auf einer anderen Ebene getroffen.

Kein Rat aus der Ferne

Dieser Artikel kann nicht entscheiden, welche der drei Optionen für ein konkretes Projekt richtig ist.

Dazu sind Systeme, Organisationen und persönliche Situationen zu unterschiedlich.

Es gibt keine sinnvolle Regel wie:

Wenn dein Management dreimal ein Refactoring ablehnt, solltest du gehen.

Ebenso wenig wäre sinnvoll:

Ein guter Architekt kämpft so lange, bis sich die Organisation verändert.

Oder:

Wer ein Legacy-System akzeptiert, hat aufgegeben.

Die drei Optionen sind keine Checkliste und kein Score.

Sie geben lediglich eine Sprache für eine Entscheidung, die sonst leicht unscharf bleibt.

Will ich diese Realität verändern?

Will ich bewusst innerhalb dieser Realität arbeiten?

Oder möchte ich nicht länger Teil dieser Realität sein?

Die Antworten hängen vom Produkt, vom Handlungsspielraum, von wirtschaftlichen Rahmenbedingungen und von den eigenen Prioritäten ab.

Das Ende dieser Serie

Diese Serie begann bei einem System, über dessen Architektur erstaunlich schwer offen zu sprechen sein kann.

Am Anfang stand das Bild einer Organisation, in der gefährliche Bereiche bekannt sind, erfahrene Menschen bestimmte Änderungen absichern und trotzdem immer wieder die Frage entsteht, warum Entwicklung so langsam geworden ist.

Seitdem haben wir den Big Ball of Mud aus unterschiedlichen Richtungen betrachtet.

Wir haben gesehen, dass er kein Synonym für einen Monolithen ist. Dass er aus vielen lokal nachvollziehbaren Entscheidungen entstehen kann. Dass seine Grenzen allmählich ihre Wirkung verlieren. Dass kleine fachliche Änderungen große Verständnisräume erzeugen können. Dass seine Probleme für Stakeholder schwer sichtbar sind. Dass Organisationen an Architektur mitschreiben. Dass Schlüsselpersonen gleichzeitig Lösung und Risiko sein können. Dass Menschen sich an die entstehende Arbeitsumwelt anpassen. Dass schlechte Änderbarkeit wirtschaftlich relevant werden kann – aber nicht zwangsläufig eine Sanierung rechtfertigt. Und dass eine Rekonstruktion nicht zur nächsten Heldengeschichte werden sollte.

Damit bleibt am Ende keine einfache technische Pointe.

Ein Big Ball of Mud kann funktionieren und wirtschaftlichen Wert erzeugen. Er kann außergewöhnliche Experten hervorbringen und Organisationen dazu bringen, erstaunlich wirksame Kompensationsmechanismen zu entwickeln. Er kann Menschen frustrieren oder ihnen eine Umgebung bieten, in der ihre besondere Erfahrung enorm wertvoll wird. Er kann teuer und schwer planbar werden, rekonstruiert oder ersetzt werden – und er kann über viele Jahre weiterbestehen.

Architektur entscheidet darüber nicht allein. Menschen und Organisationen entscheiden mit.

Fazit

Ein Big Ball of Mud ist kein Zustand, in dem nichts mehr funktioniert.

Vielleicht ist gerade das die wichtigste Erkenntnis dieser Serie: Solche Systeme können lange bestehen, weil Entwickler sie verstehen lernen, Experten Unsicherheit kompensieren, Tests und Prozesse Risiken auffangen, Organisationen ihre Arbeitsweisen anpassen und Stakeholder weiterhin realen Wert aus ihnen erhalten.

Das macht ihren strukturellen Zustand nicht irrelevant, erklärt aber, warum er so erstaunlich stabil werden kann.

Ein Big Ball of Mud ist ein sozio-technisches Phänomen.

Technik, Organisation, Ökonomie und Menschen lassen sich darin nicht vollständig voneinander trennen. Code beeinflusst Arbeit. Arbeit kompensiert Code. Wirtschaftliche Entscheidungen bestimmen Handlungsspielräume. Organisatorische Strukturen prägen technische Entscheidungen. Menschen lernen, mit dem daraus entstehenden System umzugehen.

Man kann versuchen, diese Realität zu verändern.

Man kann sie bewusst akzeptieren.

Oder man kann entscheiden, nicht weiter Teil dieser Realität zu sein.

Keine dieser Entscheidungen ist automatisch richtig. Entscheidend ist, ob sie zur tatsächlichen Situation und zu den eigenen Prioritäten passt.

Du kannst die Realität eines Systems verstehen. Aber du musst danach immer noch entscheiden, welche Rolle du selbst in dieser Realität spielen willst.

Change it, like it or leave it.

Vielleicht ist die wichtigste Erkenntnis dieser Serie deshalb nicht, wie man einen Big Ball of Mud erkennt oder rekonstruiert. Vielleicht ist es die Erkenntnis, dass technische Einsicht nicht automatisch persönliche Verpflichtung erzeugt.

Nicht jedes System muss von dir gerettet werden – und nicht jedes System muss überhaupt gerettet werden.

Am Ende bleibt keine universelle technische Antwort. Es bleibt eine bewusste Entscheidung darüber, welche Realität man verändern kann, welche man akzeptieren will – und welche man verlassen sollte.