Wie sich technische Schuld messen lässt
Technische Schuld ist keine physikalische Größe, aber es gibt etablierte Näherungen. Die verbreitetsten arbeiten mit statischer Code-Analyse. Werkzeuge wie SonarQube schätzen auf Basis der SQALE-Methode einen Remediation-Aufwand in Personenzeit und setzen ihn ins Verhältnis zum geschätzten Aufwand, das System vollständig neu zu schreiben. Aus dieser Verhältniszahl leitet sich ein Maintainability Rating von A bis E ab. Die absolute Zahl ist mit Vorsicht zu genießen — sie beruht auf pauschalen Aufwandsannahmen pro Regelverstoß. Als Trendindikator über Monate hinweg ist sie dennoch brauchbar: entscheidend ist, ob die Kurve steigt oder fällt.
Ergänzend liefern Liefer- und Betriebskennzahlen ein Bild, das Entscheider oft besser verstehen als jede Code-Metrik. Die im DORA-Forschungsprogramm etablierten Kennzahlen — Deployment-Frequenz, Vorlaufzeit für Änderungen, Change Failure Rate und Wiederherstellungszeit — messen nicht den Code, sondern seine Konsequenzen. Eine dauerhaft hohe Change Failure Rate, also ein hoher Anteil an Releases, die zu Störungen führen, ist ein belastbares Symptom fehlender Test- und Architektur-Investitionen.
- Code-Metriken: zyklomatische Komplexität, Duplikationsgrad, Testabdeckung, Regelverstöße pro tausend Zeilen.
- Historien-Metriken: Änderungshäufigkeit pro Datei, Anzahl der Entwickler pro Modul, Alter der ältesten offenen Abhängigkeits-Updates.
- Wirkungs-Metriken: Change Failure Rate, Vorlaufzeit bis Produktion, Anteil ungeplanter Arbeit im Sprint.
Tilgungsstrategien
Der Großteil technischer Schuld wird nie durch ein Großprojekt abgetragen, sondern durch kontinuierliche kleine Zahlungen. Drei Vorgehensweisen haben sich durchgesetzt.
Refactoring-Budget. Ein fester Anteil der Entwicklungskapazität — in der Praxis häufig zwischen zehn und zwanzig Prozent — wird reserviert und nicht gegen Features verhandelt. Der Vorteil liegt weniger in der Höhe als in der Verlässlichkeit: Ein Budget, das bei jedem Termindruck als Erstes gestrichen wird, existiert faktisch nicht.
Boy-Scout-Rule. Die von Robert C. Martin popularisierte Regel lautet, jeden berührten Code-Bereich etwas sauberer zu hinterlassen, als man ihn vorgefunden hat. Der Effekt ist, dass Tilgung genau dort geschieht, wo der Zins anfällt — in den Bereichen mit hoher Änderungsfrequenz. Sie funktioniert nur mit belastbaren automatisierten Tests, weil sonst jede Aufräumaktion ein Risiko ist.
Strangler-Fig-Pattern. Für Architektur-Schuld, die sich nicht lokal beheben lässt, hat Martin Fowler dieses Muster beschrieben: Ein neues System wächst um das alte herum, indem einzelne Funktionsbereiche nacheinander abgefangen und im Neubau bedient werden, bis das Altsystem keine Aufgaben mehr hat und abgeschaltet werden kann. Gegenüber einer vollständigen Neuentwicklung auf der grünen Wiese hat das den Vorteil, dass das Geschäft durchgehend lauffähig bleibt und jeder Schritt einzeln zurückgenommen werden kann.
Realbeispiel: Migration von Shopware 5 auf Shopware 6
Ein greifbares Beispiel aus dem E-Commerce ist der Versionssprung von Shopware 5 auf Shopware 6. Shopware 5 basiert auf einer anderen technischen Grundlage als Shopware 6, weshalb individuelle Erweiterungen nicht einfach übernommen werden können, sondern neu entwickelt werden müssen. Händler, die über Jahre Anpassungen direkt im Template oder in Plugin-Überschreibungen vorgenommen haben, statt die vorgesehenen Erweiterungspunkte zu nutzen, stehen bei der Migration vor genau der aufgelaufenen Rechnung: Jede unsaubere Anpassung ist nun ein Posten im Migrationsbudget. Wer dagegen entlang der offiziellen Erweiterungsmechanismen gearbeitet hat, migriert deutlich günstiger. Die Schuld wurde in beiden Fällen aufgenommen — nur im zweiten Fall laufend getilgt.
Technische Schuld und KI-generierter Code
Mit dem breiten Einsatz von KI-Assistenten in der Softwareentwicklung hat die Diskussion eine neue Dimension bekommen. Generierte Codevorschläge sind syntaktisch sauber und lokal plausibel, entstehen aber ohne vollständiges Bild der Systemarchitektur. Typische Muster, die daraus folgen: duplizierte Hilfsfunktionen statt Wiederverwendung, Lösungen, die an bestehenden Abstraktionen vorbeigehen, und Code, den niemand im Team vollständig durchdrungen hat.
Der entscheidende Unterschied zu klassischer Schuld ist das Tempo. Code entsteht schneller als das Verständnis über ihn, und Review-Kapazität wird zum Engpass. Die etablierten Gegenmittel ändern sich dadurch nicht, sie werden nur wichtiger: verbindliche Code-Reviews durch Menschen, automatisierte Qualitäts-Gates in der Build-Pipeline und die Regel, dass niemand Code in Produktion bringt, den er nicht erklären kann.
Abgrenzung und häufige Missverständnisse
Technische Schuld ist nicht dasselbe wie Fehler. Ein Bug ist falsches Verhalten; technische Schuld ist korrektes Verhalten, das teuer zu ändern ist. Sie ist auch nicht dasselbe wie Legacy-Software: Ein altes System kann sauber strukturiert und gut wartbar sein, ein sechs Monate altes ebenso gut unbeherrschbar.
Ein zweites Missverständnis ist die Gleichsetzung mit Schlamperei. Die Metapher wurde ausdrücklich geprägt, um eine rationale Entscheidung beschreibbar zu machen — nämlich früher zu liefern und dafür später zu zahlen. Sie verliert ihren Sinn, wenn sie zum Sammelbegriff für alles wird, was einem am Code nicht gefällt.
Drittens ist null Schuld kein sinnvolles Ziel. Ein Team, das jede Entscheidung bis zur Perfektion ausarbeitet, liefert zu spät und lernt zu wenig über den tatsächlichen Bedarf. Die betriebswirtschaftlich richtige Frage lautet nicht „wie vermeiden wir Schuld", sondern „welche Schuld nehmen wir bewusst auf, zu welchem Zins, und wann tilgen wir sie".
Relevanz für Entscheider im Mittelstand
Für Geschäftsführung und Fachbereiche ist technische Schuld vor allem deshalb relevant, weil sie die Reaktionsfähigkeit des Unternehmens begrenzt. Sie wird selten als Posten sichtbar, sondern als Nebensatz: Eine neue Zahlungsart lässt sich nicht kurzfristig anbinden. Ein zusätzlicher Vertriebskanal erfordert ein Projekt statt einer Konfiguration. Eine gesetzliche Anforderung mit fester Frist wird knapp.
Drei Fragen helfen, den Zustand ohne technische Tiefe einzuschätzen: Wie lange dauert es von der fertigen Entscheidung bis zur produktiven Änderung? Wie viel Prozent der Entwicklungszeit fließt in ungeplante Arbeit? Und wie oft führt ein Release zu einer Störung? Verschlechtern sich diese Werte über mehrere Quartale, ist das Zinsniveau zu hoch — unabhängig davon, was einzelne Code-Metriken sagen.
Bei der Auswahl von Dienstleistern ist der Umgang mit dem Thema ein Qualitätssignal. Wer Refactoring-Anteile im Angebot ausweist, Testabdeckung als Lieferbestandteil behandelt und Architekturentscheidungen dokumentiert, verkauft kurzfristig teurer und langfristig günstiger.
Ausblick
Zwei Entwicklungen prägen das Thema absehbar. Zum einen rückt Abhängigkeits- und Infrastruktur-Schuld durch die Regulierung von Lieferketten stärker in den Fokus: Veraltete Komponenten sind nicht mehr nur ein Wartungsthema, sondern zunehmend ein Compliance-Thema. Zum anderen verschiebt KI-gestützte Entwicklung den Engpass von der Code-Erzeugung zum Code-Verständnis. Parallel entstehen Werkzeuge, die dieselbe Technologie für die Gegenrichtung nutzen — automatisierte Abhängigkeits-Aktualisierungen, Testgenerierung für ungetesteten Altcode, Vorschläge für Architektur-Refactorings. Welche Seite überwiegt, entscheidet sich nicht an der Technologie, sondern daran, ob Organisationen Tilgung als festen Bestandteil ihrer Kapazitätsplanung behandeln.
Häufige Fragen
Ist technische Schuld immer schlecht?
Nein. Bewusst aufgenommene Schuld mit Tilgungsplan ist ein legitimes Mittel, um früher am Markt zu sein oder eine Annahme schneller zu prüfen. Problematisch wird sie, wenn sie unbemerkt aufläuft oder nie zurückgezahlt wird.
Wie viel Kapazität sollte ein Team für Tilgung reservieren?
Es gibt keinen allgemeingültigen Wert. Verbreitet ist ein fester zweistelliger Prozentanteil der Sprint-Kapazität. Wichtiger als die Höhe ist, dass der Anteil nicht bei jedem Termindruck als erster gestrichen wird.
Lässt sich technische Schuld in Euro beziffern?
Nur näherungsweise. Werkzeuge wie SonarQube schätzen einen Behebungsaufwand in Personenzeit, der sich in Kosten umrechnen lässt. Diese Zahl beruht jedoch auf pauschalen Annahmen und taugt eher als Trendindikator als für eine Investitionsrechnung.
Ist ein kompletter Neuaufbau die bessere Lösung?
Selten. Eine Neuentwicklung auf der grünen Wiese bindet über lange Zeit Kapazität, ohne geschäftlichen Mehrwert zu liefern, und reproduziert häufig alte Fehler in neuer Technologie. Schrittweise Ablösung nach dem Strangler-Fig-Muster ist in den meisten Fällen risikoärmer.
Wer entscheidet über die Tilgung?
Die Priorisierung gehört in dieselbe Runde, die auch über Features entscheidet. Entwicklungsteams liefern die fachliche Einschätzung, welche Bereiche den höchsten Zins verursachen; die Produkt- oder Geschäftsverantwortung entscheidet über die Verteilung der Kapazität.
Weiterführende Informationen zum Ursprung der Metapher finden sich in der englischsprachigen Wikipedia-Übersicht zu Technical Debt.
