Technische Schulden messen: So priorisieren Sie Ihr Refactoring-Budget

Wer technische Schulden messen will, stößt zuerst auf ein Definitionsproblem. Der Begriff stammt aus den 1990er-Jahren von Ward Cunningham und beschreibt ursprünglich den Aufpreis, den ein Team später für schnelle Entscheidungen von heute zahlt. In der Praxis wird daraus schnell ein Gefühl: Der Code ist alt, niemand traut sich an bestimmte Module, jede Änderung dauert länger als sie sollte. Mit einem Gefühl lässt sich ein Budget aber nicht rechtfertigen. Wer beim nächsten Jahresplan Mittel fürs Refactoring beantragen will, braucht Zahlen, die auch vor der Geschäftsführung standhalten und sich mit dem Budget des Vorjahres vergleichen lassen.

Was technische Schulden konkret kosten

Wie groß das Problem ist, hat McKinsey 2020 in einer Erhebung unter Technologieverantwortlichen untersucht. Nach dieser Erhebung von McKinsey (2020) fließen 10 bis 20 Prozent des Budgets für neue Produkte in die Behebung technischer Schulden. Die gleiche Erhebung aus dem Jahr 2020 beziffert den Bestand an technischen Schulden auf 20 bis 40 Prozent des Werts des gesamten Technologiebestands. 60 Prozent der von McKinsey 2020 befragten CIOs sahen einen Anstieg gegenüber den drei Vorjahren. Unternehmen mit aktivem Schuldenmanagement berichteten laut derselben Erhebung von bis zu 50 Prozent zusätzlicher Zeit für Arbeit, die tatsächlich Wert schafft, statt für laufende Wartung.

Diese Zahlen stammen aus einer Befragung von Führungskräften, nicht aus einer technischen Messung einzelner Codebasen. Sie taugen als Orientierung für die Größenordnung. Als Zielwert für das eigene Unternehmen taugen sie nicht.

Technische Schulden messen: Diese Kennzahlen zählen

Eine gängige Kennzahl ist die Technical Debt Ratio, das Verhältnis der Kosten, technische Schulden zu beheben, zu den gesamten Entwicklungskosten. Nach einer Auswertung von Sourcegraph aus dem Jahr 2024 gilt ein Wert im niedrigen einstelligen Prozentbereich als gesund. Wichtiger als der Absolutwert ist laut dieser Auswertung von 2024 der Trend über mehrere Quartale. Ein Team, dessen Ratio von 3 auf 6 Prozent steigt, hat ein Problem, selbst wenn 6 Prozent isoliert betrachtet noch unauffällig wirkt.

Verbreitet ist außerdem das SQALE-Modell, wie es die Analyse-Software SonarQube einsetzt. Es rechnet Verstöße gegen hinterlegte Qualitätsregeln in eine geschätzte Behebungszeit um und stellt sie der geschätzten Entwicklungszeit des gesamten Projekts gegenüber. Das Ergebnis ist eine Kennzahl, die sich über Zeit vergleichen lässt, solange das Regelwerk dahinter nicht ständig verändert wird. Wechselt das Team das Tool oder die Regeln, bricht die Vergleichbarkeit ab. Genau darin liegt eine Schwäche der Methode.

Wo Kennzahlen an ihre Grenzen stoßen

Die Technical Debt Ratio und das SQALE-Modell messen, was ein Analysetool erkennen kann: doppelten Code, überkomplexe Funktionen, fehlende Tests, veraltete Muster. Architekturentscheidungen, die sich erst nach Jahren rächen, etwa eine falsch geschnittene Modulgrenze oder eine Datenbank, die für ein anderes Lastprofil gebaut wurde, fallen durch dieses Raster. Das Gleiche gilt für Wissen, das mit einer einzelnen Person das Unternehmen verlässt.

Ein Team kann eine Ratio von 2 Prozent ausweisen und trotzdem an einem System hängen, das nur noch eine Person versteht. Wer technische Schulden messen will, sollte solche blinden Flecken deshalb schriftlich neben die Kennzahl stellen. Kennzahlen sind ein Ausgangspunkt für das Gespräch mit der Geschäftsführung. Ein Ersatz für dieses Gespräch sind sie nicht. Wer eine Zahl präsentiert, sollte deshalb auch die zwei oder drei Systeme benennen können, bei denen die Zahl aus eigener Erfahrung zu niedrig ausfällt. Ab wann sich eine Modernisierung mehr lohnt als weiteres Ausbessern, zeigt der Beitrag Legacy-Software modernisieren oder ersetzen? Ein Entscheidungsbaum.

