Die Ökonomie eines Big Ball of Mud

Ein Big Ball of Mud kann wirtschaftlich vollkommen rational sein.

Das klingt zunächst wie ein Widerspruch zu einer Artikelserie, die sich ausführlich mit verlorenen Grenzen, wachsenden Änderungsradien, impliziten Abhängigkeiten und den organisatorischen Folgen technisch erodierter Systeme beschäftigt. Aus ökonomischer Perspektive ist diese Gegenposition jedoch wichtig. Architektur besitzt keinen wirtschaftlichen Wert allein dadurch, dass sie sauber ist. Ihr Wert entsteht daraus, dass sie gegenwärtige und zukünftige Anforderungen wirtschaftlich unterstützt.

Man stelle sich ein Produkt vor, das seit fünfzehn Jahren betrieben wird. Nur noch wenige Kunden verwenden es. Neue Features sind kaum geplant, die Infrastruktur ist stabil, regulatorische Änderungen sind selten und eine Ablösung in einigen Jahren bereits beschlossen. Der Code kann stark erodiert sein, seine inneren Strukturen können schwer verständlich und Änderungen unangenehm sein. Trotzdem wäre es möglicherweise irrational, noch einmal eine grundlegende Modernisierung zu beginnen.

Refactoring, Migration, Replatforming oder Rewrite sind schließlich ebenfalls nicht kostenlos. Sie binden Entwicklungszeit, erzeugen Übergangsrisiken, können Produktentwicklung verzögern und benötigen häufig Migrationen, Schulungen und parallelen Betrieb. Auch eine technische Verbesserung besitzt Opportunity Costs, weil dieselben Menschen währenddessen etwas anderes nicht tun können.

Nicht jede technische Schuld muss zurückgezahlt werden.

Die wirtschaftlich richtige Antwort auf einen Big Ball of Mud ist deshalb nicht automatisch seine Sanierung. Die interessantere Frage lautet, unter welchen Bedingungen sein Zustand tolerierbar bleibt – und wann seine schlechte Änderbarkeit beginnt, die wirtschaftliche Handlungsfähigkeit des Unternehmens zu beeinträchtigen.

Denn die Ökonomie eines Big Ball of Mud entscheidet sich nicht daran, wie hässlich sein Code ist, sondern daran, welchen Preis das Unternehmen für zukünftige Veränderung, Unsicherheit und Reaktionsfähigkeit bezahlt.

Zwei Produkte, dieselbe technische Qualität, völlig andere Ökonomie

Betrachten wir zwei Produkte mit ähnlich problematischer innerer Struktur.

Produkt A befindet sich am Ende seines Lebenszyklus. Es wird noch betrieben und gewartet, aber kaum weiterentwickelt. Die Anzahl der Benutzer sinkt, eine Nachfolgelösung existiert bereits und die verbleibende Maintenance-Mannschaft nimmt nur noch notwendige Anpassungen vor.

Produkt B ist dagegen ein strategisches Kernprodukt. Neue Features erscheinen kontinuierlich, weitere Integrationen sind geplant, mehrere Teams entwickeln daran und das Produkt soll noch viele Jahre am Markt bleiben.

Technisch können beide Systeme gleich schlecht strukturiert sein. Ökonomisch befinden sie sich trotzdem in vollkommen unterschiedlichen Situationen.

Bei Produkt A könnte eine umfassende Sanierung mehr kosten als alle realistisch zu erwartenden zukünftigen Änderungen zusammen. Das Unternehmen würde dann Geld investieren, um eine Änderbarkeit herzustellen, die es voraussichtlich kaum noch benötigt.

Bei Produkt B wird dieselbe schlechte Änderbarkeit dagegen bei jedem weiteren Feature erneut wirksam. Was heute eine unangenehme technische Eigenschaft ist, wird über Jahre immer wieder Bestandteil der Produktionskosten.

Nicht der technische Zustand allein entscheidet, ob ein Big Ball of Mud wirtschaftlich problematisch ist. Entscheidend ist das Verhältnis zwischen diesem Zustand und dem zukünftigen Änderungsbedarf des Produkts.

Nicht der technische Zustand allein entscheidet über die Wirtschaftlichkeit. Entscheidend ist, wie viel Veränderung das Unternehmen künftig von diesem System erwartet.

Je höher der zukünftige Änderungsbedarf eines Produkts ist, desto größer wird der wirtschaftliche Wert einer Struktur, die Änderungen lokal, kontrollierbar und hinreichend vorhersehbar hält. Das ist keine Formel und keine universelle Schwelle. Es ist ein Verhältnis zwischen den Kosten technischer Veränderung und dem Ausmaß der Veränderung, die von einem Produkt noch erwartet wird.

Der erwartete Änderungsbedarf ist entscheidend

Ein Big Ball of Mud ist nicht primär deshalb teuer, weil er heute läuft. Er wird wirtschaftlich relevant, wenn er verändert werden muss.

Bei einer fachlichen Änderung besteht ein Teil der Arbeit zwangsläufig aus der eigentlichen Umsetzung: Eine neue Regel wird implementiert, eine Oberfläche angepasst, ein Prozess erweitert oder eine Schnittstelle ergänzt. Diese Arbeit würde grundsätzlich auch in einem gut strukturierten System entstehen.

Daneben kann jedoch Arbeit notwendig werden, die nicht aus der fachlichen Anforderung selbst folgt. Entwickler müssen zunächst historische Strukturen verstehen, implizite Abhängigkeiten aufspüren oder prüfen, welche entfernten Bereiche von einer Änderung betroffen sein könnten. Zusätzliche Regressionstests werden notwendig, Workarounds müssen berücksichtigt, Seiteneffekte repariert und erfahrene Personen zur Absicherung hinzugezogen werden.

Als konzeptionelle Trennung lässt sich deshalb schreiben:

Änderungskosten = fachliche Arbeit + strukturell verursachte Zusatzarbeit

Das ist ausdrücklich kein präzises Kostenmodell. Es beschreibt lediglich zwei unterschiedliche Quellen von Aufwand. Die erste entsteht aus dem gewünschten Produktverhalten. Die zweite entsteht daraus, dass dieses Verhalten in einem bestehenden technischen System verändert werden muss.

