Was ein Big Ball of Mud mit Menschen macht

Ein Big Ball of Mud lässt sich technisch beschreiben. Man kann Abhängigkeiten zählen, Zyklen visualisieren, globalen Zustand suchen, Change-Radien untersuchen und nachvollziehen, warum eine scheinbar lokale Änderung an einer ganz anderen Stelle Seiteneffekte erzeugt. Für Menschen, die jahrelang an einem solchen System arbeiten, ist er jedoch mehr als eine technische Struktur: Er ist ihre tägliche Arbeitsumwelt.

Entwickler lernen in ihr nicht nur APIs, Frameworks und fachliche Regeln. Sie lernen auch, welche Änderungen riskant sind, welche Bereiche kaum jemand vollständig versteht, wen sie vor einer bestimmten Änderung fragen müssen, welche Probleme besser umgangen werden und welche Regeln zwar nirgendwo dokumentiert sind, aber trotzdem gelten. Damit verschiebt sich die Perspektive von der Frage, wie ein Big Ball of Mud Software verändert, zu einer anderen:

Was macht eine dauerhaft schwer verständliche und schwer veränderbare Softwareumgebung mit den Menschen, die jahrelang in ihr arbeiten?

Menschen arbeiten nicht über Jahre in einer solchen Umwelt, ohne sich an sie anzupassen. Das ist zunächst weder gut noch schlecht. Anpassung ist eine normale Reaktion auf Arbeitsbedingungen, und unterschiedliche Menschen bringen unterschiedliche Erfahrungen, Fähigkeiten, Erwartungen und professionelle Werte mit. Entsprechend unterschiedlich kann dieselbe technische Umgebung erlebt werden.

Genau darin liegt eine zweite Ebene des Big Ball of Mud. Er besitzt irgendwann nicht mehr nur technische Strukturen. Um ihn herum entstehen soziale Normen darüber, wie man in ihm arbeitet. Dieser Artikel beschreibt drei idealtypische Reaktionsmuster darauf: den Navigator, den Angepassten oder Resignierten und den strukturorientierten Veränderer. Sie sind keine Persönlichkeitstypen. Dieselbe Person kann im Laufe ihrer beruflichen Biografie mehrere dieser Muster zeigen oder zwischen ihnen wechseln.

Die arbeitspsychologische Forschung untersucht Big-Ball-of-Mud-Systeme nicht als eigene Kategorie. Allgemeine Befunde über Burnout, Person–Environment Fit, Employee Voice oder Organizational Socialization dürfen deshalb nicht als direkte Befunde über schlechte Softwarearchitektur ausgegeben werden. Die Forschung zu Burnout in der Softwareentwicklung selbst ist inzwischen umfangreicher; eine systematische Mapping-Studie von Tulili, Capiluppi und Rastogi identifizierte 92 einschlägige Arbeiten. Ein spezifischer kausaler Mechanismus „Big Ball of Mud führt zu Burnout“ ist damit jedoch nicht etabliert.

Die wissenschaftlich belastbarere Frage lautet deshalb: Welche Arbeitsbedingungen können in langlebigen Big-Ball-of-Mud-Systemen entstehen – und was weiß die Arbeits- und Organisationspsychologie über vergleichbare Bedingungen?

Drei mögliche Reaktionen auf dieselbe Umwelt

Ein schwer verständliches System stellt nicht für jeden Menschen dieselbe Arbeitsumwelt dar. Das Konzept des Person–Environment Fit beschäftigt sich seit Jahrzehnten damit, wie gut Eigenschaften, Bedürfnisse und Werte einer Person zu ihrer Arbeitsumgebung passen. Die Meta-Analyse von Kristof-Brown, Zimmerman und Johnson bündelte 172 Studien mit 836 Effektgrößen und untersuchte verschiedene Formen dieser Passung sowie Zusammenhänge mit Einstellungen, Leistung, Rückzugsverhalten, Belastung und Verbleib.

Für einen Big Ball of Mud ist daran vor allem eine Unterscheidung hilfreich: Die Frage, ob ein Mensch in einer Umgebung gut funktioniert, ist nicht identisch mit der Frage, ob diese Umgebung technisch gut gestaltet ist. Die folgenden drei Muster sind deshalb keine drei Sorten von Entwicklern, sondern drei mögliche Arten, auf dieselbe Arbeitsumwelt zu reagieren.

Dieselbe technische Umgebung kann von Menschen sehr unterschiedlich erlebt und beantwortet werden.

Der Navigator

Manche Menschen können in einem schwer strukturierten System erstaunlich erfolgreich arbeiten. Nach einigen Jahren besitzen sie ein detailliertes mentales Modell, erkennen Fehlerbilder, die Außenstehende kaum einordnen können, und kennen nicht nur den offiziellen Aufbau, sondern auch historische Sonderfälle und implizite Kopplungen. Sie wissen, welche vermeintlich unabhängigen Komponenten tatsächlich zusammenhängen, welche Änderungen typischerweise Nebenwirkungen erzeugen und bei welchem Problem welche Person gefragt werden sollte.

In einer Umgebung, in der explizite Grenzen nur wenig Orientierung geben, gewinnt die Fähigkeit an Wert, implizite Zusammenhänge zu erkennen und Unsicherheit praktisch zu bewältigen. Die Fähigkeiten des Navigators passen damit vergleichsweise gut zu einer Arbeitsumwelt, in der Navigation wichtiger geworden ist als explizite Struktur. Das bedeutet weder, dass diese Person Chaos „liebt“, noch dass die technische Struktur gesund sein muss.

Ein Mensch kann einen guten Fit mit einer schlechten Struktur besitzen.

Gerade diese Trennung ist wichtig. Für den Navigator kann ein komplizierter Incident ein interessantes Problem sein, während derselbe Incident für eine andere Person vor allem ein weiteres Hindernis in einem System darstellt, dessen Ursachen sie seit Jahren nicht verändern kann. Weil der eigene Arbeitsalltag funktioniert, muss der Navigator auch keinen besonders starken subjektiven Veränderungsdruck empfinden. Eine tiefgreifende Reorganisation kann aus seiner Perspektive zunächst sogar bedeuten, ein über Jahre aufgebautes und sehr wirksames mentales Modell durch ein neues ersetzen zu müssen.

