Zum Hauptinhalt springen

Technical Debt (Technische Schulden)

Technical Debt beschreibt bewusst oder unbewusst eingegangene Kompromisse in Software, die später zusätzlichen Aufwand verursachen.

Wie bei finanziellen Schulden gilt:

Schulden können sinnvoll sein –
aber nur, wenn man sie kennt, bewertet und aktiv steuert.

1. Was ist Technical Debt?​

Technical Debt ist die Differenz zwischen:

  • dem schnellsten Weg zu einem Ergebnis
    und
  • dem langfristig nachhaltigen Weg

Kurzfristig spart man Zeit.
Langfristig entstehen Zinsen.

Wichtig:

Nicht jede schlechte Lösung ist Technical Debt.
Debt entsteht nur, wenn eine Entscheidung:

  • bewusst schneller gewählt wurde
    oder
  • implizit Risiken erzeugt, die später Kosten verursachen.

2. Der Vergleich mit echten Schulden​

Finanziell​

  • Kredit aufnehmen → schneller investieren
  • Zinsen → regelmäßige Mehrkosten
  • Zu viele Kredite → eingeschränkte Handlungsfähigkeit

Technisch​

  • Quick Fix → schneller liefern
  • Zinsen → steigende Änderungsaufwände
  • Zu viel Debt → Feature-Delivery verlangsamt sich
  • Extremfall → Stillstand („nur noch Reparaturbetrieb“)

Ein System kann lange funktionieren –
aber mit exponentiell steigenden Zinskosten.

3. Debt vs. Entropie​

Nicht jede Verschlechterung ist Debt.

Technical Debt​

  • Kompromiss zugunsten von Geschwindigkeit
  • bewusste oder bewertbare Entscheidung
  • potenziell rückzahlbar

Technische Entropie​

  • fehlende Pflege
  • inkonsistente Muster
  • ungeklärte Verantwortlichkeiten
  • kein Refactoring über Zeit

Entropie entsteht automatisch.
Debt ist eine strategische Entscheidung (oder ihr Versäumnis).

4. Wie entstehen technische Schulden?​

  • Zeitdruck: „Wir müssen raus.“
  • Unklare Anforderungen: spätere Korrekturen
  • Fehlende Tests: Regressionsrisiko steigt
  • Architektur-Umgehungen: Abkürzungen in Abhängigkeiten
  • Technologie-Drift: veraltete Frameworks ohne Upgrade-Strategie
  • Rollenlücken: niemand fühlt sich verantwortlich

Technische Schulden entstehen nicht nur im Code – sondern auch durch organisatorische Entscheidungen.

5. Typische Symptome​

  • Jede Änderung dauert länger als früher
  • Kleine Änderungen verursachen unerwartete Nebeneffekte
  • Bug-Fix-Rate steigt
  • Teams haben Angst vor Refactoring
  • Wissen wird zum Engpass
  • „Nur noch Workarounds“ statt saubere Lösungen

Ein starkes Indiz:

Die Änderungszeit steigt, obwohl Teamgröße gleich bleibt.

6. Die Zinsmechanik verstehen​

Technische Schulden erzeugen:

  • höhere kognitive Last
  • längere Review-Zeiten
  • mehr Testaufwand
  • mehr Incident-Risiko
  • steigende Integrationskosten

Zinsen wirken oft schleichend.

Man merkt sie nicht pro Ticket –
sondern über Monate.

7. Strategischer Umgang mit Technical Debt​

1️⃣ Sichtbar machen​

  • Schulden dokumentieren
  • Owner benennen
  • Auswirkungen beschreiben
  • nicht nur „TODO“ im Code

Unsichtbare Schulden sind die gefährlichsten.

2️⃣ Zinsen bewerten​

Fragen:

  • Wie viel Zeit verlieren wir pro Monat?
  • Wie oft blockiert es Features?
  • Wie hoch ist das Incident-Risiko?
  • Wie stark steigt Komplexität?

Technische Schulden sind ein wirtschaftliches Thema.

3️⃣ Gezielte Tilgung​

  • Kleine, kontinuierliche Refactorings
  • Debt-Budget pro Sprint
  • Upgrade-Fenster definieren
  • keine „Refactoring nur wenn Zeit ist“-Strategie

Debt muss geplant werden.

4️⃣ Neue Schulden bewusst aufnehmen​

Schulden können sinnvoll sein, wenn:

  • Marktzeit kritisch ist
  • Lernphase noch läuft
  • Risiko gering ist
  • Rückzahlungsplan existiert

Die entscheidende Frage:

Wann und wie zahlen wir zurück?

Ohne Rückzahlungsplan ist es kein Kredit –
es ist Verdrängung.

8. Technical Debt im Qualitätsmodell​

Stufe 0–1:

  • Debt ist akzeptabel, wenn Lebensdauer gering

Stufe 2:

  • Debt muss dokumentiert und begrenzt sein

Stufe 3:

  • Zinsen werden betriebswirtschaftlich relevant

Stufe 4–5:

  • Unkontrollierte Debt ist nicht akzeptabel

Je höher die Kritikalität, desto geringer die Toleranz für implizite Schulden.

9. Für Nicht-Techniker: Warum das wichtig ist​

Technische Schulden sind wie ein unsichtbarer Kredit.

Man merkt ihn nicht sofort. Aber jede neue Entscheidung wird teurer.

Wer nur kurzfristig optimiert,
bezahlt langfristig mit:

  • Verzögerungen
  • steigenden Kosten
  • sinkender Planbarkeit
  • erhöhtem Risiko

10. Typische Fehlannahmen​

  • „Technical Debt ist normal, also egal.“
  • „Wir machen das später.“
  • „Refactoring bringt keinen Business Value.“
  • „Neue Features lösen das Problem.“

Technische Schulden verschwinden nicht von selbst.

Fazit​

Technical Debt ist nicht per se schlecht.

Schlecht ist:

  • keine Übersicht
  • keine Bewertung
  • kein Rückzahlungsplan
  • keine Ownership

Schulden sind ein Instrument.

Unkontrollierte Schulden sind ein Risiko.

Und wie bei echten Schulden gilt:

Nicht der Kredit ist gefährlich –
sondern die Illusion, ihn nie zurückzahlen zu müssen.