Die Architektur, über die niemand sprechen möchte

Es dauert selten länger als die erste Woche.

Man ist neu im Projekt, arbeitet sich durch Onboarding-Tickets, Build-Prozesse, Namen und Zuständigkeiten, und irgendwann fällt beiläufig der erste Satz:

„Fass bloß Service X nicht an.“

Man nickt, merkt sich den Namen und weiß in diesem Moment noch nicht, wie oft man diesen Satz in den kommenden Monaten hören wird. Manchmal wird er mit einem kleinen Lächeln gesagt. Manchmal klingt er eher wie eine Warnung.

Ein paar Wochen später erlebt man den ersten Release. Auch der fühlt sich anders an, als man es vielleicht aus anderen Projekten kennt.

Bestimmte Personen sollten an diesem Tag besser verfügbar sein. Nach dem Deployment wird nicht einfach zum nächsten Ticket übergegangen. Man beobachtet Logs, prüft kritische Abläufe und wartet einen Moment länger als gewöhnlich, bevor jemand sagt:

„Sieht gut aus.“

Nicht unbedingt, weil bekannt wäre, dass etwas kaputtgehen muss. Sondern weil niemand mit letzter Sicherheit weiß, was kaputtgehen könnte.

Und irgendwann fällt der andere Satz. Vielleicht vom Management. Vielleicht von einem langjährigen Spezialisten.

„Das hätte ich in einem Tag gemacht.“

Und möglicherweise stimmt das sogar.

Fachlich betrachtet ist die Änderung klein. Ein neues Feld. Eine zusätzliche Bedingung. Eine Anpassung an einer bestehenden Regel. Für jemanden, der genau diesen Teil des Systems seit Jahren kennt, kann das tatsächlich eine Sache von Stunden sein.

Andere Entwickler benötigen dafür mehrere Tage oder Wochen.

Von außen entsteht daraus schnell ein naheliegendes Bild:

Das System ist nicht das Problem. Die Entwickler sind zu langsam.

Nur passt dieses Bild nicht zu dem, was im Projekt gleichzeitig jeder weiß.

Der problematische Service ist bekannt. Die gefährlichen Bereiche sind bekannt. Tester kennen typische Seiteneffekte. Product Owner wissen, welche scheinbar kleinen Tickets regelmäßig eskalieren. Entwickler wissen, welche Änderungen ungewöhnlich viel Analyse benötigen. Und Führungskräfte haben wahrscheinlich schon mehr als eine Präsentation über Technical Debt gesehen.

Das Problem ist nicht verborgen.

Warum bleibt ein solcher Zustand dann über Jahre erstaunlich stabil?

Darum geht es in diesem Artikel.

Noch nicht darum, wie ein Big Ball of Mud technisch genau definiert ist. Das folgt im nächsten Teil.

Hier interessiert mich zunächst etwas anderes:

Warum entwickeln Organisationen die Fähigkeit, mit einem strukturell problematischen System immer weiterzuarbeiten, statt diesen Zustand grundsätzlich zu verändern?

Kein Ausnahmezustand, sondern ein stabilisierter Zustand

Bei einem Big Ball of Mud denkt man zunächst an Chaos: ständige Ausfälle, Feuerwehreinsätze, Produktionsprobleme, ein System unmittelbar vor dem Kollaps.

In der Realität ist der Zustand häufig viel unspektakulärer.

Der Alltag funktioniert. Features werden ausgeliefert. Releases finden statt. Produktionsprobleme werden gelöst. Kunden arbeiten weiter mit dem Produkt.

Das System funktioniert.

Nur benötigt dieses Funktionieren immer mehr Dinge, die außerhalb der eigentlichen Fachlichkeit liegen:

• zusätzliche Tests,
• zusätzliche Reviews,
• zusätzliche Abstimmungen,
• Spezialwissen,
• informelle Regeln,
• besondere Release-Prozesse,
• bestimmte Personen, die vorsorglich hinzugezogen werden,
• und Bereiche, von denen jeder weiß, dass man sie möglichst nicht anfasst.

Eine Organisation hat dann begonnen, sich an ihre Architektur anzupassen.