Mit der Zeit kann ein Navigator zur Schlüsselperson werden. Das muss nicht passieren und wurde im vorherigen Artikel bereits ausführlicher betrachtet. Für diesen Artikel genügt die Beobachtung, dass ein Big Ball of Mud Fähigkeiten außerordentlich wertvoll machen kann, die in einem expliziter strukturierten System wesentlich weniger exklusiv wären.

Der Angepasste oder Resignierte

Ein zweites Reaktionsmuster sieht von außen manchmal wie Desinteresse an Architektur oder Widerstand gegen Veränderung aus. Die betreffende Person muss den Zustand des Systems keineswegs gut finden. Vielleicht hat sie früher selbst Refactorings vorgeschlagen, Modernisierungsinitiativen begleitet oder versucht, Verantwortlichkeiten zu klären. Mit der Zeit kann sie jedoch gelernt haben, dass große Veränderungsversuche hohe Kosten erzeugen und ihre ursprünglichen Ziele nur selten erreichen.

Dann verändert sich nicht zwingend die technische Einschätzung, sondern die Strategie. Statt grundsätzliche Ursachen anzugehen, arbeitet die Person stärker über bekannte und als vergleichsweise sicher wahrgenommene Wege. Sie verwendet vorhandene Workarounds, vermeidet bestimmte Komponenten, reduziert den Umfang riskanter Änderungen und investiert weniger Energie in Vorhaben, deren Erfolg sie inzwischen für unwahrscheinlich hält. Sätze wie „Das haben wir schon versucht“, „Mach einfach das Ticket“ oder „Fass den Bereich lieber nicht an“ können in diesem Kontext Zynismus ausdrücken, aber ebenso das Ergebnis nüchterner Erfahrungswerte sein.

Anpassung kann von gesundem Pragmatismus bis zu tiefer Resignation reichen.

Diese Unterscheidung ist wichtig, weil eine Softwareorganisation nicht bei jeder Änderung das gesamte System neu strukturieren kann. Erfahrene Entwickler müssen Risiken einschätzen und bewusst entscheiden, wann ein Workaround ökonomisch vernünftig ist. Pragmatismus ist deshalb kein Symptom eines Big Ball of Mud. Interessant wird es dort, wo die Erwartung sinkt, dass strukturelle Veränderungsversuche überhaupt noch Wirkung entfalten.

Die Forschung zu Cynicism About Organizational Change liefert dafür einen passenden Begriff. Reichers, Wanous und Austin beschrieben Zynismus gegenüber Veränderung unter anderem als Pessimismus bezüglich zukünftiger Veränderungserfolge und fanden als möglichen Entstehungskontext eine Geschichte von Veränderungsprogrammen, die nicht konsistent erfolgreich waren. Spätere Arbeiten derselben Forschungsrichtung stützen die Vorstellung, dass solcher Zynismus nicht ausschließlich dispositionell sein muss, sondern aus Erfahrungen mit Veränderungen lernen kann.

Resignation kann von außen wie Widerstand gegen Veränderung aussehen. Sie kann aber auch das Ergebnis wiederholt erfolgloser Veränderungsversuche sein.

Der Satz „Das haben wir schon versucht“ enthält dann möglicherweise mehr Organisationsgeschichte als Widerstand.

Der strukturorientierte Veränderer

Das dritte Muster entspricht zunächst ziemlich genau dem, was Architekturlehrbücher häufig erwarten. Eine Person kennt Systeme, in denen Verantwortlichkeiten relativ klar waren, Änderungen überwiegend lokal blieben, Architekturregeln tatsächlich wirkten und technische Probleme zumindest prinzipiell an ihren Ursachen bearbeitet werden konnten. In einem Big Ball of Mud versucht sie deshalb, Struktur herzustellen: Sie entfernt Zyklen, führt Tests ein, hinterfragt Abhängigkeiten, versucht Ownership zu klären, begrenzt öffentliche Schnittstellen und sucht nach fachlichen Grenzen.

Viele dieser Diagnosen können technisch vollkommen korrekt sein. Ein langlebiger Big Ball of Mud ist jedoch längst nicht mehr ausschließlich ein Codeproblem. Ein Zyklus kann bestehen bleiben, weil zwei Teams unterschiedliche Verantwortlichkeiten besitzen. Eine schlechte API kann einen ungeklärten fachlichen Prozess spiegeln. Ein globaler Service kann mehrere historische Organisationsgrenzen überbrücken. Eine sinnvolle Migration kann gleichzeitig mit Lieferverpflichtungen, fehlendem Mandat, Schlüsselpersonen, veralteter Infrastruktur und früher gescheiterten Modernisierungsprogrammen kollidieren.

Der strukturorientierte Entwickler arbeitet damit nicht nur gegen Abhängigkeiten im Code, sondern gegen ein Geflecht technischer und organisatorischer Randbedingungen, dessen Veränderung erheblich mehr Entscheidungsmacht erfordern kann, als seine Rolle besitzt. Genau hier kann eine besondere Form des Misfit entstehen: Die Person erkennt das Problem möglicherweise sehr klar, empfindet Verantwortung dafür und kennt technisch plausible Alternativen, erlebt aber wiederholt, dass ihre tatsächliche Kontrolle nicht ausreicht, um die Ursachen nachhaltig zu verändern.

Der strukturorientierte Entwickler kann besonders belastet werden, wenn er Probleme klar erkennt, Verantwortung empfindet und gleichzeitig dauerhaft erlebt, dass seine Einflussmöglichkeiten nicht ausreichen, um ihre Ursachen zu verändern.