Refactoring-Budget priorisieren

Für die Priorisierung hilft eine Faustregel: Module nach Änderungshäufigkeit und Fehlerrate sortieren, nicht nach dem subjektiven Störgefühl einzelner Entwickler. Ein Modul, das selten angefasst wird und trotzdem unschön aussieht, kann liegen bleiben. Ein Modul, das jede Woche Änderungen bekommt und dabei überdurchschnittlich viele Fehler produziert, gehört nach oben auf die Liste. In der Praxis sind das oft Kernmodule wie Preisfindung, Lagerbuchung oder Auftragsabwicklung, also genau die Stellen, an denen sich Fehler am teuersten auswirken.

Wo ein Teil der Schulden aus KI-generiertem Code stammt, lohnt sich vor der Priorisierung ein gesonderter Blick auf die Risiken solcher Codeabschnitte, weil sich dort Sicherheitslücken mit gewöhnlicher Unordnung im Code vermischen können. Ein Korridor von 10 bis 20 Prozent des Entwicklungsbudgets für laufende Schuldentilgung ist ein realistischer Ausgangspunkt, wie ihn auch die McKinsey-Zahlen von 2020 nahelegen. Unternehmen mit besonders alten Kernsystemen landen dabei eher am oberen Ende dieser Spanne.

Häufige Fragen

Wie misst man technische Schulden ohne Tool?

Ganz ohne Tooling zeigt sich der Zustand oft an zwei Symptomen. Erstens die Zeit. Dauert eine kleine Änderung heute deutlich länger als vor einem Jahr, obwohl das Team nicht kleiner geworden ist? Zweitens das Vermeidungsverhalten. Gibt es Dateien oder Module, die Entwickler im Planning lieber umgehen, weil niemand genau weiß, was beim Anfassen passiert? Wer beide Fragen im Team offen bespricht und die Antworten alle paar Monate abgleicht, bekommt ein brauchbares Bild, auch ohne SonarQube oder vergleichbare Software.

Wie viel Budget sollte ins Refactoring fließen?

Ein Korridor von 10 bis 20 Prozent des Entwicklungsbudgets für neue Produkte deckt sich mit dem, was McKinsey 2020 bei den befragten Unternehmen beobachtet hat. Als starrer Wert taugt das trotzdem nicht. Ein junges Produkt mit wenig gewachsenem Code kommt mit deutlich weniger aus, ein zehn Jahre altes Kernsystem mit hoher Änderungsfrequenz braucht eher mehr. Sinnvoller als eine feste Prozentzahl ist ein Betrag, der an die gemessene Technical Debt Ratio gekoppelt ist und bei jeder Budgetrunde neu verhandelt wird.

Woran erkennt man, dass Refactoring zu spät kommt?

Ein deutliches Warnzeichen ist, wenn Schätzungen für neue Features regelmäßig um mehr als das Doppelte danebenliegen, weil niemand vorab abschätzen kann, was eine Änderung im Bestandscode auslöst. Ein zweites Zeichen ist Personalfluktuation, die sich auf die Teams konzentriert, die an den unangenehmsten Systemteilen arbeiten. Kommen beide Signale zusammen, reicht ein einzelner Refactoring-Sprint nicht mehr. Dann wird ein mehrmonatiges Programm mit eigenem Budget nötig.

torck entwickelt Individualsoftware für Industrie und Handel, häufig auf gewachsenen Systemen, bei denen sich über Jahre unbemerkt Schulden angesammelt haben. Die Entwicklungsteams in Maxhütte-Haidhof, Wien und Rabat übernehmen solche Codebasen regelmäßig und wissen, an welcher Stelle eine Kennzahl beim nächsten Budgetgespräch weiterhilft und wo sie nur Papier produziert. Vertragspartner ist die deutsche torck GmbH, das schafft bei mehrjährigen Refactoring-Programmen die nötige Verbindlichkeit. Wer eine Einschätzung der eigenen technischen Schulden braucht, kann das in einem Erstgespräch klären.

Gespräch vereinbaren