Technical Debt erkennen und gezielt abbauen
Technical Debt ist geliehene Zeit. Man nimmt sie auf, um schneller zu liefern, und zahlt sie mit Zinsen zurück – in Form von Entwicklungsgeschwindigkeit, die Jahr für Jahr sinkt. Das Problem dabei: Die Zinsen tauchen in keiner Bilanz auf, und wer sie bezahlt, merkt es oft nicht. Dieser Artikel zeigt, woran Sie technische Schulden erkennen, wie Sie ihre Kosten in Euro ausdrücken und mit welchen Strategien der Abbau tatsächlich gelingt.
Die Kredit-Metapher und ihre Grenzen
Der Begriff geht auf Ward Cunningham zurück, und die Metapher trägt überraschend weit. Man nimmt einen Kredit auf – eine Abkürzung im Code, eine schnelle Lösung ohne Test, eine Struktur, die für heute reicht – und gewinnt damit Zeit. Diese Zeit ist echt und manchmal die richtige Entscheidung. Aber ab dem Moment der Aufnahme laufen Zinsen: jede weitere Änderung an dieser Stelle kostet mehr als sie müsste.
Zwei Dinge unterscheiden technische Schulden von einem Bankkredit, und beide machen sie gefährlicher.
Die Zinsen sind variabel und unsichtbar. Niemand bekommt eine Abrechnung. Sie zeigen sich als Aufwandsschätzungen, die höher ausfallen als früher, als Fehler, die immer wieder auftreten, als Zögern vor Änderungen. Jede dieser Beobachtungen hat lokale Erklärungen, und darum wird die eigentliche Ursache selten benannt.
Es gibt keine Tilgungsautomatik. Ein Kredit läuft ab. Technische Schulden bleiben, bis jemand sie bewusst abbaut – und wachsen in der Zwischenzeit, weil neuer Code auf alten aufsetzt.
Was Technical Debt nicht ist: schlechter Code. Schlechter Code ist Inkompetenz oder Nachlässigkeit. Technische Schulden sind der Preis einer Entscheidung – oft einer vernünftigen. Die Unterscheidung ist wichtig, weil sie das Gespräch aus dem Vorwurf heraushält. Es geht nicht darum, wer Fehler gemacht hat, sondern darum, welche Verbindlichkeiten die Codebasis trägt.
Vier Arten technischer Schulden
Martin Fowler hat die nützlichste Einteilung geliefert: zwei Achsen, bewusst gegen unbewusst und umsichtig gegen unbedacht.
| Umsichtig | Unbedacht | |
|---|---|---|
| Bewusst | Wir liefern jetzt und räumen nach dem Launch auf | Für Tests ist keine Zeit |
| Unbewusst | Jetzt wissen wir, wie es richtig gegangen wäre | Was ist Schichtenarchitektur? |
Die Einordnung ist keine Theorie, sondern bestimmt die Gegenmaßnahme:
Hinzu kommt eine Dimension, die in den kommenden Jahren das Thema prägen wird: architektonische Schulden. Analystenhäuser erwarten, dass bis 2026 rund 80 Prozent der technischen Schulden architektonischer Natur sind – also nicht durch Refactoring einzelner Stellen lösbar, sondern nur durch strukturelle Umbauten. Das verschiebt das Gespräch von Codequalität zu Architekturentscheidungen, wie sie etwa der Artikel Monolith oder Microservices behandelt.
Warnsignale: woran Sie es merken
Technische Schulden kündigen sich zuverlässig an. Diese Signale sind in der Praxis die aussagekräftigsten:
Die wirksamste Diagnosefrage: Fragen Sie Ihr Team, welche drei Stellen der Codebasis sie am liebsten nicht anfassen würden – und warum. Die Antworten sind präziser als jede automatisierte Analyse, weil sie Änderungsaufwand und Risiko gleichzeitig abbilden. Automatisierte Werkzeuge finden Verstöße gegen Regeln; Menschen finden die Stellen, die tatsächlich Geld kosten.
Was es kostet: ein Rechenbeispiel
Für das Gespräch mit der Geschäftsführung brauchen Sie Zahlen, keine Metaphern. Die Studienlage gibt dafür einen Rahmen, mit allen Vorbehalten gegenüber Selbstauskunftsumfragen.
| Quelle | Aussage |
|---|---|
| Stripe / Harris Poll, Developer Coefficient | Entwickler verbringen rund ein Drittel ihrer Arbeitszeit mit technischen Schulden; mit Wartung und schlechtem Code zusammen etwa 42 Prozent |
| Besker, Martini und Bosch, 2019 | 18 bis 23 Prozent der Entwicklungszeit gehen verloren – die konservativere, akademisch erhobene Zahl |
| CISQ, 2022 | allein in den USA rund 1,5 Billionen Dollar aufgelaufene technische Schulden |
| McKinsey | technische Schulden entsprechen 20 bis 40 Prozent des Werts eines Technologiebestands |
| Sonar | über fünf Jahre rund 1,5 Millionen Dollar Schuldenkosten pro einer Million Codezeilen |
Rechnen Sie es für Ihren Fall durch. Ein Team mit fünf Entwicklern, Vollkosten 95.000 Euro pro Person und Jahr, ergibt 475.000 Euro Entwicklungsbudget. Nimmt man die konservativen 20 Prozent Reibungsverlust, verschwinden davon 95.000 Euro pro Jahr – nicht in Kaffeepausen, sondern in Suchen, Umwegen, Nacharbeit und Fehlerbehebung an Stellen, die vermeidbar wären.
Diese Rechnung hat eine Eigenschaft, die sie im Management-Gespräch stark macht: Sie ist nicht die Frage, ob Geld ausgegeben wird, sondern wo. Ein Refactoring-Budget von 15 Prozent kostet nicht zusätzlich – es verschiebt Geld von unkontrollierter Nacharbeit in kontrollierte Verbesserung.
Der Zinseszins-Effekt: Entscheidend ist nicht der Jahresbetrag, sondern seine Richtung. Steigt der Reibungsverlust um nur 2 Prozentpunkte pro Jahr, ist in zehn Jahren jeder zweite Entwicklereuro Zinszahlung. Dieser Verlauf ist der eigentliche Grund, warum manche Produkte irgendwann nicht mehr weiterentwickelt, sondern ersetzt werden – und ein Ersatz kostet immer ein Vielfaches des Abbaus.
Strategien, die funktionieren
Ein festes Budget, kein gelegentlicher Kraftakt
Die wirksamste Maßnahme ist unspektakulär: ein fester Anteil der Entwicklungskapazität für Qualitätsarbeit, verbindlich reserviert. Verbreitet und praxiserprobt sind 15 bis 20 Prozent. Der Unterschied zu guten Absichten ist die Verbindlichkeit – ein Anteil, der in jedem Sprint verplant wird und nicht der erste ist, der bei Terminen gestrichen wird.
Was dabei nicht funktioniert: Qualität als etwas zu behandeln, das man macht, wenn Zeit bleibt. Es bleibt nie Zeit.
Die Boy-Scout-Rule
Hinterlasse jede Stelle etwas besser, als du sie gefunden hast. Keine große Umbauaktion, sondern ein besserer Name, ein extrahiertes Stück Logik, ein ergänzter Test – immer begrenzt auf den Bereich, der ohnehin angefasst wird. Der Vorteil: Verbesserung konzentriert sich automatisch dort, wo sie am meisten wirkt, nämlich im Code, der tatsächlich geändert wird.
Nach Änderungshäufigkeit priorisieren, nicht nach Hässlichkeit
Der häufigste Fehler beim Abbau ist, dort anzufangen, wo der Code am unschönsten ist. Richtig ist: dort anzufangen, wo sich Änderungshäufigkeit und Komplexität überschneiden. Eine komplexe Datei, die seit drei Jahren niemand angefasst hat, kostet nichts. Eine mittelmäßige Datei, die in jedem Sprint geändert wird, kostet jeden Monat.
Die Datenquelle dafür ist Ihre Versionsgeschichte – welche Dateien wurden am häufigsten geändert, welche haben die meisten Fehlerbehebungen gesehen. Diese Auswertung kostet eine Stunde und priorisiert besser als jedes Qualitätswerkzeug.
Refactoring an Features koppeln
Ein isolierter Refactoring-Sprint ist schwer zu verkaufen und riskant, weil er große Änderungen ohne funktionalen Nutzen bündelt. Besser: Jedes Feature, das einen schwierigen Bereich berührt, bringt sein Aufräumen mit. Der Aufwand steht dann im Angebot, hat einen Grund und wird direkt von Tests des neuen Features abgedeckt.
Die Leitplanke zuerst
Refactoring ohne Tests ist Umbauen im Dunkeln. Wenn ein Bereich keine Testabdeckung hat, ist der erste Schritt nicht die Verbesserung, sondern eine Absicherung des bestehenden Verhaltens – auch wenn dieses Verhalten merkwürdig ist. Wie das methodisch geht, beschreiben die Artikel Unit Testing Guide und Testautomatisierung.
Schulden sichtbar machen
Technische Schulden, die nicht im Backlog stehen, existieren für die Planung nicht. Legen Sie sie als normale Einträge an – mit Beschreibung, betroffenem Bereich, geschätztem Aufwand und, das ist der entscheidende Teil, den Folgekosten des Nichtstuns. Ein Eintrag „Altes Zahlungsmodul ablösen, bremst jede Änderung am Checkout um geschätzt zwei Tage“ ist diskutierbar. „Refactoring nötig“ ist es nicht.
Messen: Werkzeuge und ihre Grenzen
| Werkzeug | Misst | Taugt für |
|---|---|---|
| SonarQube / SonarCloud | Regelverstöße, Duplikate, Komplexität, Abdeckung, geschätzte Behebungszeit | Trendbeobachtung, Qualitätsschwellen in der Pipeline |
| CodeScene | Änderungshäufigkeit verknüpft mit Komplexität, Wissensverteilung im Team | Priorisierung nach tatsächlichen Kosten |
| Abhängigkeits-Prüfung | veraltete Pakete, bekannte Sicherheitslücken | messbare Schuld mit klarer Dringlichkeit |
| Testabdeckung | Anteil durch Tests ausgeführter Zeilen | Risikoabschätzung vor Umbauten |
| Versionsgeschichte | Änderungs- und Fehlerhäufigkeit pro Datei | kostet nichts, priorisiert am besten |
Zwei Warnungen zu Werkzeugkennzahlen. Erstens: Die von Werkzeugen ausgegebene Behebungszeit ist eine Schätzung aus Regelverstößen, keine Messung. Sie ist als Trend nützlich und als Absolutwert irreführend. Zweitens: Was gemessen wird, wird optimiert. Eine Zielvorgabe auf Testabdeckung erzeugt Tests ohne Prüfungen; eine Zielvorgabe auf Regelverstöße erzeugt unterdrückte Warnungen. Nutzen Sie Kennzahlen als Gesprächsgrundlage, nicht als Ziel.
Der pragmatische Einstieg: Statische Analyse in die Pipeline einbauen und auf neuen Code anwenden, nicht auf den Bestand. Bestehende Befunde werden als Ausgangslage akzeptiert, neue blockieren den Merge. Damit hört das Wachstum sofort auf, ohne dass ein einziger Sprint für Aufräumen gebraucht wird – und die Zahl sinkt dann automatisch, weil Code, der angefasst wird, die neue Regel erfüllen muss. Wie sich das in die Pipeline einfügt, zeigt der CI/CD-Guide.
Das Gespräch mit dem Management
Der häufigste Grund, warum technische Schulden nicht abgebaut werden, ist nicht Budgetmangel. Es ist, dass das Thema in einer Sprache vorgetragen wird, die Entscheider nicht bewerten können. Vier Verschiebungen helfen:
Hilfreich ist außerdem eine ehrliche Aussage, die selten gemacht wird: Nicht jede Schuld muss getilgt werden. Code in einem Bereich, der nicht mehr weiterentwickelt wird, darf hässlich bleiben. Diese Zurückhaltung macht die Fälle glaubwürdig, in denen Sie tatsächlich Budget verlangen.
Fazit
Technische Schulden sind unvermeidbar und nicht grundsätzlich schlecht – problematisch ist nur, sie unsichtbar zu lassen. Erkennen Sie sie an sinkender Geschwindigkeit, wachsenden Schätzungen und der Scheu, bestimmte Stellen anzufassen. Messen Sie sie, wo es geht, aber priorisieren Sie nach Änderungshäufigkeit statt nach Werkzeugpunkten. Der Abbau gelingt nicht in Kraftakten, sondern mit einem verbindlichen Anteil der Kapazität, gekoppelt an Features und abgesichert durch Tests. Und für das Gespräch nach oben gilt: Übersetzen Sie Codequalität in Durchlaufzeit, Risiko und Euro – dann wird aus einer technischen Befindlichkeit eine Investitionsentscheidung.