Das ist zunächst nichts Unprofessionelles. Im Gegenteil.

Wenn Änderungen häufig unerwartete Seiteneffekte erzeugen, sind zusätzliche Tests sinnvoll. Wenn ein kritischer Bereich nur von zwei Personen wirklich verstanden wird, ist es vernünftig, eine davon vor einer Änderung zu fragen. Wenn Releases riskant sind, ist ein besonders sorgfältiger Release-Prozess sinnvoll. Wenn ein bestimmter Service bei jeder Änderung Probleme verursacht, ist Vorsicht angebracht.

Das Problem liegt nicht zwingend in einer einzelnen dieser Entscheidungen.

Das Problem kann im Ergebnis vieler lokal vernünftiger Entscheidungen liegen.

Denn jede erfolgreiche Kompensation macht es etwas leichter, mit dem strukturellen Zustand weiterzuleben:

• Der zusätzliche Test verhindert den Fehler.
• Das Review erkennt den Seiteneffekt.
• Der Spezialist findet den Produktionsfehler.
• Das Release geht durch.
• Der Workaround funktioniert.

Aus Sicht dieses Tages war jede dieser Maßnahmen erfolgreich.

Und genau darin liegt ein Paradox:

Die Organisation wird immer besser darin, die Folgen ihrer Architektur zu kompensieren.

Damit kann gleichzeitig der unmittelbare Druck sinken, die Architektur selbst zu verändern.

Die Kompensation funktioniert – und genau das kann dazu beitragen, dass der strukturelle Zustand bestehen bleibt.

Wenn Abweichung zum normalen Betrieb gehört

Eine interessante organisationssoziologische Perspektive darauf stammt von Diane Vaughan.

Vaughan untersuchte die Entscheidungsprozesse der NASA vor der Challenger-Katastrophe von 1986. In ihrer Analyse beschrieb sie, wie technische Abweichungen schrittweise Bestandteil dessen werden konnten, was innerhalb einer Organisation als akzeptabler Betrieb galt.

Abweichungen traten auf. Sie führten nicht unmittelbar zur Katastrophe. Sie wurden analysiert, erklärt und in bestehende Entscheidungsprozesse eingeordnet. Weitere Missionen verliefen erfolgreich.

Damit konnte sich über die Zeit verändern, was innerhalb der Organisation als akzeptables Risiko wahrgenommen wurde.

Vaughan prägte dafür den Begriff Normalization of Deviance.

Wichtig ist dabei eine Differenzierung.

Vaughans Analyse handelt nicht von Big Balls of Mud. Und ich habe keine belastbare empirische Forschung gefunden, aus der man seriös ableiten könnte:

Big Balls of Mud sind ein Fall von Normalization of Deviance.

Das wäre eine zu starke Übertragung.

Aber das Konzept bietet eine interessante Linse auf bestimmte organisatorische Verhaltensweisen.

Jeffrey Pinto untersuchte später mit Interviews von 21 Projektmanagern, wie sich Normalization of Deviance auch in Projektorganisationen zeigen kann. Dabei ging es unter anderem um Planung, Governance und problematische Praktiken, die über Zeit zu einem scheinbar normalen Teil des Projektalltags werden.

Auf Software übertragen lässt sich daraus zumindest eine Frage ableiten:

Was passiert, wenn ein Release nur mit drei zusätzlichen Sicherheitsmaßnahmen zuverlässig funktioniert?

Zunächst ist das außergewöhnlich. Beim nächsten Release wiederholt man dieselben Maßnahmen. Danach erneut.

Irgendwann fragt niemand mehr:

Warum benötigt unser Release eigentlich diese Sonderbehandlung?

Die operative Frage lautet nur noch:

Wer übernimmt diesmal die zusätzliche Prüfung?

Ähnlich kann aus:

Dieser Service besitzt ein strukturelles Problem.

über Jahre:

Bei diesem Service müssen wir eben vorsichtig sein.

werden.

Das Problem ist weiterhin bekannt. Aber die Reaktion darauf ist Teil des normalen Betriebs geworden.

Die Organisation hat gelernt, damit zu leben.

