Tech-Schulden erkennen und beheben

"Wir können keine neuen Features mehr bauen. Wir müssen erst aufräumen."

Wenn dieser Satz fällt, ist es meist schon zu spät. Technical Debt ist wie Kreditkarten-Schulden: Die Zinsen kommen schleichend, und irgendwann zahlt man nur noch Zinsen.

Was ist Technical Debt? (Und was nicht?)

Technical Debt ist:

• Bewusste Abkürzungen für Geschwindigkeit (z.B. MVP ohne Tests)
• Legacy-Code, der funktioniert, aber schwer wartbar ist
• Fehlende Dokumentation und Standards
• Infrastruktur, die nicht mehr skaliert

Technical Debt ist NICHT:

• Schlechter Code, weil das Team nichts kann (das ist einfach schlechter Code)
• Jede Technologie älter als 2 Jahre (Stabilität ist ein Feature)
• Alles, was Entwickler nicht mögen

Der Unterschied: Tech Debt ist eine bewusste Investitionsentscheidung mit bekannten Konsequenzen.

Ein Beispiel aus der Praxis: Bei einem E-Commerce-Startup wurden "schnelle Fixes" zur Normalität. Das Team war stolz auf seine Geschwindigkeit, aber niemand führte Buch. Nach 18 Monaten war die Codebasis so fragil, dass jede kleine Änderung unerwartete Bugs verursachte. Die Feature-Velocity brach um 60% ein. Die Lösung: Wir haben Tech Debt sichtbar gemacht, in den Sprint-Plannings explizit eingeplant und 20% der Kapazität fix reserviert. Nach 4 Monaten war die Velocity wieder auf Normalniveau.

Die 5 Warnsignale für kritische Tech Debt

1. Velocity bricht ein

• Features, die früher 1 Woche brauchten, dauern jetzt 4 Wochen
• "Einfache" Änderungen haben unerwartete Side-Effects
• Mehr Zeit für Bugfixes als für neue Features

Messbar: Story Points per Sprint sinken kontinuierlich über 3-6 Monate.

2. Onboarding dauert ewig

• Neue Entwickler brauchen 3+ Monate bis produktiv
• "Du musst erstmal diese 20 Dokumente lesen" (die veraltet sind)
• Niemand versteht das ganze System

Red Flag: Wenn die Antwort auf "Warum ist das so?" immer ist: "Weiß nicht, war schon immer so."

3. Deployment ist ein Event

• Releases nur nachts/am Wochenende
• "Deployment-Checkliste" mit 50+ manuellen Schritten
• Rollbacks dauern Stunden
• Angst vor Production-Releases

Gesunder Zustand: Deploy mehrmals täglich, vollautomatisch, ohne Drama.

4. Bugs stapeln sich schneller als Fixes

• Bug-Backlog wächst jeden Sprint
• "Das Feature ist fertig, außer diese 12 bekannten Bugs"
• Production-Hotfixes sind die Norm, nicht die Ausnahme

Kritisch: Wenn >30% der Entwicklerzeit für Bugfixes draufgeht.

5. "Das System ist zu komplex zum Ändern"

• Jede Änderung braucht System-weites Refactoring
• Tight Coupling überall
• Keine klaren Module oder Services
• "Wenn wir da was ändern, bricht alles"

Das Endstadium: Erwägung eines kompletten Rewrites.

Tech Debt Assessment: Der systematische Check

Quick Audit (2-4 Stunden)

1. Code-Qualität:

• Test-Coverage <60%?
• Keine automatisierten Tests?
• Code-Reviews nicht etabliert?

2. Infrastructure:

• Deployment dauert >30 Minuten?
• Keine CI/CD-Pipeline?
• Manuelle Infrastruktur-Provisionierung?

3. Dokumentation:

• Keine aktuelle Architektur-Dokumentation?
• Onboarding nur durch "Buddy-System"?
• APIs ohne Specs?

4. Monitoring:

• Keine Error-Tracking?
• Kein Monitoring von Business-Metriken?
• "Wir sehen Probleme, wenn Kunden sich beschweren"?

Scoring:

• 0-3 Gut
• 4-7 Handlungsbedarf mittelfristig
• 8+ 🚨 Kritisch, sofort handeln

Deep Dive (1-2 Wochen)

Für kritische Systeme:

• Code-Analyse-Tools (SonarQube, CodeClimate)
• Dependency-Audit (veraltete Libraries?)
• Performance-Profiling
• Security-Scan
• Architecture-Review mit Team

Der pragmatische Abbau-Plan

Phase 1: Stopp den Bleed (Woche 1-2)

Ziel: Keine neue Tech Debt

• Code-Review-Pflicht einführen
• Test-Coverage für neue Features (Minimum-Bar setzen)
• CI/CD für main-Branch
• Definition of Done erweitern

Phase 2: Quick Wins (Woche 3-8)

Ziel: Sichtbare Verbesserungen

• Top 5 Pain Points identifizieren (Team fragen!)
• Deployment-Zeit halbieren
• Critical-Path-Tests schreiben
• Monitoring für Top 3 Business-Metriken

Budget: 20% der Entwickler-Kapazität

Phase 3: Strategischer Refactor (Monat 3-6)

Ziel: Strukturelle Verbesserungen

• Module/Services entkoppeln
• Shared-Kernel extrahieren
• Legacy-Code isolieren (Strangler Pattern)
• Dokumentation aktualisieren

Budget: 30-40% der Kapazität (zeitlich befristet!)

Phase 4: Continuous Improvement (ongoing)

Ziel: Prävention

• 15% "Tech-Investment-Time" pro Sprint
• Quarterly "Tech Health Reviews"
• Proaktive Library-Updates
• Blameless Postmortems

Die Kosten ignorieren (ist teurer)

Szenario Scale-up, 15 Entwickler, kritische Tech Debt:

Option A: Weitermachen wie bisher

• Velocity sinkt um 50% über 12 Monate
• Effektiv: 7,5 Entwickler productive capacity
• Opportunitätskosten: 7,5 x 100k€ = 750k€/Jahr

Option B: 3 Monate Refactoring-Push

• 15 Entwickler x 3 Monate x 80k€/Jahr = 300k€
• Danach: Velocity normal, Innovation möglich
• Break-even nach 6 Monaten

Die Mathe ist klar.

Wann ist ein Rewrite die richtige Wahl?

Fast nie. Aber manchmal doch:

Rewrite erwägen, wenn:

• System <2 Jahre alt, aber fundamentale Architektur-Fehler
• Technologie ist wirklich tot (Python 2, Angular.js)
• Business-Model-Pivot macht aktuelles System obsolet
• Strategische Gründe (Compliance, M&A, etc.)

Kein Rewrite, wenn:

• "Der Code ist hässlich" (Refactor stattdessen)
• "Neue Technologie ist cooler" (nicht Ihr Problem)
• "Würde ich heute anders machen" (natürlich, Sie sind auch klüger geworden)

Regel: Rewrite ist ein neues Produkt, kein "Aufräumen". Kalkulieren Sie entsprechend.

Fazit: Tech Debt ist Business Debt

Tech Debt zu ignorieren ist wie eine Fabrik nicht zu warten. Irgendwann steht das Band still.

Das Management-Gespräch:

• Tech Debt ist nicht "IT will spielen". Es ist Investment in Lieferfähigkeit
• Messbar in Velocity, Time-to-Market, Entwickler-Retention
• Nicht beheben = langsamer werden = Wettbewerb verlieren

Drei Schritte ab morgen:

1. Quick Audit (2 Stunden, dieser Artikel)
2. Top 3 Pain Points im Team identifizieren (1 Meeting)
3. 20% Tech-Investment-Budget freimachen (nächster Sprint)

Tech Debt Zinsen sind immer höher als der Kredit.