Die Technical-Debt-Forschung liefert empirische Hinweise darauf, dass solche Zusatzarbeit wirtschaftlich relevant sein kann. Besker, Martini und Bosch untersuchten in einer longitudinalen Studie mit 43 Entwicklern sowie ergänzenden Interviews, wie viel Entwicklungszeit nach Einschätzung der Beteiligten durch Technical Debt gebunden wurde. In ihrer 2019 veröffentlichten Replikations- und Erweiterungsstudie lag der berichtete Durchschnitt bei rund 23 Prozent; zusätzliche Tests gehörten zu den besonders häufig genannten Tätigkeiten.

Diese Zahl verlangt eine wichtige Einschränkung: Technical Debt ist nicht dasselbe wie ein Big Ball of Mud. Die Studie besagt daher nicht, dass ein Big Ball of Mud „23 Prozent Produktivität kostet“. Sie zeigt etwas Allgemeineres und für die ökonomische Betrachtung Relevantes: Technische Altlasten können einen erheblichen Anteil der Arbeitszeit in Tätigkeiten verschieben, die zusätzlich zur eigentlichen fachlichen Veränderung erforderlich werden.

Gerade diese Verschiebung macht technische Erosion wirtschaftlich interessant.

Output Decline: Nicht weniger Arbeit, sondern weniger fachlicher Output

Von außen kann ein erodierendes System zunächst wie ein Personalproblem aussehen.

Ein Team hat früher vielleicht mehrere größere Anforderungen pro Quartal umgesetzt. Jahre später schafft dieselbe Organisation sichtbar weniger. Daraus entsteht leicht die Interpretation, die Entwickler seien langsamer geworden, Prozesse seien ineffizient oder die Mannschaft benötige mehr Leistungsdruck.

Das kann zutreffen, muss aber nicht die Ursache sein. Ein wachsender Anteil derselben verfügbaren Kapazität kann inzwischen in Systemverständnis, Fehlerbehebung, Regression, Absicherung, Abstimmung, Workarounds, Incident-Arbeit oder die Reparatur unbeabsichtigter Seiteneffekte fließen. Die Menschen arbeiten dann nicht zwangsläufig weniger; ein größerer Teil ihrer Arbeit dient lediglich dazu, die Änderbarkeit des vorhandenen Systems zu kompensieren.

Die Untersuchung von Besker, Martini und Bosch ist auch für diese Unterscheidung interessant: Die von Technical Debt verursachte Zeit verschwand nicht einfach. Sie wurde für zusätzliche Entwicklungsaktivitäten benötigt.

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

Ökonomisch ist das entscheidend. Ein Unternehmen finanziert weiterhin dieselbe Entwicklungskapazität, doch ein wachsender Anteil davon erzeugt keine neue fachliche Funktionalität, sondern kompensiert die strukturellen Eigenschaften des bestehenden Systems.

Eine wissenschaftliche Grenze

An dieser Stelle ist eine Abgrenzung notwendig, die für den gesamten Artikel gilt.

Es gibt empirische Forschung zu Technical Debt, Wartbarkeit, Koordination, Softwareaufwandsschätzung, Legacy-Onboarding, Software-Evolution und Security-Patching. Diese Forschungsstränge untersuchen Mechanismen, die auch für einen Big Ball of Mud relevant sein können.

Sie messen jedoch nicht gemeinsam eine universelle Kategorie „Big Ball of Mud“ und liefern keine belastbare Zahl dafür, um wie viel teurer, langsamer oder unplanbarer ein solches System grundsätzlich ist.

Wo dieser Artikel beispielsweise argumentiert, dass ein unbekannter Change Radius zusätzliche Schätzunsicherheit erzeugen kann, ist das deshalb eine Architekturhypothese: Wenn relevante Abhängigkeiten vor Beginn einer Änderung unbekannt sind, fehlen zum Zeitpunkt der Schätzung Informationen. Die allgemeine Schwierigkeit von Softwareaufwandsschätzungen ist empirisch untersucht. Die BBOM-spezifische Übertragung ist eine Schlussfolgerung aus dem beschriebenen Mechanismus und keine direkt gemessene Prozentzahl.

Dasselbe gilt später für Security-Patching, Onboarding oder Opportunity Costs.

Diese Trennung ist wichtig, weil gerade ein wirtschaftliches Argument durch Scheingenauigkeit nicht stärker, sondern schwächer würde.

Vom Change Radius zum wirtschaftlichen Problem

Der Begriff des Change Radius wurde in dieser Serie bereits technisch eingeführt. Für die wirtschaftliche Betrachtung interessiert weniger, wie er im Code entsteht, sondern was passiert, wenn er größer wird oder vor einer Änderung nicht zuverlässig bekannt ist.

Je weiter eine Veränderung tatsächlich reicht, desto mehr Code muss möglicherweise verstanden werden. Weitere Komponenten können getestet werden müssen, zusätzliche Teams können beteiligt sein und mehr organisatorische Abstimmung kann erforderlich werden. Gleichzeitig steigt die Wahrscheinlichkeit, dass ein ursprünglich lokales Vorhaben während der Umsetzung neue Abhängigkeiten sichtbar macht.

Damit verändert sich die Perspektive: Was für einen Entwickler zunächst eine technische Frage ist – Welche Teile des Systems muss ich für diese Änderung anfassen? –, kann für einen Stakeholder zu einer wirtschaftlichen Frage werden – Wann ist diese Änderung fertig und wie sicher ist diese Aussage?

Der Change Radius eines Entwicklers kann zum Geschäftsrisiko eines Stakeholders werden.

Koordinationskosten: Effort ist nicht Lead Time

Besonders deutlich wird das, wenn technische Abhängigkeiten organisatorische Abhängigkeiten erzeugen. Eine Änderung kann mehrere Teams, unterschiedliche Verantwortliche, gemeinsame Tests, Architekturentscheidungen oder abgestimmte Releases erfordern. Dann entstehen nicht nur zusätzliche Arbeitsstunden, sondern auch Übergaben und Wartezeiten.

Die Forschung zu sozio-technischer Kongruenz untersucht genau die Beziehung zwischen technischen Abhängigkeiten und dem Koordinationsbedarf von Entwicklungsorganisationen. Cataldo, Herbsleb und Carley zeigten in einer empirischen Untersuchung, dass die Abstimmung tatsächlicher Koordinationsmuster mit den durch technische Arbeit entstehenden Koordinationsanforderungen mit kürzeren Bearbeitungszeiten von Änderungsanforderungen zusammenhing.

