Technical Debt quantifizieren: Wie Sie Altlasten in Euro umrechnen

„Wir haben Technical Debt" ist eine Aussage, die jedes Management-Meeting überlebt. „Wir haben Technical Debt im Wert von 2,3 Millionen Euro, der uns monatlich 180.000 Euro kostet" – das verändert Budgetgespräche. Dieser Artikel zeigt, wie Sie technische Schulden messbar machen.

Technical Debt verhält sich wie eine Bilanzposition: Er verursacht Behebungskosten, Zinsen und Ausfallrisiko.

Warum überhaupt quantifizieren?

Die meisten Entwickler wissen intuitiv, wo die Probleme liegen. Der Monolith, der bei jedem Deploy zittert. Das Modul, das niemand mehr anfassen will. Die Datenbank-Queries, die nachts das Monitoring rot färben.

Aber Intuition überzeugt keine Budgetverantwortlichen. Was überzeugt:

• Konkrete Zahlen: „Das Billing-Modul kostet uns 40 Entwicklerstunden pro Monat für Workarounds"
• Business-Impact: „Jeder Ausfall des Legacy-Systems kostet 15.000 Euro pro Stunde"
• Opportunitätskosten: „Wir können Feature X nicht bauen, weil 30% der Kapazität in Wartung fließt"
• Risiko-Bewertung: „Bei einem Security-Incident im Altsystem rechnen wir mit 500.000 Euro Schaden"

Arten von Technical Debt

Nicht alle Schulden sind gleich. Bevor Sie quantifizieren, kategorisieren Sie:

Typ	Beispiele	Messung
Code Debt	Duplizierter Code, fehlende Tests, hohe Komplexität	Statische Analyse (SonarQube, etc.)
Architektur Debt	Monolith, zirkuläre Dependencies, falsche Abstraktion	Architektur-Analyse, Coupling-Metriken
Infrastructure Debt	Veraltete Server, manuelle Deployments, fehlende Automation	Deployment-Frequenz, MTTR
Documentation Debt	Fehlende/veraltete Docs, Tribal Knowledge	Onboarding-Zeit, Support-Tickets
Test Debt	Niedrige Coverage, flaky Tests, fehlende Integration-Tests	Coverage, Defect Escape Rate
Dependency Debt	Veraltete Libraries, End-of-Life Frameworks	CVE-Scans, Version-Differenz

Die wichtigsten Metriken

1. Remediation Cost (Behebungskosten)

Die fundamentale Frage: Was kostet es, den Debt zu beheben?

# SonarQube liefert Technical Debt in Minuten
# Umrechnung in Euro:
MINUTEN_DEBT = 4800  # aus SonarQube
STUNDENSATZ = 100    # Euro (interner Satz oder externer)
DEBT_EURO = (MINUTEN_DEBT / 60) * STUNDENSATZ
# = 8.000 Euro

2. Interest Rate (Zinskosten)

Debt kostet nicht nur einmalig – er kostet laufend. Die „Zinsen" sind die zusätzliche Zeit, die Teams durch den Debt verlieren.

# Beispiel-Berechnung Interest Rate
FEATURES_OHNE_DEBT = 10  # Features pro Sprint (theoretisch)
FEATURES_MIT_DEBT = 7    # Features pro Sprint (real)
VELOCITY_VERLUST = (10 - 7) / 10  # = 30%

TEAM_KOSTEN_MONAT = 80000  # Euro
ZINSKOSTEN_MONAT = TEAM_KOSTEN_MONAT * 0.30
# = 24.000 Euro/Monat

Diese Berechnung ist grob, aber sie macht einen Punkt klar: Technical Debt hat laufende Kosten. Jeden Monat.

3. Defect Density

Wie viele Bugs pro Lines of Code entstehen in verschiedenen Modulen?

# Bugs pro 1000 LOC
SELECT
    module,
    COUNT(bugs) as bug_count,
    loc,
    (COUNT(bugs) * 1000.0 / loc) as defect_density
FROM codebase
JOIN bug_tracker ON module = affected_module
GROUP BY module
ORDER BY defect_density DESC;

-- Ergebnis:
-- billing_legacy    | 47 | 12000 | 3.92
-- user_service      | 12 | 8000  | 1.50
-- api_gateway       | 3  | 5000  | 0.60

Ein Modul mit Defect Density > 3 ist ein klarer Kandidat für Refactoring oder Rewrite. Als Trend-Metrik ist Defect Density nützlich – nicht als absolute Qualitätszahl. Vergleichen Sie Module nur innerhalb derselben Domäne/Codebase.

4. Change Failure Rate

Wie oft führen Änderungen an einem Modul zu Problemen?

# DORA-Metrik: Change Failure Rate
DEPLOYMENTS_MODUL_X = 20
ROLLBACKS_MODUL_X = 6
HOTFIXES_MODUL_X = 4

CFR = (ROLLBACKS_MODUL_X + HOTFIXES_MODUL_X) / DEPLOYMENTS_MODUL_X
# = 50% - kritisch!