Technical Debt erzeugt Arbeit, die im Feature nicht vorkommt

Für den zusätzlichen Aufwand solcher Systeme existiert sehr viel direktere Forschung aus dem Software Engineering.

Terese Besker, Antonio Martini und Jan Bosch untersuchten, wie sich Technical Debt auf die tägliche Entwicklungsarbeit auswirkt.

In ihrer longitudinalen Untersuchung dokumentierten 43 Entwickler ihre Arbeit; ergänzt wurde sie durch Interviews und eine unabhängige Replikation.

Im Durchschnitt berichteten die Entwickler, rund 23 Prozent ihrer Entwicklungszeit aufgrund von Technical Debt zu verlieren.

Zusätzlicher Aufwand entstand besonders häufig durch weiteres Testen, aber auch durch Analyse und Refactoring. Die Untersuchung zeigte außerdem, dass bestehende Technical Debt Entwickler teilweise dazu zwang, wiederum neue Technical Debt einzuführen.

Die 23 Prozent beschreiben keinen Big Ball of Mud. Die Untersuchung betrachtet Technical Debt allgemein – und Technical Debt ist in langlebigen Softwaresystemen kaum vollständig vermeidbar. Sie muss nicht einmal grundsätzlich problematisch sein: Technische Schulden können bewusst eingegangen werden, wenn der kurzfristige Nutzen die erwarteten späteren Kosten rechtfertigt. Für diese Serie ist deshalb weniger die konkrete Zahl entscheidend als der von Besker und Kollegen beobachtete Mechanismus: Technical Debt bindet Arbeitszeit, die in der fachlichen Änderung selbst nicht enthalten ist. Bei einem Big Ball of Mud interessiert mich der Zustand, in dem genau dieser zusätzliche Aufwand nicht mehr gelegentlich anfällt, sondern einen erheblichen Teil der täglichen Entwicklungsarbeit bestimmt. Um in der Schuldenmetapher zu bleiben: Das Problem ist nicht mehr, dass Schulden existieren. Die Zinsen beginnen, die eigentliche Entwicklungsleistung aufzufressen.

Damit kann man zwei scheinbar ähnliche Fragen stellen.

Die erste lautet:

Warum brauchen unsere Entwickler sechs Wochen für diese Änderung?

Die zweite lautet:

Warum benötigt unser System für eine fachlich kleine Änderung sechs Wochen menschliche Arbeit?

Die fachliche Größe einer Änderung sagt wenig darüber aus, wie viel Arbeit ein schwer veränderbares System daraus macht.

Die erste Frage sucht die Ursache schnell bei Personen: Erfahrung, Motivation, Produktivität, Seniorität.

Die zweite betrachtet das System.

Vielleicht schreibt niemand sechs Wochen Feature-Code. Stattdessen werden Auswirkungen analysiert, implizite Abhängigkeiten gesucht, Kollegen hinzugezogen, Regressionstests erweitert, historische Sonderfälle rekonstruiert, Bereiche überprüft, die mit der Änderung eigentlich nichts zu tun haben sollten, und zusätzliche Release-Risiken abgesichert.

All das kostet Zeit.

Und vieles davon ist in einem schwer veränderbaren System vollkommen professionelle Arbeit.

Ein langsamer Entwicklungsprozess kann damit paradoxerweise gerade daraus entstehen, dass Entwickler versuchen, verantwortungsvoll mit einem riskanten System umzugehen.

Er bleibt teuer. Aber die Ursache sieht anders aus.

Das System produziert seine Experten

Je länger ein komplexes System existiert, desto wertvoller wird Erfahrung.

Das ist zunächst normal.

Softwareentwicklung ist Wissensarbeit. Nicht jedes relevante Wissen steht in Dokumentationen oder lässt sich vollständig aus dem Code rekonstruieren.

Problematisch wird es, wenn dieses Erfahrungswissen immer größere Teile der fehlenden strukturellen Verständlichkeit ersetzen muss.

Dann weiß eine Person nicht nur besonders viel über einen fachlichen Bereich. Sie weiß beispielsweise auch:

• welche scheinbar unbeteiligte Komponente nach Änderung X getestet werden muss,
• welcher alte Sonderfall nur bei einer bestimmten Datenkonstellation auftritt,
• warum eine merkwürdige Codezeile besser nicht entfernt wird,
• welcher Service offiziell zuständig ist, tatsächlich aber umgangen wird,
• und welche Fehlermeldung in Wirklichkeit auf ein vollkommen anderes Problem hindeutet.

Ein Teil der Architektur befindet sich dann nicht mehr nur im Repository.

Er befindet sich in Köpfen.

Die Software-Engineering-Forschung versucht diese Wissenskonzentration unter anderem über den Truck Factor oder Bus Factor greifbar zu machen.

Avelino, Passos, Hora und Valente analysierten 133 populäre GitHub-Projekte. Bei 65 Prozent der untersuchten Systeme lag der geschätzte Truck Factor bei höchstens zwei Personen. Die Autoren überprüften ihre automatisierten Schätzungen zusätzlich mit Entwicklern aus 67 der untersuchten Projekte.

Das sagt nicht, dass jedes Projekt mit einem niedrigen Truck Factor ein Big Ball of Mud ist.

Auch hervorragend strukturierte Systeme können kritisches Wissen auf wenige Personen konzentrieren.

Aber es zeigt:

Die Abhängigkeit eines Softwareprojekts von wenigen Wissensträgern ist ein reales und messbares Risiko.

Bei einem schwer verständlichen System kann genau dieses Wissen gleichzeitig zum wichtigsten Mechanismus werden, der das System weiterhin beherrschbar erscheinen lässt.

Der Held und das falsche Signal

Der Spezialist, der dieses Wissen besitzt, ist nicht automatisch der Bösewicht dieser Geschichte.

Das Gegenteil kann der Fall sein.

Vielleicht ist er derjenige, der seit Jahren Verantwortung übernimmt, einen Produktionsfehler in zwanzig Minuten findet, nachdem andere einen Tag gesucht haben, bei kritischen Releases erreichbar bleibt, schwierige Änderungen übernimmt und Kollegen hilft.

Immer wieder.

Wenn diese Person sagt:

„Das hätte ich in einem Tag erledigt.“

kann das sachlich vollkommen richtig sein.

Nur folgt daraus nicht automatisch:

Diese Änderung benötigt einen Tag.

Vielleicht bedeutet es lediglich:

Eine bestimmte Person mit jahrelang aufgebautem, teilweise implizitem Wissen kann diese Änderung in einem Tag durchführen.

Das ist etwas anderes.

Die Organisation besitzt dann nicht notwendigerweise die allgemeine Fähigkeit, diese Änderung innerhalb eines Tages vorzunehmen.

Sie besitzt eine Person, die es kann.

Und damit kann die individuelle Stärke eines Spezialisten ein irreführendes organisatorisches Signal erzeugen.

Das System erscheint beherrschbar. Schließlich wird es immer wieder beherrscht. Der Incident wird gelöst. Das Feature wird fertig. Der Release wird gerettet.

Damit können drei verschiedene Dinge gleichzeitig gelernt werden:

• Die Organisation: „Wenn es kritisch wird, holen wir Person X dazu.“
• Das Team: „An diesem Bereich arbeiten wir besser nicht ohne Person X.“
• Person X: „Wenn ich nicht eingreife, wird es möglicherweise problematisch.“

Keine dieser Reaktionen benötigt Egoismus oder Machtstreben. Sie kann vollständig aus Erfahrung, Verantwortungsbewusstsein und Hilfsbereitschaft entstehen.

Gerade deshalb ist diese Dynamik so hartnäckig.

Die außergewöhnliche Leistung einzelner Menschen kann kurzfristig die strukturellen Defizite eines Systems ausgleichen. Und dadurch werden diese Defizite für die Organisation weniger unmittelbar schmerzhaft.

Was diese Abhängigkeit später mit Schlüsselpersonen selbst und mit ihren Teams macht, verdient einen eigenen Artikel.

Hier ist zunächst nur ein Punkt wichtig:

Ein System kann seine strukturellen Schwächen durch menschliche Expertise kompensieren – und dadurch stabiler wirken, als es tatsächlich ist.

Kosten, die auf keiner Rechnung stehen

Technical Debt besitzt noch eine unangenehme Eigenschaft.

Ihre Kosten tauchen selten als eine einzelne Position auf.

Es gibt normalerweise keine Rechnung mit dem Posten:

Architektonische Erosion: 417.000 €

Stattdessen verteilen sich die Kosten:

• Ein Entwickler analysiert einen Tag länger.
• Zwei Kollegen sitzen zusätzlich in einem Termin.
• Ein weiterer Regressionstest wird geschrieben.
• Vor dem Release findet noch ein Review statt.
• Ein Spezialist wird aus einem anderen Thema herausgezogen.
• Eine Änderung wird vorsichtshalber in zwei Releases geteilt.
• Onboarding dauert länger.
• Ein Refactoring wird erneut verschoben.

Jeder einzelne Vorgang lässt sich begründen. Und jeder einzelne Vorgang ist möglicherweise sinnvoll.

Erst in Summe entsteht der wirtschaftliche Effekt.

Besker, Martini und Bosch beschreiben Architectural Technical Debt in ihrer Forschung entsprechend nicht nur als Frage schlechter Codequalität, sondern als etwas, das Wartung und Weiterentwicklung langfristig beeinträchtigen kann.

Die Unsichtbarkeit dieser Kosten ist organisatorisch relevant.

Neue Features besitzen Tickets. Projekte besitzen Budgets. Migrationen besitzen Business Cases.

Die zusätzlichen zwei Stunden Analyse, die heute notwendig wurden, weil eine alte architektonische Grenze nicht mehr existiert, besitzen meistens nichts davon.

Sie verschwinden in der normalen Entwicklungsarbeit.

Und wenn solche Kosten überall ein wenig verschwinden, kann ein strukturelles Problem lange wie eine Sammlung individueller Produktivitätsprobleme aussehen.

Warum man die Schulden trotzdem nicht einfach bezahlt

An diesem Punkt wäre es leicht, die Geschichte auf kurzsichtiges Management zu reduzieren.

Das würde der Realität nicht gerecht.

Technical Debt kann bewusst eingegangen werden. Eine pragmatische technische Lösung kann heute wirtschaftlich sinnvoll sein, wenn sie ein wichtiges Produkt schneller auf den Markt bringt.

Auch bei einem bereits stark erodierten System ist die Alternative zum Weiterbetrieb nicht kostenlos.

Das System besitzt Kunden. Es enthält Daten. Andere Systeme sind davon abhängig. Es bildet Geschäftsprozesse ab. Es muss möglicherweise regulatorische Anforderungen erfüllen. Während einer Migration muss es weiter betrieben werden. Und niemand kann garantieren, dass ein Rewrite schneller, günstiger oder am Ende besser wird.

Die Entscheidung lautet deshalb selten:

Schlechte Architektur oder gute Architektur?

Sie lautet eher:

Investieren wir die nächsten Monate in ein Feature mit erkennbarem Kundennutzen – oder in eine strukturelle Verbesserung, deren Nutzen schwieriger unmittelbar sichtbar zu machen ist?

Das ist eine echte wirtschaftliche Entscheidung.

Freire und Kollegen untersuchten 653 Softwarepraktiker aus sechs Ländern dazu, warum Technical-Debt-Positionen nicht getilgt werden.

Die Gründe lagen häufig nicht im rein technischen Bereich. Die Autoren identifizierten zahlreiche Hindernisse; Gründe für die Nicht-Tilgung waren überwiegend mit Planung und Management verbunden.

Auch daraus folgt nicht:

Management verhindert gute Software.

Es zeigt vielmehr, dass Technical Debt nicht allein durch bessere Programmierung verschwindet.

Sie konkurriert mit Planung, Ressourcen und anderen organisatorischen Zielen.

Damit wird aus der technischen Frage eine ökonomische.

Und genau dieser Punkt wird später in dieser Serie noch deutlich wichtiger werden.

Manchmal wird weiter investiert

