Technische Schulden systematisch abbauen

Was technische Schulden wirklich sind

Ward Cunningham prägte den Begriff 1992 als Metapher: Wie finanzielle Schulden erlauben technische Schulden, schneller voranzukommen — aber die „Zinsen” (Wartungsaufwand, Bugs, langsame Entwicklung) wachsen, bis sie die Produktivität auffressen.

Was oft übersehen wird: Nicht alle technischen Schulden sind schlecht. Bewusste, kurzfristige Schulden (ein schneller Prototyp, der nach Validierung sauber umgesetzt wird) sind ein legitimes Werkzeug. Problematisch werden unbewusste Schulden — Code, der aus Zeitdruck, fehlendem Wissen oder mangelhaftem Review entsteht und sich still ansammelt.

Die vier Typen technischer Schulden

1. Code-Schulden

Duplizierter Code, unklare Benennung, zu lange Methoden, fehlende Tests. Die häufigste und sichtbarste Form.

2. Architektur-Schulden

Monolithische Strukturen, die eigentlich aufgeteilt werden sollten. Falsche Abstraktionen, die jede Änderung teuer machen. Fehlende Patterns (kein Caching, kein Event-System), die Performance und Erweiterbarkeit limitieren.

3. Infrastruktur-Schulden

Veraltete Abhängigkeiten, nicht aktualisierte Frameworks, manuelle Deployments, fehlende CI/CD-Pipelines, keine Infrastructure as Code.

4. Wissens-Schulden

Fehlende Dokumentation, Bus-Faktor 1 (nur eine Person versteht das System), keine Onboarding-Materialien, undokumentierte Entscheidungen.

Technische Schulden messen

Was man nicht misst, kann man nicht managen:

Velocity-Trend

Wenn die Feature-Velocity über Quartale sinkt, obwohl das Team stabil ist, sind technische Schulden ein wahrscheinlicher Grund.

Bug-Cluster

Bereiche mit überdurchschnittlich vielen Bugs deuten auf unterliegende Schulden hin. Git-Log-Analyse: Welche Dateien werden am häufigsten geändert UND haben die meisten Bug-Fixes?

Deployment-Frequenz

Sinkende Deployment-Frequenz bei stabiler Teamgröße = wachsende Schulden. Features brauchen länger, weil der existierende Code jede Änderung erschwert.

Developer Experience Survey

Fragen Sie Ihr Team: „Welche Teile des Systems meiden Sie am liebsten?” Die Antworten sind Ihr Schulden-Inventar.

Das 20%-Framework

Ein pragmatischer Ansatz, der Feature-Entwicklung und Schuldenabbau balanciert:

Regel: 20 % der Engineering-Kapazität für Schuldenabbau

• Nicht verhandelbar — es ist kein Puffer, der bei Zeitdruck gestrichen wird
• Nicht akkumulierbar — „wir sparen 20 % über drei Sprints und machen dann einen Refactoring-Sprint” funktioniert nicht
• Sichtbar — im Sprint Board als eigene Kategorie, nicht versteckt in Feature-Tickets

Priorisierung: Impact × Frequency

Nicht alle Schulden sind gleich dringend. Priorisieren Sie nach:

Häufig geänderter Code mit hohem Impact = höchste Priorität. Hier bremsen Schulden am meisten.

Selten geänderter Code mit niedrigem Impact = ignorieren. Der ROI des Refactorings ist negativ.

Praktische Taktiken

Boy Scout Rule

„Hinterlasse den Code besser, als du ihn vorgefunden hast.” Jeder Feature-PR verbessert den berührten Code ein wenig — Benennung, Testabdeckung, Vereinfachung.

Strangler Pattern für Legacy-Code

Neuen Code sauber schreiben, alten Code schrittweise ersetzen. Siehe unser Artikel zum Strangler-Fig-Pattern.

Dependency Updates als Routine

Wöchentliches Dependency-Update (automatisiert mit Dependabot/Renovate) verhindert, dass Updates sich zu einem riskanten Mammut-Upgrade aufstauen.

Test-Coverage gezielt erhöhen

Nicht blindes Streben nach 100 % Coverage. Stattdessen: Tests für die Bereiche schreiben, die am häufigsten Bugs produzieren oder geändert werden.

Architecture Decision Records (ADRs)

Entscheidungen dokumentieren — warum wurde etwas so gebaut? Das verhindert, dass zukünftige Entwickler aus Unwissenheit die falsche Entscheidung rückgängig machen.

Technische Schulden kommunizieren

Engineering-Teams kämpfen oft darum, Schuldenabbau gegenüber dem Management zu rechtfertigen. Drei Argumente, die funktionieren:

1. Velocity-Verlust quantifizieren: „Feature X hätte 2 Sprints gedauert, aber wegen Schulden in Modul Y brauchten wir 4.”
2. Incident-Kosten berechnen: „Die letzten drei Produktionsausfälle betrafen alle das gleiche Subsystem. Geschätzter Umsatzverlust: X €.”
3. Opportunity Cost zeigen: „Wir können Feature Z nicht bauen, solange die Architektur-Schulden in Bereich A bestehen.”

Fazit

Technische Schulden sind unvermeidlich. Unkontrollierte Schulden sind es nicht. Mit dem 20%-Framework, klarer Priorisierung und transparenter Kommunikation können Engineering-Teams Schulden systematisch abbauen, ohne die Feature-Entwicklung zu opfern. Der Schlüssel: Schuldenabbau ist keine Sonderaktion, sondern ein fester Bestandteil jedes Sprints.