Tech Debt
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 führen dazu, dass jedes neue Feature doppelt so lange dauert, bis die Entwicklung schliesslich komplett zum Erliegen kommt.
- Refactoring-Verbot: Das Management erlaubt keine Zeit für Aufräumarbeiten, da nur "sichtbare Features" zählen.
Die Schulden-Bewirtschaftung
- Sichtbarkeit (Tech Debt Registry): Erfassung technischer Schulden in einem Backlog oder direkt im Code (z. B. via TODO-Tags).
- Kategorisierung: Unterscheidung zwischen "bewusster Schuld" (Speed to Market) und "unbewusster Schuld" (mangelnde Qualität).
- 20% Regel: Feste Allokation von ca. 20% der Entwicklungszeit für Refactoring, Updates und Tilgung technischer Schulden.
- Dependency Bankruptcy: Mut zum kompletten Neubau von Komponenten, wenn die Tilgung der Schulden teurer wäre als die Neuentwicklung.
- 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 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. Wir investieren in die Betriebssicherheit eures Unternehmens.
Wie priorisieren wir Refactoring gegen neue Features?
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.
Reference Guide
- Technical Debt (Martin Fowler): Die klassische Definition und das Quadranten-Modell. martinfowler.com
- Refactoring: Martin Fowler über die Techniken zur Schulden-Tilgung. refactoring.com
- The Leprechauns of Software Engineering: Laurent Bossavit über Mythen und Fakten der Softwareentwicklung. Leanpub