Das ist keine Aussage darüber, dass strukturorientierte Menschen zwangsläufig stärker leiden. Es ist eine Mechanismushypothese. Arbeitspsychologisch ist sie jedoch anschlussfähig, weil sowohl geringe Job Control als auch Misfit zwischen Person und Arbeitsumgebung zu gut untersuchten Faktoren beruflicher Beanspruchung gehören. Die Meta-Analyse von Park und Kollegen untersuchte 71 unabhängige Stichproben aus 66 Studien mit insgesamt 48.528 Personen und fand deutliche Zusammenhänge zwischen Job Control und Burnout-Dimensionen. Die breitere Person–Environment-Fit-Forschung verbindet schlechtere Passung ebenfalls mit Belastung und Rückzugsreaktionen.

Erschöpfung ist nicht nur eine Frage der Arbeitsstunden

Bei Burnout liegt eine gefährliche Vereinfachung nahe: Wer nicht ständig Überstunden macht, könne eigentlich auch nicht ausbrennen. Die Forschung zeichnet ein wesentlich komplexeres Bild. Maslach und Leiter beschreiben Burnout über Erschöpfung, Zynismus beziehungsweise Distanzierung und reduzierte professionelle Wirksamkeit. Ihr Areas-of-Worklife-Modell betrachtet sechs Bereiche, in denen das Verhältnis zwischen Mensch und Arbeit relevant wird: Workload, Control, Reward, Community, Fairness und Values. Das Job Demands–Resources Model betrachtet wiederum das Verhältnis zwischen Anforderungen einer Arbeit und den Ressourcen, die zur Bewältigung dieser Anforderungen zur Verfügung stehen.

Arbeitsmenge ist in diesen Modellen wichtig, aber sie ist nur ein Teil des Bildes. Eine systematische Übersichtsarbeit mit Meta-Analyse von Aronsson und Kollegen konzentrierte sich auf prospektive beziehungsweise vergleichbare Studien und fand moderat starke Evidenz dafür, dass höhere Job Control mit geringerer späterer emotionaler Erschöpfung zusammenhing; auch geringe Unterstützung zeigte einen entsprechenden Zusammenhang. Für weitere Faktoren wie hohe Anforderungen, hohe Arbeitslast, geringe Belohnung, Jobunsicherheit und wahrgenommene Gerechtigkeit berichteten die Autoren begrenztere Evidenz. Alarcons Meta-Analyse kommt aus einer anderen theoretischen Perspektive zu einem ähnlichen Gesamtbild: Höhere Anforderungen, geringere Ressourcen und ungünstigere arbeitsbezogene Einstellungen hängen mit Burnout zusammen.

Auch die Softwareentwicklung bildet dabei keine grundsätzliche Ausnahme. Singh, Suar und Leiter untersuchten 372 Softwareentwickler und fanden unter anderem Zusammenhänge von Burnout mit Rollenunklarheit, Rollenkonflikten, Zeitdruck, unregelmäßigen Arbeitszeiten und mangelnder Kooperation. Die systematische Mapping-Studie von Tulili, Capiluppi und Rastogi bündelt eine deutlich breitere Software-Engineering-Literatur und identifiziert unter anderem Job Demands, Überlastung und Spannungen am Arbeitsplatz als wiederkehrende Themen.

Das erlaubt keine Gleichsetzung mit einem Big Ball of Mud. Es erlaubt aber eine präzisere Hypothese: Ein langlebiger Big Ball of Mud kann Arbeitsbedingungen erzeugen, die bekannten Belastungsfaktoren ähneln. Auswirkungen von Änderungen bleiben schwer vorhersehbar, technische Hindernisse treten wiederholt auf, Verantwortung und Entscheidungsmacht können auseinanderfallen, Ownership bleibt unklar, Workarounds erzeugen Rework, professionelle Qualitätsansprüche können mit der tatsächlich möglichen Arbeitsweise kollidieren und die wahrgenommene Wirksamkeit eigener Verbesserungsversuche kann sinken.

Ein Big Ball of Mud kann Arbeitsbedingungen erzeugen, die aus der Burnout-Forschung als relevante Belastungsfaktoren bekannt sind.

Die entscheidende Warnung lautet deshalb nicht, dass ein Big Ball of Mud Burnout verursache. Sie lautet, dass Arbeitsbelastung nicht auf Arbeitsmenge reduziert werden darf. Geringe Kontrolle, Wertekonflikte, wiederkehrende Hindernisse und erlebte Wirkungslosigkeit gehören ebenfalls in die Betrachtung.

Erschöpfend ist nicht nur, zu viel arbeiten zu müssen. Erschöpfend kann auch sein, ein Problem dauerhaft zu sehen, Verantwortung dafür zu empfinden und gleichzeitig zu erleben, dass die eigene Arbeit seine Ursachen kaum verändern kann.

Dieser Satz ist eine Synthese der beschriebenen Forschung und der Übertragung auf Softwarearchitektur, kein experimentell belegter Kausalsatz über Big-Ball-of-Mud-Systeme.

Belastung entsteht nicht ausschließlich durch Arbeitsmenge. Auch geringe Kontrolle, Wertekonflikte und wiederholt erlebte Wirkungslosigkeit gehören zu bekannten psychosozialen Belastungsfaktoren.

Eine persönliche Beobachtung – und ihre Grenze

In einem persönlich erlebten Projekt kam es innerhalb beteiligter Entwicklungsteams zu mehreren Burnout-Ausfällen. Auch beim Autor selbst wurden mit der Zeit deutliche Belastungssymptome spürbar. Auffällig war aus der eigenen Perspektive, dass die Belastung nicht primär aus außergewöhnlich langen Arbeitszeiten entstand. Belastend war vielmehr die wiederholte Erfahrung, strukturelle Probleme klar zu erkennen, ihre Folgen im Alltag zu erleben, Verantwortung für Verbesserungen zu empfinden und technisch plausible Ansätze zu kennen – und trotzdem kaum in der Lage zu sein, die Ursachen nachhaltig zu verändern.

Diese Beobachtung beweist keinen kausalen Zusammenhang zwischen einem Big Ball of Mud und Burnout. Auch mehrere Fälle innerhalb desselben Projekts tun das nicht. Dafür existieren zu viele mögliche Einflussfaktoren, und persönliche Beobachtungen können weder kontrollierte Vergleiche noch longitudinale Forschung ersetzen. Sie eröffnen aber eine arbeitspsychologisch relevante Frage:

Welche Belastung entsteht, wenn Verantwortung, professioneller Anspruch und tatsächliche Einflussmöglichkeiten dauerhaft auseinanderfallen?

Genau an dieser Stelle werden Forschung zu Job Control, Person–Environment Fit und Values Congruence interessant.

Wenn professioneller Anspruch und Arbeitsrealität auseinanderfallen

Das Areas-of-Worklife-Modell behandelt Values ausdrücklich als eigenen Bereich neben Workload und Control. Gemeint ist die Passung zwischen dem, was eine Person in ihrer Arbeit als wichtig empfindet, und dem, was die konkrete Arbeitsumgebung tatsächlich ermöglicht oder verlangt. Maslach und Leiter beschreiben solche Mismatches als Teil des organisatorischen Kontexts von Burnout. In einer longitudinalen Untersuchung mit 466 Beschäftigten zeigten sie zudem, dass Inkongruenzen in Bereichen der Arbeitsumwelt mit späteren Bewegungen in Richtung Burnout oder Engagement zusammenhingen; besonders relevant war in dieser Studie unter anderem der Bereich Fairness.

Auch andere Berufsgruppen zeigen, dass Werte nicht einfach in Workload aufgehen. Leiter, Frank und Matheson analysierten 2.536 kanadische Ärztinnen und Ärzte, die mehr als 35 Stunden pro Woche arbeiteten. In dieser Querschnittsstudie leisteten sowohl ein handhabbares Arbeitspensum als auch Values Congruence eigenständige Beiträge zur Vorhersage von Erschöpfung und Zynismus; Values Congruence hing darüber hinaus mit professioneller Wirksamkeit zusammen. Das ist kein Beleg für Softwarearchitektur, aber ein gutes Beispiel dafür, dass berufliche Belastung nicht vollständig durch Arbeitsstunden erklärt werden kann.

Die Übertragung auf Software bleibt theoretisch. Ein strukturorientierter Entwickler kann sein professionelles Selbstverständnis beispielsweise darin sehen, Ursachen zu beseitigen und Systeme nachhaltig verständlich zu machen. Eine Organisation kann gleichzeitig aus legitimen wirtschaftlichen Gründen verlangen, zunächst den nächsten Incident zu beheben und das nächste Feature zu liefern. Diese Ziele widersprechen sich nicht zwangsläufig; Software muss liefern und gleichzeitig gepflegt werden. Ein Misfit kann jedoch entstehen, wenn die zweite Anforderung über lange Zeit verhindert, dass die erste überhaupt noch verfolgt werden kann.

Dann geht es nicht mehr ausschließlich um die technische Frage, ob ein Refactoring umgesetzt wird. Der Konflikt kann das professionelle Selbstverständnis berühren: Was bedeutet gute Arbeit – und darf ich diese Arbeit unter den gegebenen Bedingungen überhaupt leisten? Ein Navigator kann in demselben System erleben, dass er schwierige Probleme zuverlässig gelöst bekommt, während ein strukturorientierter Veränderer täglich Symptome eines Problems bearbeitet, dessen Ursache er nicht verändern kann. Beide Erfahrungen können gleichzeitig wahr sein.

Wenn Voice ihre erwartete Wirkung verliert

Strukturorientierte Veränderung beginnt häufig mit Voice. In der Organisationsforschung bezeichnet Employee Voice das freiwillige Äußern von Vorschlägen, Bedenken oder Informationen über arbeitsbezogene Probleme mit dem Ziel, einen bestehenden Zustand zu verbessern. In Softwareteams kann das sehr alltäglich klingen: „Wir sollten diesen Bereich anders schneiden“, „Diese Abhängigkeit müssen wir auflösen“ oder „Hier brauchen wir klare Ownership“. Solche Aussagen sind zunächst das Gegenteil von Resignation.

Ob Menschen Voice wiederholen, hängt jedoch auch davon ab, ob sie erwarten, dass ihre Stimme etwas bewirken kann und ob das Ansprechen von Problemen als sinnvoll und sicher erlebt wird. Die Forschung zu Organizational Silence beschäftigt sich entsprechend mit Situationen, in denen relevante Informationen oder Bedenken nicht geäußert werden. Besonders passend für die hier diskutierte Dynamik ist eine neuere experimentelle Arbeit von Andrieu und Kollegen: In zwei Experimenten mit insgesamt 654 Teilnehmenden führte wiederholt geringe wahrgenommene Wirksamkeit von Voice dazu, dass spätere Möglichkeiten, erneut Voice zu zeigen, seltener genutzt wurden; zugleich berichteten die Teilnehmenden stärkere Hilflosigkeit. Die Autoren diskutieren diese Entwicklung als acquiescent silence im Rahmen eines Learned-Helplessness-Ansatzes.

Das ist weder ein Experiment mit Softwarearchitekten noch ein Big-Ball-of-Mud-Befund. Es zeigt aber, dass eine Entwicklung von wiederholt geringer wahrgenommener Wirkung zu weniger späterer Voice psychologisch plausibel und empirisch untersuchbar ist. Das ältere Exit–Voice–Loyalty–Neglect-Modell beschreibt ebenfalls unterschiedliche mögliche Reaktionen auf Unzufriedenheit. Diese Kategorien bilden keine feste Abfolge und schon gar keine Handlungsempfehlung; sie helfen lediglich zu verstehen, warum Menschen auf dieselbe Situation mit Ansprechen, Abwarten, Rückzug oder Verlassen reagieren können.

Damit wird eine vorschnelle Zuschreibung problematisch. Wenn ein langjähriger Mitarbeiter heute als „veränderungsfeindlich“ erscheint, kennt das Team möglicherweise sein aktuelles Verhalten, aber nicht die Geschichte der Veränderungsversuche, die diesem Verhalten vorausging.

Die drei Muster können Stationen derselben Biografie sein