Einen weiteren möglichen Erklärungsrahmen liefert die Forschung zur Escalation of Commitment.

Mark Keil, Joan Mann und Arun Rai untersuchten bereits 2000 Software- beziehungsweise Informationssystemprojekte, in denen trotz problematischer Entwicklungen weitere Ressourcen investiert wurden.

Die Autoren fanden dabei nicht einen einzigen einfachen Mechanismus. Verschiedene theoretische Erklärungen trugen dazu bei, eskalierende von nicht eskalierenden Projekten zu unterscheiden.

Auch hier ist Vorsicht wichtig.

Ein jahrzehntealtes produktives System ist kein gescheitertes Softwareprojekt. Und es wäre zu simpel, den Weiterbetrieb eines Legacy-Systems ausschließlich mit Sunk Costs zu erklären.

Es gibt reale Wechselkosten, reale Modernisierungsrisiken, reale Abhängigkeiten und manchmal keine realistische Alternative.

Spannend an dieser Forschung ist eher eine andere Erkenntnis:

Dass ein Weg problematisch geworden ist, bedeutet noch nicht automatisch, dass das Verlassen dieses Weges die rationalere Entscheidung ist.

Organisationen können deshalb sehr lange in Situationen verbleiben, die niemand als ideal empfindet.

Nicht notwendigerweise, weil niemand das Problem versteht, sondern weil alle verfügbaren Alternativen ebenfalls Kosten und Risiken besitzen.

Das macht einen Big Ball of Mud wirtschaftlich so schwer zu behandeln.

Die Frage ist nicht nur:

Wie teuer ist es, dieses System weiterzubetreiben?

Sondern ebenso:

Wie teuer und riskant ist es, damit aufzuhören?

Wenn alle es wissen und trotzdem niemand mehr darüber spricht

Bleibt eine andere Frage.

Was passiert, wenn die Probleme längst bekannt sind?

Vielleicht wurde Service X bereits fünfmal thematisiert. Vielleicht existieren Architekturdiagramme dazu, Tickets, Workshops und Refactoring-Vorschläge. Vielleicht wurde das Problem mehrfach priorisiert und anschließend wieder verschoben.

Dann stellt sich irgendwann nicht mehr die Frage, ob Menschen das Problem erkennen, sondern ob sie es weiterhin ansprechen.

Die organisationspsychologische Forschung beschäftigt sich unter den Begriffen Employee Voice und Employee Silence genau damit.

Elizabeth Morrison fasst Voice als freiwilliges Kommunizieren von Vorschlägen, Bedenken oder Informationen über Probleme an Personen mit höherer organisatorischer Position zusammen. Silence bezeichnet dagegen das Zurückhalten solcher Informationen.

Ein wichtiger Punkt dabei:

Schweigen bedeutet nicht, dass kein Wissen vorhanden ist.

Menschen können ein Problem sehr genau erkennen und sich trotzdem dagegen entscheiden, es erneut anzusprechen.

Ob Beschäftigte ihre Stimme erheben, hängt unter anderem davon ab, ob sie das Ansprechen als sicher und als potenziell wirksam wahrnehmen.

Auch das ist keine spezifische Big-Ball-of-Mud-Forschung. Aber es liefert einen hilfreichen Interpretationsrahmen für eine Beobachtung, die in problematischen Projekten leicht entstehen kann.

Am Anfang heißt es:

„Wir müssen das grundsätzlich lösen.“

Dann vielleicht:

„Wir sollten dafür wirklich Zeit einplanen.“

Später:

„Das Thema steht schon im Backlog.“

Und irgendwann:

„Das bringt sowieso nichts.“

Das Problem ist nicht verschwunden.

Vielleicht hat sich nur die Erwartung verändert, dass erneutes Ansprechen etwas bewirken würde.

Aus einer technischen Erkenntnis kann damit stilles organisatorisches Wissen werden.

Jeder kennt Service X.

Und gerade deshalb muss kaum noch jemand erklären, warum Service X ein Problem ist.

„Wir haben Technical Debt“ ist der angenehmere Satz

Technical Debt ist heute ein vollkommen etablierter Begriff.