Eine Change Failure Rate über 15% signalisiert ernsthafte Probleme. Über 30% ist ein Alarmsignal.

5. Mean Time to Change

Wie lange dauert eine typische Änderung in verschiedenen Bereichen?

Modul	Durchschn. Änderungszeit	Benchmark	Delta
API Gateway (neu)	4 Stunden	4 Stunden	0
User Service	8 Stunden	4 Stunden	+4h
Billing Legacy	24 Stunden	4 Stunden	+20h

Das Billing-Modul kostet bei jeder Änderung 20 Extra-Stunden. Bei 10 Änderungen pro Monat sind das 200 Stunden – oder 20.000 Euro.

Tools zur Messung

SonarQube / SonarCloud

Der Industriestandard für statische Code-Analyse.

# SonarQube Docker Setup
docker run -d --name sonarqube \
  -p 9000:9000 \
  -v sonarqube_data:/opt/sonarqube/data \
  sonarqube:community

# Scan ausführen (Maven-Projekt)
mvn sonar:sonar \
  -Dsonar.projectKey=my-project \
  -Dsonar.host.url=http://localhost:9000 \
  -Dsonar.login=your-token

SonarQube liefert:

• Technical Debt in Minuten: Geschätzte Behebungszeit
• Debt Ratio: Verhältnis Debt zu Entwicklungsaufwand
• Maintainability Rating: A bis E
• Code Smells, Bugs, Vulnerabilities: Kategorisiert nach Schwere

CodeScene

CodeScene geht über statische Analyse hinaus und analysiert die Git-Historie.

• Hotspots: Code, der oft geändert wird UND komplex ist
• Temporal Coupling: Dateien, die immer zusammen geändert werden (versteckte Dependencies)
• Knowledge Distribution: Wer kennt welchen Code? Wo ist Tribal Knowledge?
• Refactoring Targets: Priorisierte Liste basierend auf Änderungshäufigkeit × Komplexität

Dependency-Track / Snyk

Für Dependency Debt – veraltete und vulnerable Libraries.

# Snyk CLI
snyk test --all-projects

# Output:
# ✗ High severity vulnerability in lodash
#   Prototype Pollution [High Severity]
#   Introduced through: lodash@4.17.15
#   Fixed in: lodash@4.17.21

# Dependency-Track API: Alle veralteten Dependencies
curl -X GET "https://dtrack.example.com/api/v1/component/outdated" \
  -H "X-Api-Key: $API_KEY"

Custom Metrics Dashboard

Für die Management-Ebene brauchen Sie ein aggregiertes Dashboard:

// Beispiel: Technical Debt Dashboard (Grafana/Metabase)
const debtMetrics = {
  // Aus SonarQube
  codeDebt: {
    minutes: 48000,
    euro: 80000,
    trend: '+5%'  // vs. letzter Monat
  },

  // Aus Git-Analyse
  hotspots: [
    { file: 'billing/Invoice.java', changes: 47, complexity: 89 },
    { file: 'auth/LegacyAuth.java', changes: 32, complexity: 72 }
  ],

  // Aus Bug-Tracker
  defectDensity: {
    billing: 3.92,
    userService: 1.50,
    apiGateway: 0.60
  },

  // DORA-Metriken
  changeFailureRate: {
    overall: 0.18,
    billing: 0.45,
    userService: 0.12
  },

  // Berechnet
  monthlyInterest: 24000,  // Euro
  paybackPeriod: 80000 / 24000  // = 3.3 Monate
};

Den Business Case bauen

Cost of Delay

Was kostet es, den Debt NICHT zu beheben?

Priorisierung nach ROI

Nicht aller Debt ist gleich wichtig. Priorisieren Sie nach Return on Investment:

ROI = (Jährliche Einsparung - Behebungskosten) / Behebungskosten

Debt-Item	Behebung	Einsparung/Jahr	ROI
Billing Refactor	320k €	486k €	52%
Auth Modernization	150k €	180k €	20%
Test Automation	80k €	120k €	50%
Docs Update	20k €	15k €	-25%

Priorisierung: Test Automation → Billing → Auth → (Docs streichen)

Stakeholder-Kommunikation

Verschiedene Stakeholder brauchen verschiedene Zahlen:

Stakeholder	Interessiert an	Sprache
CFO	Kosten, ROI, Cashflow	„320k Investment, 486k Einsparung, 11 Monate Break-Even"
CTO	Risiko, Velocity, Architektur	„30% Velocity-Verlust, CFR 45%, Security-Exposure"
Product Owner	Feature-Delivery, Time-to-Market	„4 Features/Jahr Opportunity Cost, 3x längere Änderungszeiten"
Team Lead	Team-Moral, Onboarding, Qualität	„6 Wochen statt 2 Wochen Onboarding, Frustration"

Debt Tracking über Zeit

Das Debt Register

Führen Sie ein zentrales Register aller bekannten Technical Debts:

// debt-register.json
{
  "debts": [
    {
      "id": "DEBT-001",
      "title": "Billing Legacy Monolith",
      "category": "architecture",
      "severity": "critical",
      "discovered": "2024-03-15",
      "owner": "team-billing",
      "estimatedCost": 320000,
      "monthlyInterest": 28000,
      "status": "in_progress",
      "linkedJiraEpic": "BILL-1234",
      "dependencies": ["DEBT-003"],
      "lastReview": "2025-06-01",
      "notes": "Migration zu Microservices läuft, 40% complete"
    },
    {
      "id": "DEBT-002",
      "title": "Fehlende Integration Tests Auth",
      "category": "test",
      "severity": "high",
      "discovered": "2024-06-20",
      "owner": "team-platform",
      "estimatedCost": 40000,
      "monthlyInterest": 5000,
      "status": "planned",
      "linkedJiraEpic": "PLAT-567",
      "targetQuarter": "Q3-2025"
    }
  ],
  "totalDebt": 580000,
  "monthlyInterest": 52000,
  "lastUpdated": "2025-07-01"
}

KPIs für Technical Debt

Regelmäßige Reviews

Debt-Management ist kein einmaliges Projekt:

• Wöchentlich: Team prüft neue Issues auf Debt-Potenzial
• Sprint: Debt-Budget (z.B. 20% der Kapazität für Debt-Reduktion)
• Monatlich: Debt-Register Review mit Stakeholdern
• Quartalsweise: ROI-Analyse, Priorisierung, Budget-Planung

Typische Fallstricke

1. Nur Code-Metriken messen

SonarQube sagt, das Modul hat 2.000 Minuten Debt. Aber wenn das Modul nie angefasst wird, ist der praktische Impact null. Kombinieren Sie statische Analyse mit Änderungshäufigkeit.

2. Alle Schulden gleich behandeln

Ein Code-Smell in einem internen Admin-Tool ist nicht so kritisch wie eine SQL-Injection-Gefahr im Checkout. Priorisieren Sie nach Business-Impact, nicht nach Tool-Output.

3. Perfektionismus

Ziel ist nicht „Zero Debt". Ziel ist ein akzeptables, kontrolliertes Niveau. Manche Schulden sind bewusste Trade-offs – dokumentieren Sie sie als „Accepted Debt".

4. Keine klare Ownership

Debt ohne Owner wird nicht behoben. Jeder Debt-Eintrag braucht einen Verantwortlichen – ein Team, keine Person.

5. Debt verstecken

Teams, die für Debt „bestraft" werden, melden keinen Debt. Schaffen Sie eine Kultur, in der Debt-Identifikation belohnt wird. Das Finden ist der erste Schritt zur Lösung.

Praxisbeispiel: Debt-Analyse eines E-Commerce-Systems

Ein mittelständischer Online-Händler mit 50 Entwicklern, gewachsenem PHP-Monolith, Umsatz 80 Mio €/Jahr.

Schritt 1: Daten sammeln

# SonarQube-Analyse
Total Technical Debt: 4.200 Stunden = 420.000 € (bei 100 €/h)

# Git-Analyse (letztes Jahr)
Hotspots (Änderungen × Komplexität):
1. checkout/PaymentProcessor.php  - Score: 892
2. catalog/ProductService.php     - Score: 654
3. order/LegacyOrderManager.php   - Score: 612

# Bug-Tracker
Defect Density:
- checkout/*: 4.2 bugs/kLOC
- catalog/*: 1.8 bugs/kLOC
- api/*: 0.9 bugs/kLOC

# Team-Befragung
"Wie viel % eurer Zeit geht für Workarounds drauf?"
- Checkout-Team: 40%
- Catalog-Team: 25%
- API-Team: 10%

Schritt 2: Kosten berechnen

Schritt 3: Priorisierung

System	Behebung	Jährl. Kosten	ROI	Priorität
Checkout/Payment	180k €	767k €	326%	1
Order Management	120k €	156k €	30%	2
Catalog Service	90k €	84k €	-7%	3 (defer)

Schritt 4: Roadmap

• Q3 2025: Checkout/Payment Modernisierung starten
• Q4 2025: Checkout abschließen, Order Management Assessment
• Q1 2026: Order Management Modernisierung
• Q2 2026: Catalog re-evaluieren (evtl. durch andere Maßnahmen verbessert)

Fazit

Technical Debt zu quantifizieren ist keine exakte Wissenschaft – aber es ist die Grundlage für rationale Entscheidungen. Ohne Zahlen diskutieren Teams und Management aneinander vorbei. Mit Zahlen können Sie:

• Priorisieren: Welcher Debt kostet am meisten?
• Budgetieren: Wie viel sollten wir für Debt-Reduktion ausgeben?
• Tracken: Wird es besser oder schlechter?
• Kommunizieren: Warum brauchen wir Zeit für „nichts Neues"?

Starten Sie einfach: Ein Debt-Register, ein monatlicher Review, ein Dashboard mit 3-5 Metriken. Verfeinern Sie über Zeit.

Technical Debt verschwindet nicht durch Ignorieren – aber durch Messen wird er handhabbar.

---