Ein Entwickler kann als strukturorientierter Veränderer in ein Projekt kommen, Zyklen beseitigen, Verantwortlichkeiten aufbauen, Tests nachziehen und technische Regeln etablieren. Nach mehreren Jahren wird er möglicherweise pragmatischer und unterscheidet genauer, welche Probleme tatsächlich veränderbar erscheinen. Bestimmte Diskussionen beginnt er nicht mehr, und manche Workarounds akzeptiert er, weil ihre Beseitigung bereits mehrfach gescheitert ist. Das kann vernünftige Erfahrungsbildung sein; es kann sich aber auch in Richtung Zynismus oder Resignation verschieben, wenn die Erwartung struktureller Wirksamkeit dauerhaft sinkt.

Gleichzeitig lernt dieselbe Person das bestehende System immer besser kennen. Sie sammelt historische Erklärungen, entdeckt verborgene Zusammenhänge und kennt irgendwann genau jene sicheren Wege, die neue Teammitglieder erst mühsam lernen müssen. Nach vielen Jahren kann der strukturorientierte Veränderer von damals deshalb einer der besten Navigatoren des Systems sein.

Der strukturorientierte Veränderer von gestern kann der Navigator von morgen sein.

Daraus folgt keine zwangsläufige Entwicklung. Menschen können dauerhaft Veränderer bleiben, Systeme können sich tatsächlich verbessern und Arbeitsbedingungen können sich grundlegend ändern. Entscheidend ist nur die Richtung der Betrachtung: Normalerweise fragen wir, wie Menschen Software verändern. Bei einem langlebigen Big Ball of Mud muss zusätzlich gefragt werden, wie die Softwareumgebung langfristig Erwartungen und Verhalten der Menschen verändert, die in ihr arbeiten.

Die Reaktionsmuster sind keine festen Persönlichkeitstypen. Menschen können ihre Erwartungen und ihr Verhalten über Jahre an die bestehende Umwelt anpassen.

Ein System besitzt irgendwann eine soziale Gebrauchsanweisung

Die Anpassung endet nicht bei langjährigen Mitarbeitern, denn neue Entwickler betreten kein neutrales System. Die Forschung zur Organizational Socialization untersucht, wie Newcomer lernen, in einer Organisation handlungsfähig zu werden. Die Meta-Analyse von Bauer und Kollegen nutzte 70 unabhängige Stichproben und zeigte die Bedeutung von Anpassungsdimensionen wie Rollenklärung, Selbstwirksamkeit und sozialer Akzeptanz für spätere Arbeitserfahrungen und Verbleib.

Diese Forschung untersucht keine Big-Ball-of-Mud-Systeme; die folgende Übertragung ist daher ausdrücklich theoretisch. In einem gut strukturierten Softwaresystem kann ein großer Teil der Orientierung durch den Code selbst vermittelt werden. Modulgrenzen, Typen, APIs, Tests und konsistente Patterns erklären zumindest einen Teil der Regeln. Je weniger zuverlässig diese technischen Strukturen Orientierung bieten, desto stärker kann die Organisation andere Formen der Wissensvermittlung benötigen.

Neue Entwickler lernen dann nicht nur, welche API sie aufrufen müssen. Sie lernen auch, welche Person bei welchem Subsystem gefragt wird, welche Bereiche trotz scheinbar klarer Zuständigkeit gemeinsam geändert werden müssen, welche Komponenten besser nicht angefasst werden, welche Tests als zuverlässig gelten, welche historischen Workarounds akzeptiert sind und bei welchen Entscheidungen eine formale Ownership von einer faktischen Entscheidungshoheit abweicht.

Ein Big Ball of Mud hat irgendwann nicht nur eine technische Architektur. Um ihn herum entsteht eine soziale Gebrauchsanweisung.

Diese Gebrauchsanweisung muss nicht dysfunktional sein. Im Gegenteil: Ohne solche informellen Regeln könnte ein schwer verständliches System möglicherweise kaum noch wirtschaftlich betrieben werden. Problematisch ist vielmehr die Verschiebung dessen, wo Wissen gespeichert wird.

Je weniger der Code seine Regeln verständlich ausdrückt, desto mehr muss das Team informelle Regeln darüber lernen, wie man mit ihm arbeitet.

Diese Regeln werden selten vollständig dokumentiert. Sie werden in Reviews erklärt, in Pairing-Sessions weitergegeben, in Incidents entdeckt und von erfahrenen Kollegen korrigiert. Der eigentliche Onboarding-Prozess besteht dann nicht nur darin, die Software zu lernen, sondern auch zu lernen, wie die bestehende Organisation gelernt hat, mit dieser Software zu leben.

Technisch chaotisch, sozial stabil

Damit entsteht ein scheinbarer Widerspruch. Das technische System kann hochgradig unübersichtlich sein: Verantwortlichkeiten sind schwer nachvollziehbar, Abhängigkeiten verlaufen in unerwartete Richtungen, Sonderfälle akkumulieren und lokale Änderungen können entfernte Folgen besitzen. Das soziale System darum kann gleichzeitig erstaunlich geordnet sein, weil die Beteiligten wissen, wer gefragt werden muss, welche Teile bei einem Release besondere Aufmerksamkeit brauchen, welche Refactorings kaum Aussicht auf Unterstützung haben, welche Workarounds funktionieren und was „normalerweise“ kaputtgeht.

Die Ordnung liegt dann nicht primär im Code. Ein Teil der Stabilität kommt aus Erfahrung, Routinen, Schlüsselpersonen, gemeinsam erlernten Vermeidungsstrategien und Erwartungen darüber, was überhaupt noch verändert werden kann. Genau das erklärt, warum manche langlebigen Systeme von außen nahezu unbeherrschbar aussehen und im täglichen Betrieb trotzdem erstaunlich lange funktionieren.

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

Diese soziale Stabilität ist nicht automatisch positiv. Sie kann schlicht bedeuten, dass Menschen gelernt haben, technische Instabilität zuverlässig zu kompensieren.