Nahezu jedes größere Softwaresystem besitzt sie.

Man kann Technical Debt identifizieren, priorisieren, dokumentieren, in ein Backlog schreiben und vielleicht sogar messen.

Das ist sinnvoll.

Trotzdem gibt es einen sprachlichen Unterschied, der mich an stark erodierten Systemen interessiert.

Der Satz:

„Wir haben viel Technical Debt.“

ist relativ leicht auszusprechen.

Der Satz:

„Wir können bei einer Änderung an einem zentralen Teil unseres Systems ihre Auswirkungen nicht mehr zuverlässig vorhersagen.“

ist unangenehmer.

Denn der zweite Satz handelt nicht mehr ausschließlich von Codequalität.

Er handelt von Kontrolle, von Planbarkeit, von Risiko und von der Fähigkeit einer Organisation, ihr eigenes Produkt gezielt zu verändern.

Damit wird aus einem technischen Thema eine Governance-Frage.

Ich habe keine belastbare Untersuchung gefunden, die zeigen würde, dass Organisationen den Begriff Technical Debt bewusst verwenden, um einen solchen Kontrollverlust sprachlich zu verschleiern.

Das möchte ich auch nicht behaupten.

Aber die begriffliche Unterscheidung ist wichtig.

Ein System kann Technical Debt besitzen und trotzdem hervorragend beherrschbar sein.

Bei einem Big Ball of Mud interessiert mich deshalb eine weitergehende Frage:

Wie sicher kann die Organisation noch sagen, welche Folgen eine Änderung haben wird?

Wenn diese Vorhersagbarkeit verloren geht, reicht die Beschreibung „wir haben Technical Debt“ irgendwann nicht mehr aus.

Dann ist ein Teil der strukturellen Kontrolle verloren gegangen.

Und das einzugestehen ist organisatorisch wesentlich unangenehmer als ein weiteres Ticket im Technical-Debt-Backlog.

Das Paradox der erfolgreichen Kompensation

Damit kommen wir zurück zum Anfang.

Service X wurde nicht verändert, ohne vorher den Spezialisten zu fragen. Das zusätzliche Review fand statt. Die Regressionstests liefen. Der Spezialist war beim Deployment erreichbar. Der Workaround funktionierte. Der Release war erfolgreich.

Aus Sicht dieses Tages war das ein Erfolg.

Und das war es tatsächlich.

Kunden konnten weiterarbeiten. Das Unternehmen konnte liefern. Ein Risiko wurde beherrscht.

Genau deshalb halte ich wenig davon, solche Situationen mit einfachen Schuldzuweisungen zu erklären.

Entwickler können professionell handeln. Architekten können früh und deutlich warnen. Spezialisten können außerordentlich hilfsbereit sein. Product Owner können legitimen Kundennutzen verfolgen. Management kann wirtschaftlich nachvollziehbar priorisieren.

Und trotzdem können all diese lokal vernünftigen Entscheidungen gemeinsam einen Zustand stabilisieren, den niemand bewusst gewählt hätte.

Vielleicht ist genau das eine der interessantesten Eigenschaften eines Big Ball of Mud:

Er überlebt nicht unbedingt deshalb, weil niemand seine Probleme erkennt.

Er kann überleben, weil eine Organisation immer besser darin wird, trotz dieser Probleme weiterzuarbeiten.

Die Kompensationsmechanismen funktionieren:

• Zusätzliche Tests reduzieren Risiken.
• Expertenwissen beschleunigt kritische Änderungen.
• Reviews verhindern Fehler.
• Workarounds halten den Betrieb aufrecht.
• Release-Rituale schaffen Sicherheit.
• Zusätzliche Abstimmung kompensiert fehlende strukturelle Grenzen.

Jede dieser Maßnahmen kann sinnvoll sein.

Und jede erfolgreiche Kompensation kann gleichzeitig ein wenig von dem unmittelbaren Schmerz nehmen, der eine grundlegende Veränderung erzwingen würde.

Das ist kein Naturgesetz.

Nicht jede Organisation entwickelt diese Dynamik. Nicht jede Kompensation verschärft Technical Debt. Und nicht jedes große, alte oder komplexe System ist ein Big Ball of Mud.

