Wie manage ich technische Schulden strategisch?

Was Tech-Debt ist

Ward Cunningham 1992: Tech-Debt entsteht durch Trade-Offs zwischen Tempo + Qualität. Wie Finanz-Schulden - kurzfristig nützlich, langfristig teuer wenn nicht zurückgezahlt.

Tech-Debt-Arten

• Bewusst-strategisch: 'wir liefern jetzt, refactoren später'.

• Bewusst-reaktiv: 'wir haben gerade keine Zeit'.

• Unbewusst: aus Unkenntnis entstanden.

• Veraltet: war richtig, wurde dann veraltet (Library-Upgrade).

Schritt 1: Inventar

1. Code-Smells (Sonarqube, CodeClimate).

2. Veraltete Bibliotheken (Snyk, Dependabot).

3. Architektur-Probleme (Tech-Lead-Walkthrough).

4. Test-Coverage-Lücken.

5. Performance-Hot-Spots.

6. Dokumentations-Lücken.

Schritt 2: Bewertung

• Pro Item: Auswirkung (1-5).

• Aufwand zur Behebung (1-5).

• Matrix mit 4 Quadranten.

• Hoch-Hoch: strategisch.

• Hoch-Niedrig: Quick-Wins.

• Niedrig-Hoch: nicht jetzt.

• Niedrig-Niedrig: akzeptieren.

Schritt 3: Allokation

1. 20 % Sprint-Kapazität als Standard.

2. Tech-Debt-Tasks im Backlog.

3. Boy-Scout-Rule: jedes Mal etwas besser hinterlassen.

4. Quartalsweise Refactor-Sprint möglich.

5. Strategischer Re-Write nur in Ausnahmen.

Schritt 4: Tracking

• Tech-Debt-Inventar im Backlog.

• Monatlicher Trend.

• Pro Bereich Owner.

• Berichte an Engineering-Mgmt.

• Visualisierung (Heatmap).

Strategie-Optionen

• Pay-as-you-go: 20 % laufend.

• Refactor-Sprint: alle 6-8 Sprints einer komplett.

• Strangler-Fig: alte Komponente schrittweise ersetzen.

• Big-Bang-Re-Write: nur in Ausnahmen.

Investoren + Stakeholder

1. Tech-Debt erklärbar machen.

2. Folgen sichtbar (Velocity, Defekt-Rate, Hire-Frist).

3. Investitions-Argumente.

4. Verbindung zu Business-Outcomes.

5. Quartalsweise reporten.

Prävention

• Code-Review-Disziplin.

• Tests als Default.

• Pair-Programming.

• Architektur-Reviews.

• Tech-Talks + Schulungen.

• Up-to-Date-Bibliotheken.

Werkzeuge

• SonarQube + Code-Climate für Code-Smells.

• Snyk + Dependabot für Sicherheit + Updates.

• Lighthouse für Performance.

• Linear / Jira für Backlog.

• ArchUnit / Structurizr für Architektur.

Anti-Patterns

• Tech-Debt nie addressieren - Velocity fällt exponentiell.

• Re-Write als Default - Business stoppt.

• Tech-Debt-Sprint einmal, dann nie wieder.

• Kein Inventar - niemand kennt Umfang.

• Tech-Debt als Engineer-Problem - kein Business-Bezug.