Publiziert:

Technische Schulden

Sichtbare Schulden lassen sich steuern, unsichtbare bestimmen das Tempo

Technische Schulden (Technical Debt) sind bewusste oder unbewusste Architektur-Entscheidungen, die kurzfristig Zeit sparen, aber langfristig die Wartungskosten erhöhen und die Entwicklungsgeschwindigkeit bremsen. Wie bei finanziellen Schulden müssen auch technische Schulden "verzinst" und irgendwann "getilgt" werden.

Ziel ist nicht die komplette Schuldenfreiheit (was unrealistisch wäre), sondern eine kontrollierte Bewirtschaftung, die die Innovationsfähigkeit der IT-Organisation sichert.

Anti-Patterns: Die Schuldenfalle

  • Unbewusste Verschuldung: Teams wissen gar nicht, dass sie Schulden anhäufen, da keine Architektur-Reviews stattfinden.
  • Zinseszinseffekt: Schulden in Kernkomponenten können die Durchlaufzeit für neue Features messbar erhöhen und das Defekt-Risiko verschärfen, besonders in häufig geänderten Bereichen.
  • Refactoring-Verbot: Das Management erlaubt keine Zeit für Aufräumarbeiten, da nur "sichtbare Features" zählen.

Die Schulden-Bewirtschaftung

  1. Sichtbarkeit (Tech Debt Registry): Erfassung technischer Schulden in einem Backlog oder direkt im Code (zum Beispiel via TODO-Tags).
  2. Kategorisierung: Unterscheidung zwischen "bewusster Schuld" (Markteinführung) und "unbewusster Schuld" (mangelnde Qualität).
  3. Debt-Tilgungs-Budget: Explizite Allokation eines Teils der Entwicklungszeit für Refactoring und Updates. Ein Richtwert von ca. 20% wird häufig als Startpunkt diskutiert; die richtige Quote hängt vom Schuldenstand, der Änderungsfrequenz und den Prioritäten ab.
  4. Dependency Bankruptcy: Mut zum kompletten Neubau von Komponenten, wenn die Tilgung der Schulden teurer wäre als die Neuentwicklung.
  5. Quality Gates: Automatisierte Checks in der CI/CD-Pipeline, die das Entstehen neuer, offensichtlicher Schulden verhindern.

Der Fokus: Investition in Geschwindigkeit

Die Tilgung von technischen Schulden ist keine Freizeitbeschäftigung für Entwickler, sondern eine notwendige Investition, um die Markteinführungszeit (Time-to-Market) für zukünftige Features zu sichern.

FAQ

Warum sollten wir für Dinge bezahlen, die der Kunde nicht sieht?

Weil technische Schulden wie Rost an einer Maschine sind. Man sieht ihn von aussen nicht sofort, aber irgendwann bricht die Maschine zusammen oder wird extrem langsam. Die Tilgung schützt Betriebssicherheit, Lieferfähigkeit und Änderbarkeit.

Wie lässt sich Refactoring gegen neue Features priorisieren?

Messt die Geschwindigkeit (Velocity) der Teams. Sinkt diese über Monate hinweg bei gleicher Teamgrösse, ist das ein klares Signal, dass die Zinslast der technischen Schulden zu hoch geworden ist.

Referenzen

  • Martin Fowler Refactoring: Improving the Design of Existing Code. Techniken zur strukturierten Schulden-Tilgung. (2018). refactoring.com
  • Laurent Bossavit The Leprechauns of Software Engineering. Über Mythen und unbelegte Zahlen in der Softwareentwicklung. (2012). leanpub.com/leprechauns
  • Martin Fowler Technical Debt Quadrant. Die klassische Definition und das Quadranten-Modell technischer Schulden. (2009). martinfowler.com/bliki/TechnicalDebtQuadrant.html