Aber mehrere voneinander unabhängige Forschungsstränge machen zumindest Teile dieser Dynamik plausibel:

• Technical-Debt-Forschung zeigt zusätzlichen Entwicklungsaufwand und Schwierigkeiten bei der Tilgung.
• Forschung über Wissenskonzentration zeigt die reale Abhängigkeit von einzelnen Wissensträgern.
• Organisationsforschung zeigt, wie problematische Praktiken normalisiert werden können.
• Forschung über Employee Voice und Silence zeigt, dass bekannte Probleme nicht automatisch dauerhaft ausgesprochen werden.
• Forschung zur Escalation of Commitment zeigt, dass Organisationen problematische technische Wege aus einer Vielzahl psychologischer, organisatorischer und wirtschaftlicher Gründe fortsetzen können.

In meinem eigenen Berufsleben habe ich viele dieser Muster gleichzeitig erlebt.

Das macht meine Erfahrung nicht zum Beweis.

Sie ist der Grund, warum mich die dahinterliegende Frage interessiert.

Nicht:

Wer hat dieses System kaputt gemacht?

Sondern:

Wie kann ein offensichtlich problematisches System über Jahre weiter funktionieren?

Eine mögliche Antwort lautet:

Gerade weil Menschen gelernt haben, seine Probleme jeden Tag erfolgreich auszugleichen.

Bevor wir darüber sprechen können, wie man mit einem solchen Zustand umgeht oder sogar wieder aus ihm herauskommt, müssen wir allerdings zunächst präziser bestimmen, worüber wir eigentlich sprechen.

Denn ein großes System ist noch kein Big Ball of Mud. Ein altes System auch nicht. Und ein Monolith schon gar nicht automatisch.

Darum geht es im nächsten Artikel:

Was ist eigentlich ein Big Ball of Mud?

---

Quellen

Avelino, Guilherme Amaral; Passos, Leonardo; Hora, André; Valente, Marco Tulio: A Novel Approach for Estimating Truck Factors. 24th IEEE International Conference on Program Comprehension (ICPC), 2016. DOI: 10.1109/ICPC.2016.7503718.

Besker, Terese; Martini, Antonio; Bosch, Jan: Managing Architectural Technical Debt: A Unified Model and Systematic Literature Review. Journal of Systems and Software 135, 2018, S. 1–16. DOI: 10.1016/j.jss.2017.09.025.

Besker, Terese; Martini, Antonio; Bosch, Jan: Software Developer Productivity Loss Due to Technical Debt – A Replication and Extension Study Examining Developers’ Development Work. Journal of Systems and Software 156, 2019, S. 41–61. DOI: 10.1016/j.jss.2019.06.004.

Freire, Sávio; Rios, Nicolli; Pérez, Boris; Castellanos, Camilo; Correal, Darío; Ramač, Robert; Mandić, Vladimir; Taušan, Nebojša; López Herrera, Gustavo; Pacheco Hernández, Alexia; Mendonça, Manoel; Falessi, Davide; Izurieta, Clemente; Seaman, Carolyn; Spínola, Rodrigo: Software Practitioners’ Point of View on Technical Debt Payment. Journal of Systems and Software 196, 2023, 111554. DOI: 10.1016/j.jss.2022.111554.

Keil, Mark; Mann, Joan; Rai, Arun: Why Software Projects Escalate: An Empirical Analysis and Test of Four Theoretical Models. MIS Quarterly 24(4), 2000, S. 631–664. DOI: 10.2307/3250950.

Morrison, Elizabeth W.: Employee Voice and Silence. Annual Review of Organizational Psychology and Organizational Behavior 1, 2014, S. 173–197. DOI: 10.1146/annurev-orgpsych-031413-091328.

Pinto, Jeffrey K.: Project Management, Governance, and the Normalization of Deviance. International Journal of Project Management 32(3), 2014, S. 376–387. DOI: 10.1016/j.ijproman.2013.06.004.

Vaughan, Diane: The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA. University of Chicago Press, Chicago, 1996.