Je weniger das System seine Regeln selbst ausdrückt, desto mehr kann die Organisation informelle Regeln darüber entwickeln, wie man trotzdem darin arbeitet.

Wenn das System Verhaltensweisen unterschiedlich belohnt

In Diskussionen über schlechte Legacy-Systeme tauchen schnell problematische Zuschreibungen auf: „Die guten Entwickler gehen“ oder umgekehrt „Nur schlechte Entwickler akzeptieren so etwas“. Beides vermischt die Qualität von Menschen mit der Passung zu einer konkreten Arbeitsumwelt. Eine präzisere Betrachtung lautet:

Das System erzeugt unterschiedliche Kosten für unterschiedliche Arbeitsweisen.

Wer hervorragend darin ist, historische Zusammenhänge zu speichern, informelle Kommunikationswege zu nutzen und Sonderfälle sicher zu navigieren, kann in dieser Umgebung hohe Wirksamkeit erleben. Wer seine Arbeit stark darauf ausrichtet, lokale Verständlichkeit, explizite Ownership und nachhaltige Ursachenbeseitigung herzustellen, kann dagegen auf erheblich mehr Reibung treffen. Das sagt nichts darüber aus, wer der „bessere Entwickler“ ist. In einem anderen System könnten sich die Kostenverhältnisse umkehren.

Ein Navigator, dessen außergewöhnliche Leistung auf implizitem Wissen über sehr viele Sonderfälle beruht, besitzt in einem konsistent strukturierten Greenfield-System möglicherweise keinen vergleichbaren Vorteil. Ein Entwickler, der in einem Big Ball of Mud permanent an organisatorischen Grenzen scheitert, kann in einem System mit klaren Verantwortlichkeiten sehr wirksam sein. Ein System belohnt deshalb keine abstrakte Kategorie „guter Entwickler“, sondern Verhaltensweisen, die unter seinen konkreten Bedingungen erfolgreich sind.

Der Big Ball of Mud verändert nicht nur Menschen. Er kann langfristig auch beeinflussen, welche Verhaltensweisen in ihm erfolgreich sind.

Attraction, Selection und Attrition

Damit wird eine weitergehende Hypothese möglich. Benjamin Schneider formulierte mit dem Attraction–Selection–Attrition-Modell die Idee, dass Organisationen über längere Zeit nicht zufällig aus bestimmten Gruppen von Menschen bestehen. Menschen fühlen sich von unterschiedlichen Umgebungen angezogen, Organisationen wählen bestimmte Menschen aus, und ein Teil der Personen mit dauerhaft geringer Passung verlässt die Organisation wieder. Schneider, Goldstein und Smith fanden in einem späteren Review direkte und indirekte Unterstützung für die zentrale Annahme, dass Organisationen über solche Prozesse mit der Zeit in bestimmten Merkmalen homogener werden können.

Daraus darf nicht gefolgert werden, dass Big-Ball-of-Mud-Systeme strukturorientierte Entwickler systematisch „aussortieren“. Für eine solche Behauptung gibt es keinen belastbaren empirischen Nachweis. Auch die Forschung zu Burnout und Fluktuation in der Softwareentwicklung rechtfertigt diesen Schluss nicht. Sie zeigt jedoch, dass Burnout, Engagement, Arbeitsressourcen und Verbleib miteinander verbunden sein können. Trinkenreich, Santos und Stol untersuchten hierfür mehr als 13.000 Beschäftigte einer globalen IT-Organisation und ergänzten Befragungsdaten um den tatsächlichen Beschäftigungsstatus 90 Tage später. Ihr Modell verbindet Job Resources, Burnout und Engagement mit Bleibeabsicht und tatsächlicher Retention, wobei sich die Zusammenhänge zwischen Untergruppen unterschieden.

Eine vorsichtigere Hypothese reicht deshalb aus:

Wenn dieselbe Arbeitsumwelt für unterschiedliche Arbeitsweisen dauerhaft unterschiedliche Kosten erzeugt, kann Fluktuation langfristig beeinflussen, welche Menschen und Verhaltensweisen im System verbleiben.

Menschen, deren Fähigkeiten gut zu einer navigationsintensiven Umgebung passen, könnten geringere Anpassungskosten erleben. Menschen, die sich pragmatisch mit ihr arrangieren, möglicherweise ebenfalls. Wer dagegen dauerhaft einen starken Misfit zwischen professionellem Anspruch und tatsächlicher Einflussmöglichkeit erlebt, könnte höhere Kosten erfahren und die Organisation mit höherer Wahrscheinlichkeit verlassen. Das ist eine theoretische Übertragung allgemeiner Fit-, Attrition- und ASA-Modelle auf eine Softwareumgebung, keine empirisch belegte BBOM-Regel.

Die Hypothese besitzt dennoch eine unangenehme Konsequenz: Wenn Menschen mit geringer Passung überproportional häufig verschwinden und Menschen mit höherer Passung bleiben, kann die verbleibende Organisation mit der Zeit immer besser zum bestehenden System passen – nicht weil jemand diesen Zustand geplant hätte, sondern weil Anpassung und Fluktuation über Jahre wirken.

Sozialisation und Attrition können dieselbe Richtung verstärken

Damit treffen zwei normale organisationale Prozesse aufeinander. Sozialisation verändert, wie Menschen in einer vorhandenen Umgebung arbeiten; Attrition verändert, welche Menschen langfristig Teil dieser Umgebung bleiben. In einem langlebigen Big Ball of Mud können beide Prozesse in dieselbe Richtung wirken, ohne dass irgendjemand dies bewusst steuert.

Neue Mitarbeiter lernen die existierenden informellen Regeln, langjährige Mitarbeiter werden bessere Navigatoren, frühere Veränderungsinitiativen prägen die Erwartungen an neue Initiativen und manche Menschen passen ihre Arbeitsweise an. Andere bleiben bei einem starken Misfit oder verlassen das System. Was nach vielen Jahren übrig bleibt, kann deshalb sozial wesentlich stabiler sein, als die technische Struktur vermuten lässt. Die Organisation hat gelernt, das System zu kompensieren, und das System hat indirekt mitgeprägt, welche Fähigkeiten, Erwartungen und Routinen in dieser Organisation besonders wertvoll sind.

