Technische Schulden, Architekturerosion und Architekturdrift

Was Ward Cunningham wirklich meinte

Der Begriff technische Schulden stammt aus Ward Cunninghams Erfahrungsbericht über das Portfolio-Management-System WyCash, den er 1992 auf der Konferenz OOPSLA vorstellte. Er schrieb, Code zum ersten Mal auszuliefern sei, als würde man Schulden aufnehmen: Ein wenig Schuld beschleunigt die Entwicklung, solange sie zügig durch eine Überarbeitung zurückgezahlt wird, und gefährlich wird es, wenn sie nicht zurückgezahlt wird: Jede Minute, die man mit nicht ganz richtigem Code verbringt, zählt als Zins auf diese Schuld. Ganze Entwicklungsorganisationen, warnte er, können unter der Schuldenlast zum Stillstand kommen.

Die Metapher wird oft als Erlaubnis missverstanden, schludrigen Code zu schreiben. Cunningham erklärte später (in einem kurzen Video von 2009), dass er das nie gemeint habe. Es ging ihm um Verständnis. Ein Team liefert Code aus, der sein aktuelles, unvollständiges Verständnis eines Problems widerspiegelt, weil man so am schnellsten aus der echten Nutzung lernt. Wenn das Verständnis wächst, passt der Code nicht mehr zu dem, was das Team inzwischen weiß, und jede Änderung muss diese Diskrepanz umgehen. Die Schulden zurückzuzahlen heißt, den Code durch Refactoring so umzubauen, dass er das Gelernte widerspiegelt. Das funktioniert nur, wenn der Code von vornherein sauber genug geschrieben wurde, um refaktoriert werden zu können. So gelesen sind Schulden ein Nebenprodukt des Lernens, nicht der Nachlässigkeit.

Seitdem hat sich der Sprachgebrauch erweitert. Heute umfasst „technische Schulden“ jeden Mangel an innerer Qualität, der künftige Änderungen langsamer oder riskanter macht, ob er aus dem Lernen, bewussten Abkürzungen, Unwissen oder schlichter Vernachlässigung entstanden ist. Die weitere Bedeutung ist nützlich, solange Sie im Kopf behalten, dass die verschiedenen Arten unterschiedliche Antworten verlangen.

Tilgung und Zinsen

Das Finanzvokabular macht die Metapher in Gesprächen mit Nicht-Technikern so wirkungsvoll. Der Tilgungsaufwand ist der Aufwand, der nötig ist, um das Problem zu beheben: das Modul umzustrukturieren, die Datenbank aufzutrennen, den Zyklus aufzulösen. Die Zinsen sind der Mehraufwand, der bei jeder Arbeit anfällt, die das Problem berührt, solange es besteht. Martin Fowlers Beispiel: Wenn ein Feature in sauberem Code vier Tage dauern würde, wegen Altlasten im Code aber sechs dauert, sind die zwei zusätzlichen Tage Zinsen.

Daraus folgen drei Konsequenzen. Erstens: Schulden, die nie berührt werden, kosten nichts: Ein unordentliches Modul, das niemand ändert, verursacht keine Zinsen, und es zu tilgen kann vergeudete Mühe sein. Zweitens: Zinsen haben einen Zinseszinseffekt: Notlösungen werden zum Fundament weiterer Notlösungen, neue Entwickler kopieren die Muster, die sie vorfinden, und die Kosten der späteren Reparatur steigen. Drittens: Tilgung ist eine Investitionsentscheidung: Es lohnt sich, den Tilgungsaufwand zu leisten, wenn die Zinsen, die Sie über einen sinnvollen Zeitraum sparen, ihn übersteigen. Damit wird aus einem emotionalen Argument („der Code ist ein Chaos“) ein wirtschaftliches („dieses Modul kostet uns elf Tage pro Quartal“).

Fowlers Quadrant der technischen Schulden

