Technische Schulden sind Design- oder Implementierungsentscheidungen, die zukünftige Änderungen verteuern oder erschweren. Der Begriff geht auf Ward Cunningham (1992) zurück: Er verglich unvollständigen oder suboptimalen Code mit einem Kredit – er ermöglicht zunächst schnelle Lieferung, verlangt jedoch „Zinsen“ in Form erhöhter Wartungs- und Anpassungskosten, wenn er nicht zeitnah getilgt wird.
Praxisbezug
Arten von technischer Schuld:
- Code-Schulden (unsauberer, redundanter oder komplexer Code).
- Architektur-Schulden (ungeeignete oder überholte Strukturen, enge Kopplung).
- Test-Schulden (fehlende oder instabile Tests).
- Build-/Deploy-Schulden (manuelle oder fragile Pipelines).
- Dokumentationsschulden (fehlende oder veraltete Doku).
Ökonomisches Modell:
- Principal (Hauptschuld): Aufwand, die bessere Lösung jetzt zu implementieren.
- Interest (Zinsen): wiederkehrende Zusatzkosten, z. B. längere Entwicklungszeit, mehr Defekte.
- Interest Rate (Zinssatz): steigt in Codebereichen, die häufig geändert werden („Hotspots“).
Intent & Qualität der Entscheidung (Fowler-Quadrant):
- Absichtlich vs. unbeabsichtigt × umsichtig vs. leichtsinnig → vier Typen.
- „Absichtlich-umsichtig“ kann nützlich sein (bewusste Markteinführung trotz Kompromiss).
- „Unabsichtlich-leichtsinnig“ führt fast immer zu Problemzinsen.
Typische Missverständnisse
❌ „Technische Schulden = Bugs“ – Fehler sind Defekte; Schulden betreffen die Wartbarkeit und Evolvierbarkeit des Systems.
❌ „Tools liefern die ganze Wahrheit“ – SonarQube/SQALE schätzen v. a. Maintainability-Schulden (Code Smells), lassen Architektur-, Test- oder Build-Schulden jedoch oft unsichtbar.
❌ „Alles neu schreiben löst es“ – Big-Bang-Rewrites verlagern Schulden häufig nur; risikoärmer sind inkrementelle Ansätze (z. B. Strangler-Pattern).
Relevanz für Organisationen
Business-Effekt:
- Eine groß angelegte Studie über 39 kommerzielle Codebasen zeigte: „Low-Quality“-Code enthielt bis zu 15× mehr Defekte und Bearbeitung von Issues dauerte im Schnitt 124 % länger.
- Die Autoren betonen: Korrelation, keine Kausalität – Ergebnisse gelten für diese Stichprobe, nicht universell.
- Andere Fallstudien berichten gemischte oder sogar keine Effekte auf Durchlaufzeiten, je nach Kontext und Messmethode.
Fazit: Technische Qualität ist Business-relevant, aber die Wirkung ist kontextabhängig – Organisationen müssen eigene Messungen durchführen.
Beispiel aus der Praxis
Ein Finanzdienstleister identifizierte einen Hotspot-Service (häufig geändert, hoher Komplexitätswert). Folge: lange Durchlaufzeiten, Fehler in Releases. Durch Hotspot-Analyse und Untersuchung zeitlicher Kopplung wurden Abhängigkeiten sichtbar. Das Team extrahierte eine kleinere Komponente, ergänzte Tests und CI-Checks. Ergebnis: verkürzte Cycle Times und geringere Fehlerquote im betroffenen Wertstrom.
Strategien: Vermeiden, Managen, Abbauen
A. Sichtbar machen & bewerten
- Debt-Register (Items mit Principal/Interest), Heatmaps für Hotspots, Architektur-Reviews.
- Tools (SonarQube, SQALE) nutzen – aber nur als Teilindikator.
B. Priorisieren nach Ökonomie
- Schulden nach Cost of Delay (CoD)/WSJF und Hotspot-Score priorisieren.
- Bewusste Schulden mit Tilgungsplan versehen.
C. Tilgen im Fluss
- Kontinuierliches Refactoring im laufenden Betrieb.
- Architektur-Enabler explizit planen.
- Strangler-Pattern für Legacy-Systeme einsetzen.
D. Qualitätsroutinen & Definition of Done
- TDD, automatisierte Tests, CI/CD, Code-Reviews.
- Definition of Done explizit mit Refactoring/Tests erweitern.
E. Wirkung messen
- Kombination aus Maintainability-Metriken (z. B. Sonar) und Flow-Metriken (Lead-/Cycle Time, Defektdichte, Change Failure Rate).
Wichtig: Ratings sind Indikatoren, kein absolutes Urteil.
So arbeiten gute Coaches
- Baseline erstellen: Debt-Register + Hotspot-Map.
- Ökonomisch priorisieren: WSJF × Hotspot-Score → Top-Items.
- Tilgung in Cadence: fixe Refactoring-Slots oder Enabler in jedem PI/Sprint.
- Architektur-Schulden gesondert managen: Schnitt, Abhängigkeiten, Observability.
- Wirkung messen: Fokus auf Outcomes (z. B. kürzere Cycle Time, weniger Defekte), nicht nur „Stunden investiert“.
CALADE-Perspektive
Wir sehen technische Schulden als strategisches Risiko im Portfolio. Unser Vorgehen:
- Sichtbarkeit herstellen (Debt-Register, Hotspot-Analyse).
- Ökonomisch priorisieren (CoD, WSJF).
- Verbindliche Kapazität sichern (Refactoring-/Enabler-Slots).
- Inkrementell tilgen und messen.
Wo organisatorische Policies Schulden verstärken (z. B. starre Freigaben, fehlende Plattform-Capabilities), kombinieren wir die Arbeit mit Organisational Debt, Living Strategy (Priorisierung, Strategy Sprints) und Living Transformation® (3-Monats-Kadenz, Capa-/Prio-Events). So entsteht ein ganzheitlicher Schuldenabbau, der Technik und Organisation verbindet.
Weiterführende Begriffe & Quellen
- Ward Cunningham: Debt Metaphor (1992).
- Martin Fowler: TD-Quadrant.
- SEI/CMU – Managing Technical Debt (Kruchten, Nord, Ozkaya).
- Systematische Reviews (Li, Avgeriou u. a., 2015).
- Hotspots & Temporal Coupling (Tornhill/CodeScene).
- SonarQube/SQALE – Maintainability Debt Ratio.
Empirische Business-Impact-Studien – Korrelation zw. Qualität, Defekten & Cycle Time; Kontext beachten.
← zurück zur Übersicht