Fluktuation kann den technischen Zustand wiederum verstärken

Fluktuation ist dabei nicht nur mögliches Ergebnis, sondern kann selbst wieder neue Schwierigkeiten erzeugen. Ein denkbarer Feedback-Loop verläuft von struktureller Komplexität über hohe Lern- und Navigationskosten zu stärkerer Belastung oder geringerem Fit bei einem Teil der Entwickler. Wenn darauf Fluktuation folgt, verschwindet historisches Systemwissen; die verbleibenden Experten werden wichtiger, epistemische Abhängigkeit kann zunehmen und grundlegende Veränderung noch schwieriger werden.

Das ist kein Naturgesetz. Ausscheidende Mitarbeiter können durch gut dokumentiertes Wissen ersetzt werden, neue Teammitglieder können gezielt Struktur verbessern und Fluktuation kann verfestigte soziale Muster sogar aufbrechen. In einem System, dessen Funktionsfähigkeit jedoch stark von implizitem historischem Wissen abhängt, ist der Verlust erfahrener Personen besonders teuer.

Damit schließt sich der Kreis zum zuvor beschriebenen Schlüsselpersonen-Paradox. Je weniger die Software selbst erklärt, wie sie funktioniert, desto wichtiger werden Menschen, die diese Erklärung ersetzen können. Je wichtiger diese Menschen werden, desto schwieriger kann es werden, das System ohne ihre Beteiligung grundlegend zu verändern – und desto länger bleibt wiederum die Arbeitsumwelt bestehen, an die sich alle anderen anpassen müssen.

Die gefährlichste Stabilität ist vielleicht die, die funktioniert

Ein Big Ball of Mud muss nicht jeden Tag sichtbar zusammenbrechen. Gerade langlebige Systeme zeigen häufig das Gegenteil: Releases finden statt, Incidents werden gelöst, Features gehen live, Experten kennen die kritischen Stellen, Teams entwickeln Routinen und neue Entwickler lernen die Sonderfälle. Die Organisation produziert weiterhin Software.

Technisch können solche Systeme hochgradig problematisch sein, während um sie herum ein leistungsfähiges soziales Kompensationssystem entstanden ist. Genau das kann ihre Veränderung zusätzlich erschweren, weil eine technische Verbesserung dann nicht nur in Code eingreift. Sie kann Wissen, Zuständigkeiten, Routinen, Status, Erwartungen und über Jahre erworbene Fähigkeiten verändern.

Der Navigator verliert möglicherweise einen Teil des Vorsprungs, den sein historisches Wissen besitzt. Der Angepasste soll plötzlich wieder an eine Modernisierung glauben, nachdem mehrere frühere Initiativen gescheitert sind. Der strukturorientierte Veränderer trifft auf Menschen, deren heutiges Verhalten aus ihrer eigenen Projekterfahrung vollkommen rational ist. Niemand davon muss irrational handeln, und niemand muss den Big Ball of Mud aktiv erhalten wollen. Das System kann trotzdem stabil bleiben.

Was die Forschung sagt – und was dieser Artikel daraus ableitet

Gerade bei einem Thema, das schnell in psychologische Diagnosen und moralische Zuschreibungen abrutschen kann, ist die Grenze zwischen Befund und Übertragung entscheidend. Empirisch gut untersucht ist, dass Arbeitsbedingungen wie geringe Kontrolle, hohe Anforderungen, geringe Ressourcen, Rollenunklarheit, fehlende Unterstützung und unterschiedliche Formen von Misfit mit Burnout-Dimensionen und anderen Belastungsmaßen zusammenhängen. Für einige dieser Faktoren existieren Meta-Analysen und longitudinale Befunde. Ebenfalls untersucht ist, dass solche Fragen in der Softwareentwicklung relevant sind und dass Burnout, Engagement und Retention miteinander verbunden sein können.

Gut untersucht sind außerdem Person–Environment Fit, organisatorische Sozialisation, Employee Voice und Silence sowie Attraction-, Selection- und Attrition-Prozesse. Diese Forschungsfelder liefern Begriffe und Mechanismen, mit denen sich Beobachtungen aus langlebigen Softwaresystemen präziser beschreiben lassen.

Nicht direkt empirisch untersucht ist dagegen, dass ein Big Ball of Mud über genau diese Mechanismen Burnout erzeugt, strukturorientierte Entwickler verdrängt oder zwangsläufig eine bestimmte Teamkultur hervorbringt. Das sind theoretisch begründete Übertragungen. Sie passen zu Beobachtungen aus langlebigen Softwaresystemen, sollten aber als Hypothesen darüber formuliert werden, was passieren kann, nicht als psychologische Naturgesetze des Legacy-Codes.

Diese Grenze macht die Diagnose nicht schwächer. Sie macht sie belastbarer.

Fazit

Ein Big Ball of Mud verändert nicht nur Code. Über Jahre kann er mit beeinflussen, welche Fähigkeiten besonders wertvoll werden, welche Risiken Menschen noch eingehen, welche Veränderungsversuche sie für realistisch halten und welche informellen Regeln neue Entwickler lernen müssen.

Manche Menschen lernen, ein schwer verständliches System hervorragend zu navigieren. Andere reduzieren ihre Erwartungen an grundlegende Veränderung und konzentrieren sich auf bekannte, sichere Wege; das kann vernünftiger Pragmatismus sein, nach vielen erfolglosen Veränderungsversuchen aber auch in Zynismus oder Resignation übergehen. Wieder andere versuchen lange, Struktur herzustellen und können dabei einen starken Konflikt erleben, wenn professioneller Anspruch, empfundene Verantwortung und tatsächliche Einflussmöglichkeiten dauerhaft auseinanderfallen.