Nicht alle Schulden sind gleich. 2009 schlug Martin Fowler vor, Schulden entlang zweier Achsen einzuordnen: ob sie bewusst oder unbeabsichtigt aufgenommen wurden und ob die Entscheidung umsichtig oder leichtsinnig war. Die vier Kombinationen verlangen unterschiedliche Antworten.

Umsichtig und bewusst: Das Team kennt das bessere Design, hält es für die Kosten wert, jetzt auszuliefern, und plant die Tilgung. Das ist Cunninghams ursprünglicher Sinn, und es kann geschäftlich klug sein: etwa bei einem Start-up, das erst die Nachfrage nachweist, bevor es in Skalierung investiert. Leichtsinnig und bewusst: Das Team weiß es besser, verzichtet aber auf Design, weil es glaubt, keine Zeit zu haben, und bremst sich damit meist innerhalb weniger Wochen selbst aus. Leichtsinnig und unbeabsichtigt: Das Team weiß nicht genug, um zu erkennen, dass es Schulden aufbaut; die Abhilfe sind Fähigkeiten, Reviews und Mentoring, nicht Refactoring allein. Umsichtig und unbeabsichtigt: Ein fähiges Team leistet gute Arbeit und versteht erst später, wie es hätte strukturiert sein sollen. Fowler argumentiert, dass dies für jedes lernende Team unvermeidlich ist, weshalb kontinuierliches Refactoring zur normalen Arbeit gehört und kein Zeichen des Scheiterns ist.

Architekturschulden und Codeschulden

Schulden gibt es auf jeder Ebene, aber ihr Kostenprofil ändert sich mit der Größenordnung. Codeschulden liegen innerhalb eines Moduls: duplizierte Logik, eine Funktion, die fünf Dinge tut, fehlende Tests, schlechte Namen. Sie sind real, aber lokal; ein Entwickler kann sie meist in Stunden oder Tagen tilgen, oft während er an einem benachbarten Feature arbeitet. Architekturschulden liegen in der Struktur: Services, die sich eine Datenbank teilen, sodass keiner sein Schema allein ändern kann; eine Domäne, die entlang der falschen Linien aufgeteilt ist, sodass jedes Feature vier Teams berührt; eine synchrone Aufrufkette, durch die ein langsamer Service den Checkout lahmlegt; ein Framework, das mit jeder Schicht verschweißt ist. Ihre Tilgung berührt viele Module, oft viele Teams und manchmal Daten.

Die Forschung stützt die Intuition, dass strukturelle Schulden die teure Art sind. Eine Umfrage unter 1831 Entwicklern und Architekten, die Neil Ernst und Kollegen am Software Engineering Institute 2015 durchführten, ergab, dass Architekturentscheidungen die wichtigste genannte Quelle technischer Schulden waren, noch vor Problemen auf Codeebene. Werkzeuge, die Code Smells melden, finden Codeschulden gut und Architekturschulden schlecht, weil das Problem in den Beziehungen zwischen Teilen liegt und nicht in einer einzelnen Datei.

Architekturschulden sind aus demselben Grund wichtig, aus dem Architektur überhaupt wichtig ist: Wie Warum Architektur zählt gezeigt hat, sind strukturelle Entscheidungen diejenigen mit den höchsten Änderungskosten.

Erosion und Drift

Architekturschulden entstehen oft nicht durch eine schlechte Entscheidung, sondern durch Tausende kleiner Änderungen. Dewayne Perry und Alexander Wolf benannten in ihrem Aufsatz „Foundations for the Study of Software Architecture“ von 1992 zwei Wege, auf denen das geschieht. Architekturerosion wird durch Verstöße gegen die Architektur verursacht: ein Controller, der die Datenbank direkt abfragt und dabei die Service-Schicht umgeht; ein Modul, das in die internen Tabellen eines anderen greift. Jeder Verstoß macht das System brüchiger, als würde man eine tragende Wand entfernen. Architekturdrift wird durch mangelnde Rücksicht auf die Architektur verursacht: Änderungen, die gegen keine ausdrückliche Regel verstoßen, aber die beabsichtigten Konzepte ignorieren, sodass das System nach und nach an Stimmigkeit und klarer Form verliert. Drift ist weniger unmittelbar gefährlich als Erosion, verschleiert aber die Architektur, was wiederum Verstöße erleichtert.