Auch daraus folgt keine Aussage, jeder Big Ball of Mud verursache zwangsläufig eine bestimmte Menge zusätzlicher Meetings. Die Forschung stützt jedoch den grundlegenden Mechanismus: Technische Abhängigkeiten erzeugen Koordinationsanforderungen.

Damit müssen Effort und Lead Time getrennt betrachtet werden.

Ein Feature kann vielleicht nur wenige Tage tatsächliche Implementierungsarbeit enthalten und trotzdem mehrere Wochen bis zur Auslieferung benötigen. Team A muss zunächst eine Schnittstelle ändern, Team B darauf reagieren, anschließend muss eine gemeinsame Testumgebung verfügbar sein und schließlich wartet die Änderung auf ein abgestimmtes Release.

Die zusätzlichen Wochen erscheinen in keiner Zeile Quellcode. Wirtschaftlich sind sie trotzdem real.

Technische Unvorhersehbarkeit kann über Termine und Abhängigkeiten bis in die wirtschaftliche Planung des Unternehmens reichen.

Nicht nur höhere Kosten, sondern höhere Varianz

Die wirtschaftliche Schwierigkeit eines Big Ball of Mud liegt möglicherweise nicht einmal primär darin, dass jede Änderung teuer wäre. Problematischer kann sein, dass vor Beginn kaum erkennbar ist, welche Änderung teuer wird.

Nehmen wir zwei rein illustrative Systeme. In System A benötigen vergleichbare Änderungen relativ zuverlässig zwischen 20 und 25 Personentagen. In System B dauert eine Änderung fünf Tage, eine andere 70 oder 80 – und zu Beginn lässt sich nur schwer erkennen, welcher Fall bevorsteht.

Diese Zahlen sind kein empirischer Befund. Das Gedankenexperiment verdeutlicht lediglich eine Eigenschaft, die in klassischen Durchschnittskosten verschwindet. Selbst wenn beide Systeme langfristig einen ähnlichen mittleren Aufwand hätten, besäße System B ein zusätzliches wirtschaftliches Problem: höhere Unsicherheit.

Planbarkeit besitzt wirtschaftlichen Wert.

Unternehmen müssen Budgets verteilen, Releases planen, Marketing vorbereiten, Kundenmigrationen koordinieren, Verträge erfüllen, Personal einteilen und andere Projekte auf gemeinsame Termine ausrichten. Ein Aufwand von 30 Tagen ist für eine Organisation etwas anderes als ein Aufwand, der irgendwo zwischen fünf und achtzig Tagen liegen könnte – selbst wenn der langfristige Durchschnitt identisch wäre.

Softwareaufwandsschätzung ist allerdings auch unabhängig von einem Big Ball of Mud schwierig. Jørgensen und Shepperd sichteten in ihrem systematischen Review 304 Arbeiten zur Softwarekostenschätzung und betonten unter anderem die Bedeutung von Untersuchungs- und Datenkontexten. Jørgensens Reviews zu Expertenschätzungen zeigen ebenfalls, wie stark verfügbare Kontextinformationen und die konkrete organisatorische Situation die Qualität von Schätzungen beeinflussen können.

Diese Forschung belegt nicht, dass Big Balls of Mud eine bestimmte höhere Schätzvarianz besitzen. Die Übertragung auf die hier diskutierte Struktur lautet vorsichtiger: Wenn der tatsächliche Change Radius einer Anforderung erst während ihrer Umsetzung sichtbar wird, fehlen zum Schätzzeitpunkt potenziell relevante Informationen. Damit kommt zu der ohnehin schwierigen Softwareaufwandsschätzung eine weitere Quelle technischer Unsicherheit hinzu.

Stakeholder zahlen für technische Unvorhersehbarkeit

Diese Unsicherheit bleibt nicht zwangsläufig innerhalb der Entwicklungsabteilung. Ein zugesagtes Lieferdatum kann an ein Kundenprojekt gekoppelt sein. Andere Systeme können von einer gemeinsamen Release-Version abhängen. Marketingaktivitäten, Schulungen oder Migrationen können auf einen Termin abgestimmt worden sein. Verträge können Fristen enthalten, deren Nichteinhaltung kommerzielle Folgen hat.

Daraus folgt nicht:

Ein Big Ball of Mud führt zu Vertragsstrafen.

Die wirtschaftliche Kette ist bedingter:

technische Unsicherheit → Terminunsicherheit → Planungsrisiko → möglicherweise Vertrags-, Umsatz- oder Reputationsrisiko

Je geringer die technische Planbarkeit ist, desto größer kann das Risiko werden, dass technische Unsicherheit auf Verpflichtungen außerhalb der Entwicklungsorganisation durchschlägt.

Der entscheidende Punkt ist deshalb nicht, dass jede Verzögerung sofort Geld kostet. Es reicht, dass eine Organisation ihre Entscheidungen unter größerer Unsicherheit treffen muss.

Ein Unternehmen bezahlt für schlechte Änderbarkeit nicht nur mit mehr Entwicklungsaufwand. Es kann auch mit verlorener Planbarkeit bezahlen.

Opportunity Costs: Was wird nicht gebaut?

Die unmittelbar sichtbaren Zusatzkosten einer Änderung sind vergleichsweise leicht zu verstehen.

Nehmen wir erneut ein Gedankenexperiment: Eine Anforderung hätte in einem gut verstandenen, lokal änderbaren System vielleicht 15 Personentage benötigt. Im bestehenden System werden daraus aufgrund zusätzlicher Analyse, Regression und Seiteneffekte 40 Personentage.

Die offensichtliche Differenz beträgt 25 Personentage. Wirtschaftlich interessanter ist jedoch die Gegenfrage:

Was hätte das Team in diesen 25 Tagen stattdessen entwickeln können?

Damit kommen Opportunity Costs ins Spiel. Die knappe Ressource ist nicht nur Geld, sondern Entwicklungskapazität. Jede Stunde, die für strukturell verursachte Zusatzarbeit benötigt wird, steht für eine andere Verbesserung, einen anderen Kundenwunsch oder eine andere Risikoreduktion nicht zur Verfügung.

Noch schwerer sichtbar ist ein zweiter Effekt: Eine Anforderung wird analysiert und als technisch zu teuer eingeschätzt. Das Product Management entscheidet:

Das lohnt sich nicht.