Keines dieser Muster ist eine feste Persönlichkeitseigenschaft. Der Veränderer von gestern kann der Navigator von morgen sein, und der skeptische Kollege von heute kann eine lange Geschichte erfolgloser Voice hinter sich haben. Neue Entwickler lernen nicht nur das Repository kennen, sondern auch die soziale Gebrauchsanweisung, die das Team um dieses Repository aufgebaut hat. Wenn unterschiedliche Arbeitsweisen in derselben Umgebung dauerhaft unterschiedliche Kosten erzeugen, können Sozialisation und Fluktuation zusätzlich beeinflussen, welche Verhaltensweisen im System verbleiben.

So kann um eine technisch immer schwerer verständliche Software eine erstaunlich stabile soziale Ordnung entstehen.

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

Er besitzt irgendwann nicht mehr nur Dependencies und historische Sonderfälle. Er besitzt Erwartungen, Routinen und informelle Regeln darüber, wie Menschen sich in ihm verhalten. Was ein einzelner Mensch daraus für sich ableitet, ist eine andere Frage. Sie gehört in den späteren Artikel „Change it, like it or leave it.“ Bis hierhin reicht die Diagnose.

Irgendwann passt sich nicht mehr nur die Software an die Organisation an. Die Menschen beginnen, sich an die Software anzupassen.

Literatur

• Alarcon, G. M. (2011): A meta-analysis of burnout with job demands, resources, and attitudes. Journal of Vocational Behavior, 79(2), 549–562. DOI: 10.1016/j.jvb.2011.03.007.
• Andrieu, C. F. A., Milhabet, I., Denis-Noël, A. & Steiner, D. D. (2024): Voice in the Void: From Voice to Acquiescent Silence over Time as Learned Helplessness in Organizations. Revista de Psicología del Trabajo y de las Organizaciones, 40(2), 103–118. DOI: 10.5093/jwop2024a9.
• Aronsson, G., Theorell, T., Grape, T. et al. (2017): A systematic review including meta-analysis of work environment and burnout symptoms. BMC Public Health, 17, 264. DOI: 10.1186/s12889-017-4153-7.
• Bakker, A. B. & Demerouti, E. (2007): The Job Demands–Resources model: state of the art. Journal of Managerial Psychology, 22(3), 309–328. DOI: 10.1108/02683940710733115.
• Bauer, T. N., Bodner, T., Erdogan, B., Truxillo, D. M. & Tucker, J. S. (2007): Newcomer adjustment during organizational socialization: A meta-analytic review of antecedents, outcomes, and methods. Journal of Applied Psychology, 92(3), 707–721. DOI: 10.1037/0021-9010.92.3.707.
• Kristof-Brown, A. L., Zimmerman, R. D. & Johnson, E. C. (2005): Consequences of individuals’ fit at work: A meta-analysis of person–job, person–organization, person–group, and person–supervisor fit. Personnel Psychology, 58(2), 281–342. DOI: 10.1111/j.1744-6570.2005.00672.x.
• Leiter, M. P. & Maslach, C. (1999): Six areas of worklife: A model of the organizational context of burnout. Journal of Health and Human Services Administration, 21(4), 472–489.
• Leiter, M. P., Frank, E. & Matheson, T. J. (2009): Demands, values, and burnout: Relevance for physicians. Canadian Family Physician, 55(12), 1224–1225.e6. PMID: 20008605.
• Maslach, C. & Leiter, M. P. (2008): Early predictors of job burnout and engagement. Journal of Applied Psychology, 93(3), 498–512. DOI: 10.1037/0021-9010.93.3.498.
• Maslach, C. & Leiter, M. P. (2016): Understanding the burnout experience: recent research and its implications for psychiatry. World Psychiatry, 15(2), 103–111. DOI: 10.1002/wps.20311.
• Morrison, E. W. (2014): Employee Voice and Silence. Annual Review of Organizational Psychology and Organizational Behavior, 1, 173–197. DOI: 10.1146/annurev-orgpsych-031413-091328.
• Morrison, E. W. & Milliken, F. J. (2000): Organizational Silence: A Barrier to Change and Development in a Pluralistic World. Academy of Management Review, 25(4), 706–725. DOI: 10.5465/amr.2000.3707697.
• Park, H. I., Jacob, A. C., Wagner, S. H. & Baiden, M. (2014): Job Control and Burnout: A Meta-Analytic Test of the Conservation of Resources Model. Applied Psychology, 63(4), 607–642. DOI: 10.1111/apps.12008.
• Reichers, A. E., Wanous, J. P. & Austin, J. T. (1997): Understanding and managing cynicism about organizational change. Academy of Management Executive, 11(1). DOI: 10.5465/ame.1997.9707100659.
• Rusbult, C. E., Farrell, D., Rogers, G. & Mainous, A. G. III (1988): Impact of Exchange Variables on Exit, Voice, Loyalty, and Neglect: An Integrative Model of Responses to Declining Job Satisfaction. Academy of Management Journal, 31(3), 599–627. DOI: 10.5465/256461.
• Schneider, B. (1987): The People Make the Place. Personnel Psychology, 40(3), 437–453. DOI: 10.1111/j.1744-6570.1987.tb00609.x.
• Schneider, B., Goldstein, H. W. & Smith, D. B. (1995): The ASA Framework: An Update. Personnel Psychology, 48(4), 747–773. DOI: 10.1111/j.1744-6570.1995.tb01780.x.
• Singh, P., Suar, D. & Leiter, M. P. (2012): Antecedents, Work-Related Consequences, and Buffers of Job Burnout Among Indian Software Developers. Journal of Leadership & Organizational Studies, 19(1), 83–104. DOI: 10.1177/1548051811429572.
• Trinkenreich, B., Santos, F. & Stol, K. J. (2024): Predicting Attrition among Software Professionals: Antecedents and Consequences of Burnout and Engagement. ACM Transactions on Software Engineering and Methodology, 33(8), Article 218, 1–45. DOI: 10.1145/3691629.
• Tulili, T. R., Capiluppi, A. & Rastogi, A. (2023): Burnout in software engineering: A systematic mapping study. Information and Software Technology, 155, 107116. DOI: 10.1016/j.infsof.2022.107116.