Spätere Forscher verwenden „Erosion“ oft für die weitere Lücke zwischen der beabsichtigten Architektur (dem, was die Dokumente und der Kopf des Architekten sagen) und der implementierten Architektur (dem, was der Code tatsächlich tut). Wie auch immer die Begriffe lauten, die Ursachen sind vertraut:

Termindruck, der den kürzesten Weg statt des richtigen belohnt. Wissensverlust, wenn die Leute gehen, die das Design verstanden haben, und neue Mitarbeitende kopieren, was sie vorfinden. Unsichtbare Architektur: Regeln, die nur in einem Wiki stehen, das niemand liest, ohne dass der Build sie durchsetzt. Geänderte Anforderungen, durch die eine einst gute Struktur schlecht zum Problem passt. Organisatorischer Wandel: Nach dem Gesetz von Conway erzeugt eine Umorganisation Druck, das System entlang neuer Teamgrenzen umzuformen. Alternde Technologie: Frameworks und Plattformen, deren Support ausläuft, werden zu Schulden, ohne dass jemand den Code anfasst.

Schulden erkennen

Schulden, die Sie nicht sehen, können Sie nicht steuern, und das Bauchgefühl ist unzuverlässig: Entwickler beklagen sich meist am lautesten über den Code, den sie am häufigsten anfassen, was nützlich ist, aber sie wissen selten, wie viel jedes Problem kostet. Mehrere Techniken machen Schulden sichtbar.

Hotspots. Adam Tornhills Your Code as a Crime Scene (2015; zweite Auflage 2024) wendet Ideen der Forensik auf die Historie der Versionskontrolle an. Ein Hotspot ist Code, der sowohl komplex ist als auch häufig geändert wird. Komplexität allein reicht nicht: Eine komplexe Datei, die niemand anfasst, kostet keine Zinsen. Änderungshäufigkeit allein reicht auch nicht: Eine einfache Konfigurationsdatei kann sich täglich ändern, ohne Schaden anzurichten. Wo beides zusammenkommt, werden bei jedem Commit Zinsen gezahlt, und dort zahlt sich Tilgung zuerst aus. In den meisten Codebasen entfällt der Großteil der Änderungsaktivität auf einen kleinen Teil der Dateien.

Change Coupling. Dateien oder Services, die immer wieder in denselben Commits geändert werden, sind gekoppelt, ob der Code eine Abhängigkeit zeigt oder nicht. Wenn jede Änderung am Preisservice mit einer Änderung am Rechnungsservice einhergeht, sind sie eine Sache, die vorgibt, zwei zu sein. Change Coupling über Team- oder Servicegrenzen hinweg ist ein starkes Anzeichen für Architekturschulden.

Abhängigkeitszyklen und Regelverstöße. Statische Analyse kann den tatsächlichen Abhängigkeitsgraphen zeichnen und mit dem beabsichtigten vergleichen. Zyklen (A nutzt B, B nutzt C, C nutzt A) bedeuten, dass keines der drei für sich verstanden, getestet oder ausgeliefert werden kann. Architekturregeln („die Domänenschicht darf nicht von der Webschicht abhängen“) lassen sich bei jedem Build automatisch prüfen; das sind Fitness Functions, die Kapitel 11 behandelt.

Trends in der Auslieferung. Steigende Durchlaufzeiten für Änderungen, mehr durchrutschende Fehler pro Release, längere Einarbeitung, mehr Abstimmungsmeetings pro Feature und wachsende Scheu, bestimmte Bereiche anzufassen, sind nachlaufende Indikatoren für aufgelaufene Zinsen. Die DORA-Metriken für die Auslieferung (etwa Durchlaufzeit von Änderungen und Änderungsfehlerrate) bieten eine einheitliche Möglichkeit, einige davon über die Zeit zu verfolgen.