Daraufhin wird sie nicht umgesetzt. In einer klassischen Technical-Debt-Kostenrechnung taucht diese Anforderung möglicherweise nie auf. Es gab keinen zusätzlichen Implementierungsaufwand, keinen gescheiterten Sprint und keine sichtbaren Rework-Kosten. Trotzdem hat die technische Struktur eine wirtschaftliche Entscheidung beeinflusst.

Ein Big Ball of Mud verteuert nicht nur Änderungen. Er kann verändern, welche Änderungen überhaupt noch wirtschaftlich erscheinen.

Damit beginnt Architektur, in die Produktstrategie hineinzuwirken. Der technische Zustand verkleinert den wirtschaftlichen Lösungsraum. Bestimmte Ideen werden nicht verworfen, weil sie keinen Marktwert hätten, sondern weil ihre Realisierung im bestehenden System zu teuer oder zu riskant erscheint.

Cost of Delay und Time-to-Market

Opportunity Costs betrachten, was aufgrund gebundener Kapazität nicht gleichzeitig getan werden kann. Verzögerungen besitzen noch eine zweite Dimension: Der erwartete Nutzen einer Änderung entsteht später.

Die ökonomische Forschung zu Produktentwicklung behandelt Time-to-Market deshalb nicht isoliert als technisches Geschwindigkeitsziel, sondern als Abwägung zwischen Entwicklungsdauer, Produktqualität, Marktfenster, Wettbewerb und erwartetem wirtschaftlichem Nutzen. Cohen, Eliashberg und Ho modellierten diesen Trade-off bereits 1996 für neue Produktentwicklung und zeigten gerade, dass eine pauschale Maximierung der Geschwindigkeit ökonomisch nicht sinnvoll ist; die optimale Entscheidung hängt vom jeweiligen Markt- und Produktkontext ab.

Diese Differenzierung passt gut zur Architekturfrage.

Ein Feature, dessen Auslieferung sich technisch verzögert, ist nicht automatisch ein wirtschaftlicher Schaden. Vielleicht ist seine Marktposition unkritisch oder zusätzliche Entwicklungszeit verbessert seinen Nutzen erheblich.

Wenn der erwartete Wert jedoch zeitabhängig ist, kann Verzögerung doppelt wirken: Das Unternehmen investiert länger in die Umsetzung und realisiert den erwarteten Nutzen später.

Bei einem wettbewerbsintensiven Produkt, einem begrenzten Marktfenster oder einer vertraglich relevanten Funktion kann dieser Effekt wichtiger werden als die zusätzlichen Entwicklerstunden selbst.

Damit ist Time-to-Market keine abstrakte Managementkennzahl. Sie wird zu einer möglichen ökonomischen Konsequenz technischer Änderbarkeit.

Architektur als Optionswert

Bis hierher wurde Änderbarkeit vor allem als Mittel betrachtet, Aufwand und Verzögerung zu reduzieren. Ihr strategischer Wert kann darüber hinausgehen.

Unternehmen kennen heute nicht alle Entscheidungen, die sie in drei oder fünf Jahren treffen müssen. Vielleicht entsteht ein neues Geschäftsmodell. Eine Regulierung verändert den Umgang mit Daten. Eine Plattform wird abgekündigt. Ein neuer Vertriebskanal entsteht. Das Produkt soll in einen weiteren Markt expandieren oder eine bisher zentrale externe API muss ersetzt werden.

In solchen Situationen besitzt Flexibilität einen Optionscharakter. Sullivan, Griswold, Cai und Hallen übertrugen Real-Options-Denken auf modulare Softwarestrukturen und untersuchten damit den wirtschaftlichen Wert von Modularität und Information Hiding. Ihr Ansatz bedeutet nicht, dass sich jede Architekturentscheidung wie eine börsengehandelte Option exakt finanziell bewerten ließe. Er liefert vielmehr ein ökonomisches Modell dafür, weshalb die Möglichkeit, spätere Entscheidungen unter dann besserem Wissen treffen zu können, einen Wert besitzt.

Die strategische Idee lässt sich einfach formulieren:

Wir müssen heute noch nicht wissen, welche dieser Änderungen eintreten wird. Es reicht, wenn wir später noch darauf reagieren können.

Gute Architektur kauft nicht nur Geschwindigkeit. Sie kauft dem Unternehmen Entscheidungsfreiheit.

Ein stark verhärtetes System kann diese Entscheidungsfreiheit schrittweise reduzieren. Eine technisch grundsätzlich mögliche Veränderung kann so teuer, langwierig oder riskant werden, dass sie wirtschaftlich praktisch keine realistische Option mehr darstellt.

Auch das bedeutet nicht, dass maximale Flexibilität immer optimal wäre. Flexibilität selbst kostet Entwicklungsaufwand. Carrière, Kazman und Ozkaya argumentieren entsprechend für eine explizite Kosten-Nutzen-Betrachtung von Architekturentscheidungen im Geschäftskontext.

Der ökonomische Wert liegt also nicht darin, jede denkbare Zukunft vorwegzunehmen. Er liegt darin, für relevante Unsicherheit ausreichend Handlungsmöglichkeiten zu erhalten.

Aber: „Wir brauchen keine Features mehr“ reicht nicht

Damit könnten wir zur anfänglichen Gegenposition zurückkehren.

Wenn ein Produkt kaum noch weiterentwickelt wird, sinkt der erwartete Nutzen hoher Änderbarkeit. Genau deshalb kann es rational sein, einen technisch schlechten Zustand zu tolerieren.

Die Rechnung enthält allerdings eine Unsicherheit:

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

Nicht jede zukünftige Veränderung wird vom Product Management initiiert. Konzeptionell lassen sich zwei Quellen unterscheiden.

Endogene Änderungen

Endogene Änderungen entstehen weitgehend aus Entscheidungen des Unternehmens selbst. Dazu gehören beispielsweise:

• neue Features,
• Änderungen an der User Experience,
• neue Geschäftsmodelle,
• Refactorings,
• zusätzliche Integrationen,
• strategische Produktveränderungen.

Über viele dieser Änderungen kann eine Organisation zumindest teilweise entscheiden. Wenn ihre Kosten zu hoch sind, können sie verschoben, vereinfacht oder vollständig gestrichen werden.

Exogene Änderungen

Exogene Änderungen entstehen dagegen aus der Umwelt des Systems:

• neu entdeckte Sicherheitslücken,
• gesetzliche oder regulatorische Änderungen,
• neue Compliance-Anforderungen,
• Änderungen externer Schnittstellen,
• Plattform- oder Betriebssystemänderungen,
• Änderungen von Browsern oder Cloudplattformen,
• abgekündigte Libraries, Laufzeitumgebungen oder Protokolle.

Über den Zeitpunkt solcher Ereignisse besitzt das Unternehmen erheblich weniger Kontrolle.

Der zukünftige Änderungsbedarf eines Softwaresystems wird nicht ausschließlich vom Product Management bestimmt.

Der zukünftige Änderungsbedarf wird nicht ausschließlich vom Product Management bestimmt. Manche Änderungen entstehen außerhalb der eigenen Roadmap.

Software Evolution: Die Umwelt entwickelt sich weiter

Dass langlebige Software auf eine sich verändernde Umwelt reagieren muss, ist keine neue Beobachtung.

Meir M. Lehman untersuchte Software-Evolution bereits seit den 1970er-Jahren. Seine Arbeiten unterscheiden insbesondere sogenannte E-Type Systems: Systeme, die in reale Prozesse und Umgebungen eingebettet sind und deren Nützlichkeit deshalb mit dieser Umwelt verbunden bleibt. Zu den bekannten Laws of Software Evolution gehören Continuing Change und Increasing Complexity.

Diese „Laws“ sollten nicht als unveränderliche Naturgesetze jeder modernen Softwarearchitektur gelesen werden. Sie entstanden aus empirischen Beobachtungen bestimmter langlebiger Softwaresysteme und wurden später weiterentwickelt und diskutiert. Lehman selbst griff sie 1996 erneut im Kontext laufender Forschung auf.

Für die wirtschaftliche Argumentation bleibt dennoch eine robuste Grundidee: Ein System, das mit einer realen organisatorischen, technischen oder gesellschaftlichen Umwelt interagiert, kann seine Relevanz verlieren, wenn diese Umwelt sich verändert und das System nicht entsprechend angepasst wird.

Ein Produkt kann fachlich abgeschlossen sein. Seine Umgebung ist deshalb nicht zwangsläufig abgeschlossen.

Ein eingefrorener Feature-Backlog friert nicht die Umwelt ein, in der die Software betrieben wird.

Security: Änderung unter fremdbestimmtem Zeitdruck

Sicherheitslücken sind ein besonders anschaulicher Fall exogener Veränderung.

Eine Organisation entscheidet nicht zuverlässig, wann eine neue Schwachstelle entdeckt wird, wann Informationen darüber öffentlich werden oder wie kritisch eine notwendige Reaktion ist. Je nach Situation kann eine Änderung lange vorbereitet werden – oder sie muss kurzfristig erfolgen.

Eine gute Architektur verhindert keine Sicherheitslücken. Auch ein hervorragend strukturiertes System kann verwundbar sein.

Sie beeinflusst jedoch mit, unter welchen Bedingungen eine notwendige Änderung durchgeführt werden kann.

Empirische Security-Forschung zeigt, dass Patch-Verteilung in komplexen technischen Ökosystemen erheblich verzögert werden kann. Zhang, Zhang, Qian und Lau untersuchten beispielsweise 2021 die Patch-Propagation im Android-Kernel-Ökosystem. In der stark dezentralisierten und fragmentierten Lieferkette konnten Patches mehrere technische und organisatorische Ebenen durchlaufen; zwischen öffentlich verfügbarem Patch und Anwendung auf Endgeräten lagen in den untersuchten Fällen teilweise Monate oder sogar Jahre.

Diese Studie untersucht keinen Big Ball of Mud. Ihre Aussage ist eine andere: Security-Remediation kann durch technische und organisatorische Abhängigkeiten erheblich verzögert werden. Die Übertragung auf einen Big Ball of Mud ist deshalb wiederum eine Architekturhypothese:

Ein System mit hoher Kopplung und schlecht vorhersehbaren Änderungsradien kann gerade dann zum wirtschaftlichen Risiko werden, wenn eine Änderung nicht aufgeschoben werden kann.

Bei einem optionalen Feature kann ein Unternehmen entscheiden, dass eine Umsetzung zu teuer ist. Bei einer kritischen Sicherheitskorrektur besitzt es diese Freiheit möglicherweise nicht.

Dann wird aus schlechter Änderbarkeit Reaktionsrisiko.

Gesetzliche und regulatorische Änderungen

Security ist nicht der einzige externe Zwang.

Gesetzliche oder regulatorische Anforderungen können feste Stichtage besitzen. Sie können neue Datenverarbeitung verlangen, Prozesse verändern, zusätzliche Nachweise erfordern oder Schnittstellen betreffen. Auch Änderungen von Branchenstandards oder verpflichtenden Plattformen können eine technische Reaktion notwendig machen.

In einer solchen Situation lautet die wirtschaftliche Frage nicht mehr ausschließlich:

Lohnt sich diese Änderung?

Sie kann lauten:

Können wir diese Änderung innerhalb des verfügbaren Zeitfensters zuverlässig durchführen?

Das verändert den Wert von Änderbarkeit fundamental.

Architektur bestimmt nicht, ob ein Unternehmen von unerwarteten Veränderungen getroffen wird. Sie bestimmt mit, wie gut es darauf reagieren kann.

Gerade deshalb reicht die Aussage „Dieses Produkt bekommt keine Features mehr“ als wirtschaftliche Begründung für einen unveränderten technischen Zustand allein nicht aus. Relevant ist zusätzlich, welchen externen Veränderungen das Produkt während seiner verbleibenden Lebensdauer ausgesetzt sein kann.

Kosten, Planbarkeit und Reaktionsfähigkeit

Damit lassen sich drei unterschiedliche ökonomische Dimensionen von Änderbarkeit unterscheiden.

1. Änderungskosten

Wie viel Arbeit ist notwendig, um eine gewünschte oder notwendige Veränderung zuverlässig umzusetzen?

Hier wirken die zusätzlichen Analyse-, Test-, Koordinations- und Rework-Kosten, die ein schwer veränderbares System erzeugen kann.

2. Planbarkeit

Wie zuverlässig können Aufwand und Dauer vor Beginn einer Änderung eingeschätzt werden?

Diese Dimension ist für Budgets, Termine, Abhängigkeiten und geschäftliche Zusagen relevant. Auch eine teure Änderung kann planbar sein. Eine stark schwankende und erst während der Umsetzung erkennbare Änderung kann dagegen organisatorisch schwieriger zu beherrschen sein.

