Technische Schulden – Technical Debt – bezeichnen die Summe aller Kompromisse, Abkürzungen und bewussten oder unbewussten Qualitätseinbußen, die in der Vergangenheit bei der Entwicklung von Software oder Automatisierungslösungen eingegangen wurden, und die heute zu erhöhtem Aufwand für Wartung, Weiterentwicklung oder Fehlerbehebung führen. Wie finanzielle Schulden akkumulieren technische Schulden Zinsen: je länger sie bestehen bleiben, desto mehr Mehraufwand verursachen sie.
Der Begriff wurde von Ward Cunningham geprägt: Manchmal ist es sinnvoll, eine schnelle, imperfekte Lösung zu implementieren, um kurzfristig voranzukommen – wie ein finanzieller Kredit. Aber wie ein Kredit muss auch Technical Debt zurückgezahlt werden. Wird das zu lange aufgeschoben, wird der akkumulierte Zinsaufwand (der stetig wachsende Wartungs- und Entwicklungsaufwand) unerträglich schwer zu tragen.
Fowlers Technical-Debt-Quadrant
Bewusst-Rücksichtslos
„Wir haben keine Zeit für gutes Design.“ Bewusste Entscheidung für schlechte Qualität ohne Plan zur Rückzahlung. Gefährlichste Form.
Bewusst-Umsichtig
„Wir müssen jetzt liefern, werden es später refactoren.“ Bewusste, begründete Entscheidung mit klarem Rückzahlungsplan – akzeptabel wenn eingehalten.
Unbewusst-Rücksichtslos
„Was ist Separation of Concerns?“ Schlechte Qualität durch Unwissen. Entsteht ohne Absicht – oft durch fehlende Senior-Erfahrung.
Unbewusst-Umsichtig
„Jetzt verstehen wir, wie wir das hätten bauen sollen.“ Lernen führt zur Erkenntnis, dass eine frühere Lösung suboptimal war. Natürlicher Teil von Wachstum.
Technische Schulden in der Automation erkennen
- Steigende Änderungskosten: Wenn einfache Anpassungen unverhältnismäßig lange dauern, deutet das auf akkumulierte Schulden hin
- Keine Dokumentation: Workflows, die niemand mehr vollständig versteht und an denen man nur mit Vorsicht arbeitet
- Copy-Paste-Logik: Dieselbe Logik an 12 verschiedenen Stellen – jede Änderung muss 12-mal gemacht werden
- Keine Fehlerbehandlung: Workflows, die bei der ersten Abweichung kommentarlos scheitern
- Fehlende Tests: Niemand weiß mit Sicherheit, ob ein Workflow unter allen Bedingungen korrekt funktioniert
Praxisbeispiel
Ein Unternehmen hat über 2 Jahre 34 Automatisierungsworkflows aufgebaut – größtenteils in schnellen Sprints ohne Refactoring-Budget. Symptome der akkumulierten technischen Schulden: Neue Workflows dauern doppelt so lange wie geplant, weil das Team zuerst verstehen muss, wie bestehende Workflows funktionieren. 8 Workflows haben keine Fehlerbehandlung – Ausfälle werden manchmal erst nach Stunden bemerkt. Dieselbe Lieferanten-Lookup-Logik ist an 11 verschiedenen Stellen implementiert. Keine Dokumentation außer den Workflow-Namen. Maßnahme: 20-Prozent-Regel – ein Tag pro Woche wird für technische Schulden-Rückzahlung reserviert. Priorisierung nach Auswirkung: zuerst fehlende Fehlerbehandlung, dann Copy-Paste-Konsolidierung, dann Dokumentation.