Schulden steuern

Keine gesunde Codebasis hat null Schulden, und der Versuch, null zu erreichen, ist selbst Verschwendung. Das Ziel ist, Schulden sichtbar, bewusst und tragbar zu halten. Teams, denen das gut gelingt, kombinieren mehrere Praktiken.

Ein Schuldenregister. Halten Sie bedeutende Schuldenposten dort fest, wo das Team seine Arbeit plant: worin das Problem besteht, wo es liegt, wie es entstanden ist, den geschätzten Tilgungsaufwand, die geschätzten Zinsen (mit Belegen wie Hotspot-Daten oder aktuellen Tickets) und den Auslöser für die Tilgung. Ein Register macht aus vagen Klagen eine Liste, die sich zusammen mit Features priorisieren lässt.

Ein fester Anteil der Kapazität. Viele Teams reservieren einen gleichbleibenden Anteil jeder Iteration, meist irgendwo zwischen 10 und 20 Prozent, für die Tilgung von Schulden und andere Verbesserungsarbeit. Für eine magische Zahl gibt es keine Belege; entscheidend ist, dass der Anteil geschützt ist und nicht jedes Mal verschwindet, wenn ein Termin naht.

Refactoring parallel zu Features. Am günstigsten tilgen Sie Schulden, wenn Sie ohnehin in dem Bereich arbeiten, weil Sie den Kontext im Kopf haben und die Tests laufen. Fowler nennt das opportunistisches Refactoring. Seine alltägliche Form ist die Pfadfinderregel, die Robert C. Martin bekannt gemacht hat: Hinterlassen Sie den Code ein wenig sauberer, als Sie ihn vorgefunden haben. Weil Hotspots per Definition dort liegen, wo Features landen, konzentriert sich der Aufwand so ganz von selbst dort, wo die Zinsen am höchsten sind.

Geplante strukturelle Tilgung. Architekturschulden lassen sich selten allein mit kleinen Schritten abbauen. Sie brauchen ein ausdrückliches, finanziertes Arbeitspaket mit einem Ziel, einem Plan für eine schrittweise Migration und der Unterstützung der Stakeholder. Techniken wie das Strangler-Fig-Muster (Kapitel 11, Altsysteme modernisieren) erlauben es einem Team, eine Struktur Stück für Stück zu ersetzen, ohne alles auf einen Schlag neu zu schreiben.

Vorbeugung. Automatisierte Architekturprüfungen im Build, Code-Reviews, die neben dem Stil auch auf die Struktur achten, und aktuelle Entscheidungsdokumente bremsen Erosion und Drift an der Quelle.

Schulden für nicht technische Stakeholder erklären

Auftraggeber und Product Owner müssen nichts über zyklische Abhängigkeiten hören; sie müssen die Auswirkungen auf das verstehen, was ihnen wichtig ist: Tempo, Kosten, Risiko und Kundenerlebnis. Die Finanzmetapher ist hier ein Geschenk, vorausgesetzt, Sie verwenden sie mit Zahlen.

Sprechen Sie in Zeit und Geld: „Jede Änderung am Checkout kostet uns etwa drei zusätzliche Entwicklertage, weil Zahlung und Bestellungen so ineinander verheddert sind.“ Sprechen Sie in Risiko: „Zwei unserer letzten vier Incidents begannen in diesem Modul.“ Sprechen Sie in Optionen: „Bis wir das trennen, können wir die neuen Zahlungsarten nicht anbieten, die der Vertrieb angefragt hat.“ Und stellen Sie die Tilgung als Investition mit Amortisationszeit dar, nicht als Bitte um Entwicklungszeit. Vermeiden Sie zwei Fallen: Schulden als moralisches Versagen der Vorgänger darzustellen (sie sind meist umsichtig oder unbeabsichtigt entstanden) und einen unbefristeten „Refactoring-Sprint“ ohne messbares Ergebnis zu verlangen.