3. Reaktionsfähigkeit

Wie schnell und kontrolliert kann die Organisation handeln, wenn eine Änderung nicht beliebig verschoben werden kann?

Hier werden Security, Regulierung, Plattformwechsel oder andere externe Zwänge relevant.

Diese drei Dimensionen lassen sich nicht sinnvoll zu einer scheinpräzisen Kennzahl verrechnen. Sie beschreiben unterschiedliche Arten wirtschaftlicher Belastung.

Der wirtschaftliche Wert von Änderbarkeit liegt nicht nur darin, Änderungen billiger zu machen. Er liegt auch darin, Kosten, Dauer und Risiken innerhalb eines beherrschbaren Korridors zu halten.

Der wirtschaftliche Aufwand einer Änderung kann weit über die eigentliche fachliche Implementierung hinausgehen.

Hiring ist mehr als Recruiting

Software wird nicht nur verändert. Die Menschen, die sie verändern, wechseln ebenfalls.

Neue Entwickler zu finden verursacht bereits Aufwand. Aus Sicht eines langlebigen Systems ist Recruiting jedoch nur der Anfang. Ein neuer Mitarbeiter muss die Domäne verstehen, die Entwicklungsumgebung beherrschen, technische und organisatorische Regeln kennenlernen und schließlich genug Systemwissen erwerben, um Änderungen sicher durchführen zu können.

In einem Big Ball of Mud kann eine zusätzliche Schwierigkeit entstehen: Ein erheblicher Teil der tatsächlich wirksamen Struktur ist möglicherweise nicht explizit dokumentiert oder aus dem Code lokal ableitbar. Wissen darüber, welche Bereiche zusammenhängen, welche Pfade gefährlich sind und weshalb bestimmte scheinbar merkwürdige Lösungen existieren, liegt dann bei erfahrenen Personen.

Empirische Forschung zu Legacy-Onboarding zeigt, dass dieser Wissenserwerb tatsächlich eine relevante Herausforderung sein kann. Britto, Cruzes, Šmite und Sablis untersuchten drei global verteilte Legacy-Projekte. Sie beschreiben das Erlernen des Legacy-Codes als besondere Schwierigkeit, die in ihren Fällen durch Projektgröße und Entfernung zu ursprünglichen Wissensträgern zusätzlich verstärkt wurde.

Auch daraus folgt nicht, dass Onboarding in einem Big Ball of Mud empirisch immer einen bestimmten Prozentsatz länger dauert.

Die vorsichtige Übertragung lautet:

Forschung zu Legacy-Projekten zeigt, dass der Erwerb historischen Systemwissens eine wesentliche Onboarding-Herausforderung darstellen kann. In einem Big Ball of Mud dürfte dieser Mechanismus besonders relevant sein, wenn ein großer Teil der wirksamen Architektur nur implizit bekannt ist.

Damit bekommt mangelnde strukturelle Verständlichkeit eine direkte Personalkostendimension.

Die versteckten Kosten der Einarbeitung

Onboarding bindet nicht nur die Zeit des neuen Mitarbeiters.

Ein Entwickler, der ein unbekanntes System verstehen soll, benötigt Unterstützung durch Menschen, die dieses System bereits kennen. Diese beantworten Fragen, erklären historische Entscheidungen, führen Pairing durch, reviewen Änderungen oder verhindern Fehler in Bereichen, deren Risiken aus dem Code allein schwer erkennbar sind.

Britto und Kollegen beschreiben in ihren untersuchten Legacy-Projekten unter anderem Coaching und Mentoring durch erfahrene Entwickler als Teil des Onboardings. Daraus ergibt sich eine oft unterschätzte ökonomische Doppelwirkung.

Während ein neuer Mitarbeiter lernt, entsteht zunächst seine eigene Lernzeit. Gleichzeitig wird Kapazität einer erfahrenen Person gebunden. Und diese erfahrene Person kann gerade in einem schwer verständlichen System ohnehin eine knappe Ressource sein.

Einarbeitung kostet nicht nur die Produktivität des Neuen. Sie bindet gleichzeitig die Produktivität derjenigen, die das implizite Wissen besitzen.

Damit können die Personen, die ein Unternehmen zur Skalierung eines Teams benötigt, zunächst genau diejenigen stärker belasten, die bereits Bottlenecks sind.

Ein System lässt sich dann organisatorisch nicht beliebig durch zusätzliche Köpfe skalieren. Neue Kapazität muss zunächst durch vorhandene Kapazität ausgebildet werden.

Fluktuationskosten und verlorenes Wissen

Der vorherige Artikel dieser Serie hat bereits betrachtet, was schwer veränderbare Systeme mit Menschen und Organisationen machen können. Für die ökonomische Betrachtung genügt hier die andere Richtung: Was bedeutet es für das System, wenn Menschen gehen?

Ein neuer Entwickler, der nach relativ kurzer Zeit wieder ausscheidet, nimmt einen Teil der gerade aufgebauten Investition mit. Recruiting, Einarbeitung, Mentoring und erworbenes Systemwissen müssen für einen Nachfolger erneut aufgebracht werden.

Bei langjährigen Mitarbeitern kann die Situation umgekehrt sein. Verlässt eine Person das Unternehmen, die historische Zusammenhänge kennt, können Informationen verschwinden, die nicht vollständig in Dokumentation, Tests oder Struktur repräsentiert sind.

Robillard führte 2021 qualitative Interviews mit 27 professionellen Entwicklern und Managern aus drei Unternehmen durch und entwickelte daraus einen Rahmen zur Beschreibung von durch Turnover ausgelöstem Wissensverlust. Die Arbeit ist keine Big-Ball-of-Mud-Studie, zeigt aber, dass das Ausscheiden von Entwicklern relevantes technisches Wissen tatsächlich aus Teams entfernen kann.

Je stärker ein System auf implizitem historischen Wissen beruht, desto plausibler wird dieser Mechanismus für seine wirtschaftliche Betrachtung.

Neue Menschen können teuer einzuarbeiten sein. Erfahrene Menschen können teuer zu verlieren sein.

Ein Big Ball of Mud kann beide Seiten verschärfen, wenn sichere Änderungen stark von Wissen abhängen, das nur einzelne Personen besitzen.

Das asymmetrische Business-Case-Problem

Warum ist es dennoch häufig so schwierig, einen wirtschaftlichen Business Case für strukturelle Verbesserungen zu formulieren?

