Technical Debt (Technische Schulden)

Du musst ein Feature bis Freitag fertig haben. Du machst es "quick and dirty" (Copy-Paste, keine Tests). Das ist okay. Du hast dir Zeit geliehen. Wie bei einem Kredit bei der Bank. Ab Montag musst du Zinsen zahlen: Jede neue Änderung an diesem Code dauert länger, weil er schmutzig ist. Wenn du den Kredit nicht zurückzahlst (Refactoring), werden die Zinsen so hoch, dass du bankrott gehst (Entwicklung steht still, nur noch Bugfixing).

Merksatz: Eine Metapher für die impliziten Kosten zusätzlicher Nacharbeit, die entstehen, wenn man sich für eine einfache, schnelle Lösung entscheidet statt für einen besseren, aber zeitaufwendigeren Ansatz.

Bewusst vs. Unbewusst:

Bewusst: "Wir hacken das jetzt rein fürs Event am Wochenende, Montag fixen wir es." (Okay, taktisch).
Unbewusst: "Ich weiß nicht, wie man sauber codet, also produziere ich Müll." (Gefährlich).

Schulden abbauen: Plane in jedem Sprint 10-20% Zeit für "Tech Debt Reduction" ein. Sonst erstickt das Projekt.

1. The Quadrant

Martin Fowler unterscheidet 4 Arten:

Reckless/Deliberate: "Wir haben keine Zeit für Design" (Dummheit).
Prudent/Deliberate: "Wir müssen jetzt launchen, wir fixen es später." (Business-Entscheidung).
Reckless/Inadvertent: "Was ist Layering?" (Unwissenheit).
Prudent/Inadvertent: "Jetzt wo wir fertig sind, wissen wir, wie wir es hätten machen sollen." (Lerneffekt - unvermeidbar).

2. Bankruptcy (Legacy Rewrite)

Wenn die Schulden zu hoch sind, rufen Manager oft: "Wir schreiben alles neu! (Version 2.0)". Der größte Fehler der Softwaregeschichte (Netscape Navigator). Während du 2 Jahre lang V2 baust (ohne Features zu releasen), überholt dich die Konkurrenz. V2 wird nie fertig oder hat neue Bugs. Lösung: Refactoring des bestehenden Systems (Strangler Pattern).

3. Visibility

Manager sehen keine Code-Schulden. Sie sehen nur "Features dauern länger". Aufgabe des Entwicklers: Mach Schulden sichtbar! "Feature X dauert 3 Tage. Wenn wir vorher aufräumen, dauert es 1 Tag + 1 Tag aufräumen. Und das nächste Feature geht schneller."

1. Zinsen vs. Tilgung (Die Mathematik dahinter)

Es ist wichtig zu verstehen, dass nicht jede Zeile Code "Schulden" ist.

Tilgung: Ist die aktive Arbeit am Refactoring, um den Code sauber zu machen.
Zinszahlung: Ist die verlorene Zeit, die man bei jeder neuen Aufgabe investiert, weil man um die hässlichen Stellen herumprogrammieren muss oder weil Tests fehlen. Wenn die Zinszahlung pro Monat (z. B. 20 Stunden Extra-Aufwand durch schlechten Code) höher ist als die Zeit, die man für die Tilgung bräuchte (z. B. 10 Stunden Refactoring), ist man mathematisch gesehen in der Schuldenfalle. In diesem Moment ist es ökonomisch grob fahrlässig, mit dem Feature-Bau fortzufahren.

2. Schulden-Audits und Heatmaps

Wie findet man die gefährlichsten Schulden? Man schaut nicht nur auf die Code-Qualität (SonarQube), sondern auf die Churn Rate (Änderungshäufigkeit). Tools wie CodeScene erstellen Heatmaps: Code, der "hässlich" ist, aber seit 2 Jahren nicht angefasst wurde, ist keine dringende Schuld (niedrige Zinsen). Code, der hässlich ist UND in dem jeden Tag Bugs gefixt werden, ist eine "Hotzone". Hier muss sofort refactort werden. Eine gute Debt-Strategie priorisiert Reparaturen dort, wo die meisten Entwickler täglich arbeiten müssen.

3. Die Pfadfinder-Regel als Kultur (Debt Neutrality)

Die erfolgreichsten Teams bekämpfen Schulden nicht in großen "Cleanup-Wochen" (die oft gestrichen werden), sondern durch die Boy Scout Rule: "Check den Code ein Stück sauberer ein, als du ihn ausgecheckt hast." Wenn jeder Entwickler pro Ticket nur 10 Minuten investiert, um eine Variable besser zu benennen oder eine kleine Methode zu extrahieren, bleiben die Schulden konstant oder sinken sogar. Das Ziel ist eine Debt Neutrality, bei der man während der normalen Arbeit so viel Tilgung betreibt, wie man durch "Quick & Dirty" Entscheidungen an anderer Stelle aufnimmt.