Ein Grund liegt in einer fundamentalen Asymmetrie.

Die Kosten einer Sanierung sind sichtbar: Eine Analyse ergibt vielleicht, dass eine Migration mehrere Teams für Monate binden würde. Refactorings benötigen konkrete Kapazität. Neue Infrastruktur muss aufgebaut, Daten müssen migriert und bestehendes Verhalten abgesichert werden.

Diese Kosten erscheinen im Budget. Der Nutzen besserer Änderbarkeit besteht dagegen häufig darin, zukünftige Zusatzarbeit nicht leisten zu müssen.

Ein Entwickler muss eine Abhängigkeit nicht drei Tage analysieren. Ein zweites Team muss nicht beteiligt werden. Ein Regressionstest wird nicht notwendig. Ein Feature benötigt keine zusätzliche Woche Wartezeit. Eine neue Person versteht eine Grenze direkt aus der Struktur, statt sie von einem Experten erklärt zu bekommen.

Diese Dinge erscheinen anschließend in keiner Erfolgsmeldung, gerade weil sie nicht passiert sind.

Gute Architektur produziert häufig keine sichtbare Leistung. Sie verhindert unsichtbare Zusatzarbeit.

Daraus entsteht ein schwieriger Business Case.

Angenommen, eine Sanierung würde – rein illustrativ – 500 Personentage kosten. Diese Zahl steht konkret im Raum. Die Gegenposition lautet vielleicht, dass dadurch in den kommenden fünf Jahren ein unbekannter Anteil an Analyse-, Koordinations-, Regression-, Incident- und Verzögerungskosten vermieden werden kann.

Die erste Zahl ist sichtbar und kurzfristig.

Die zweite ist verteilt, probabilistisch und teilweise kontrafaktisch: Man müsste wissen, welche Kosten ohne die Investition entstanden wären.

Genau deshalb darf daraus aber nicht die umgekehrte Architekturreligion entstehen. Unsichtbarer Nutzen ist nicht automatisch großer Nutzen. Eine teure Modernisierung kann auch schlicht keinen positiven Business Case besitzen.

Die ökonomische Aufgabe besteht darin, beide Seiten unter Unsicherheit zu vergleichen, nicht darin, die technische Seite moralisch aufzuwerten.

Tail Risk: selten, aber teuer

Damit gelangen wir zu dem schwierigsten Teil der Entscheidung für Produkte mit geringem erwarteten Änderungsbedarf.

Vielleicht ist es tatsächlich sehr wahrscheinlich, dass in den nächsten drei Jahren nur wenige Änderungen notwendig werden.

Die Entscheidung, ein schwer veränderbares System nicht mehr grundlegend anzufassen, kann dann ökonomisch sinnvoll sein.

Trotzdem bleibt eine Frage:

Was passiert, wenn eine seltene, aber zwingende Änderung eintritt?

Eine kritische Sicherheitslücke wird veröffentlicht. Ein gesetzlicher Stichtag verlangt eine Anpassung. Eine zentrale Plattform wird kurzfristiger als erwartet abgekündigt. Ein bisher stabiler externer Dienst ändert seine Schnittstelle.

Für diese Fälle sind nicht nur die durchschnittlich erwarteten Wartungskosten relevant. Relevant sind auch Eintrittswahrscheinlichkeit, potenzieller Schaden, verfügbare Reaktionszeit und die technische Fähigkeit, innerhalb dieser Zeit kontrolliert zu handeln.

Dafür braucht es keine komplexe finanzmathematische Risikorechnung, um einen wichtigen Unterschied festzuhalten:

„Wir erwarten kaum Änderungen“ ist eine Prognose. Keine Garantie.

Ein Unternehmen kann bewusst entscheiden, dieses Risiko zu tragen. Es sollte nur nicht versehentlich aus „wenig geplante Produktentwicklung“ auf „keine notwendigen Änderungen“ schließen.

Keine Architekturreligion

Damit schließt sich der Kreis zur Gegenposition vom Beginn.

Ein alter Big Ball of Mud kann wirtschaftlich die richtige technische Realität für ein Produkt sein. Das gilt insbesondere, wenn seine Ablösung verlässlich geplant ist, die verbleibende Lebensdauer kurz ist, nur wenige Veränderungen erwartet werden und relevante externe Risiken beherrschbar bleiben.

Eine Sanierung kann in dieser Situation mehr Geld, Zeit und Risiko erzeugen, als sie während der verbleibenden Produktlebensdauer jemals zurückgewinnen könnte.

Genau dieselbe technische Struktur kann jedoch bei einem strategischen Kernprodukt wirtschaftlich problematisch sein. Wenn kontinuierlich neue Features entstehen, viele Integrationen verändert werden, regulatorische Reaktionsfähigkeit wichtig ist, Sicherheitskorrekturen schnell erfolgen müssen, die Entwicklerorganisation wächst oder das Produkt noch viele Jahre betrieben werden soll, wird Änderbarkeit selbst zu einem Produktionsfaktor.

Ein Big Ball of Mud kann bei einem Produkt am Ende seines Lebenszyklus wirtschaftlich rational toleriert werden. Problematisch wird es, wenn das Unternehmen von derselben Struktur gleichzeitig kontinuierliche Veränderung erwartet.

Die entscheidende Frage ist deshalb nicht, ob der Code modernen Architekturvorstellungen entspricht.

Sie lautet:

Welchen Preis bezahlt das Unternehmen dafür, dieses System weiterhin verändern zu können?

Dieser Preis kann aus zusätzlichen Entwicklungsstunden bestehen. Er kann sich aber ebenso als Koordinationsaufwand, längere Lead Time, geringere Schätzbarkeit, verspäteter Nutzen, erschwertes Onboarding, gebundene Expertenkapazität oder verlorene strategische Optionen zeigen.

Und er kann sich verändern.

Ein System, das gestern noch wirtschaftlich sinnvoll im Maintenance-Modus betrieben wurde, kann morgen eine vollkommen andere Bewertung benötigen, wenn sich Produktstrategie, Regulierung, Sicherheitslage oder verbleibende Lebensdauer ändern.

Deshalb ist die Ökonomie eines Big Ball of Mud keine statische Eigenschaft des Codes.

Sie ist ein Verhältnis zwischen technischem Zustand und den Veränderungen, die eine Organisation diesem System heute und in Zukunft zumuten muss.

Fazit

Ein Big Ball of Mud kann wirtschaftlich lange funktionieren.

Wenn ein Produkt stabil ist, nur noch selten verändert wird und seine verbleibende Lebensdauer begrenzt ist, kann es vollkommen rational sein, technische Erosion zu akzeptieren. Eine umfassende Sanierung besitzt selbst Kosten, Risiken und Opportunity Costs. Nicht jede technische Schuld muss zurückgezahlt werden.

Mit wachsendem Änderungsbedarf verändert sich diese Rechnung jedoch.

Dann kann ein zunehmender Anteil der Entwicklungskapazität in Arbeiten fließen, die keinen neuen fachlichen Wert schaffen, sondern die Veränderung des bestehenden Systems erst ermöglichen: Verständnis, Regression, Koordination, Workarounds, Rework und Absicherung. Technische Abhängigkeiten können Lead Time erzeugen, unbekannte Änderungsradien können die ohnehin schwierige Aufwandsschätzung zusätzlich belasten und hohe Änderungskosten können Produktentscheidungen beeinflussen, bevor überhaupt Code geschrieben wird.

Gleichzeitig entstehen Kosten außerhalb der einzelnen Änderung. Neue Entwickler müssen historisches Systemwissen erwerben und binden dabei erfahrene Kollegen. Verlässt ein Wissensträger das Unternehmen, kann schwer ersetzbares Wissen verloren gehen. Wenn Entwicklungskapazität für strukturell verursachte Zusatzarbeit gebunden ist, fehlen nicht nur Stunden – es fehlen die Features, Verbesserungen und Risiken, die in dieser Zeit alternativ hätten bearbeitet werden können.

Trotzdem wäre es falsch, daraus eine allgemeine Modernisierungspflicht abzuleiten.

Die Entscheidung, einen Big Ball of Mud weiterzubetreiben, ist vielmehr eine wirtschaftliche Wette auf die Zukunft. Sie wird plausibler, wenn der erwartete Änderungsbedarf gering bleibt, die verbleibende Lebensdauer begrenzt ist, Onboarding und Wissensverlust beherrschbar sind und seltene zwingende Veränderungen innerhalb der bestehenden Struktur weiterhin kontrolliert umgesetzt werden können.

Denn ein Teil des tatsächlichen Änderungsbedarfs entzieht sich der eigenen Roadmap. Sicherheitslücken, regulatorische Anforderungen, Plattformänderungen oder externe Schnittstellen können eine Reaktion verlangen, auch wenn niemand mehr ein neues Feature geplant hat.

Der wirtschaftliche Wert von Architektur liegt nicht nur darin, Änderungen billiger zu machen. Er liegt auch darin, ihre Kosten, ihre Dauer und ihre Risiken innerhalb eines beherrschbaren Korridors zu halten.

Ein eingefrorener Feature-Backlog friert nicht die Umwelt ein, in der die Software betrieben wird.

Ein Unternehmen bezahlt für einen Big Ball of Mud deshalb nicht nur mit Entwicklungszeit. Im ungünstigsten Fall bezahlt es mit seiner Fähigkeit, auf Veränderung zu reagieren, wenn es diese Veränderung nicht mehr selbst aufschieben kann.

Literatur

• Besker, T., Martini, A. & Bosch, J. (2019). Software Developer Productivity Loss Due to Technical Debt – A replication and extension study examining developers’ development work. Journal of Systems and Software, 156, 41–61. DOI: 10.1016/j.jss.2019.06.004.
• Britto, R., Cruzes, D. S., Šmite, D. & Sablis, A. (2018). Onboarding software developers and teams in three globally distributed legacy projects: A multi-case study. Journal of Software: Evolution and Process, 30(4), e1921. DOI: 10.1002/smr.1921.
• Carrière, S. J., Kazman, R. & Ozkaya, I. (2010). A cost-benefit framework for making architectural decisions in a business context. Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering, Volume 2, 149–157. DOI: 10.1145/1810295.1810317.
• Cataldo, M., Herbsleb, J. D. & Carley, K. M. (2008). Socio-technical congruence: A framework for assessing the impact of technical and work dependencies on software development productivity. Proceedings of the Second ACM-IEEE International Symposium on Empirical Software Engineering and Measurement, 2–11. DOI: 10.1145/1414004.1414008.
• Cohen, M. A., Eliashberg, J. & Ho, T.-H. (1996). New Product Development: The Performance and Time-to-Market Tradeoff. Management Science, 42(2), 173–186. DOI: 10.1287/mnsc.42.2.173.
• Jørgensen, M. (2004). A review of studies on expert estimation of software development effort. Journal of Systems and Software, 70(1–2), 37–60. DOI: 10.1016/S0164-1212(02)00156-5.
• Jørgensen, M. (2007). Forecasting of software development work effort: Evidence on expert judgement and formal models. International Journal of Forecasting, 23(3), 449–462. DOI: 10.1016/j.ijforecast.2007.05.008.
• Jørgensen, M. & Shepperd, M. J. (2007). A Systematic Review of Software Development Cost Estimation Studies. IEEE Transactions on Software Engineering, 33(1), 33–53. DOI: 10.1109/TSE.2007.3.
• Lehman, M. M. (1980). Programs, life cycles, and laws of software evolution. Proceedings of the IEEE, 68(9), 1060–1076. DOI: 10.1109/PROC.1980.11805.
• Lehman, M. M. (1996). Laws of Software Evolution Revisited. In: Montangero, C. (Hrsg.), Software Process Technology, Lecture Notes in Computer Science, Vol. 1149, 108–124. Springer. DOI: 10.1007/BFb0017737.
• Robillard, M. P. (2021). Turnover-Induced Knowledge Loss in Practice. Proceedings of the 29th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 1292–1302. DOI: 10.1145/3468264.3473923.
• Sullivan, K. J., Griswold, W. G., Cai, Y. & Hallen, B. (2001). The Structure and Value of Modularity in Software Design. Proceedings of the 8th European Software Engineering Conference held jointly with the 9th ACM SIGSOFT International Symposium on Foundations of Software Engineering, 99–108. DOI: 10.1145/503209.503224.
• Zhang, Z., Zhang, H., Qian, Z. & Lau, B. (2021). An Investigation of the Android Kernel Patch Ecosystem. 30th USENIX Security Symposium (USENIX Security 21), 3649–3666. USENIX Association.