Technische Schulden sind Entscheidungen im Code oder in der Architektur, die kurzfristig Zeit gespart haben und langfristig Aufwand kosten. Sie werden sichtbar, wenn kleine Änderungen unverhältnismäßig lange dauern, Fehler in scheinbar unbeteiligten Bereichen auftreten oder neue Entwickler Wochen brauchen, um sich einzuarbeiten. Der Wert lässt sich in verlorenen Entwicklerstunden pro Sprint beziffern.
Woran erkennen Sie technische Schulden?
- Eine kleine fachliche Änderung braucht Tage statt Stunden.
- Neue Entwickler brauchen mehr als zwei Wochen bis zum ersten produktiven Commit.
- Änderungen in einem Modul brechen Funktionen an ganz anderer Stelle.
- Vor jedem Deployment sammeln sich Ausnahmefälle und Workarounds.
- Tests sind unzuverlässig oder werden regelmäßig übersprungen.
Wie beziffern Sie den Wert?
Messen Sie über zwei bis drei Sprints, wie viel Zeit für Fehlersuche, Merge-Konflikte und Umwege draufgeht. Ein Team von vier Entwicklern, das ein Drittel seiner Zeit an Schulden verliert, kostet ohne Gegenwert rund 200.000 € im Jahr.
Diese Zahl macht die Diskussion greifbar — auch für Geschäftsführer, die keine Codemetriken lesen. Aus einer abstrakten „Aufräumbaustelle“ wird eine konkrete Investition mit klarem Return.
Welche Schulden lohnen sich zuerst?
Nicht die technisch spannendsten, sondern die teuersten. Priorisieren Sie nach Bereichen, in denen häufig geändert wird — dort zahlt jede Verbesserung mehrfach. Ein aufgeräumter Modulschnitt in einem selten berührten Bereich bringt fachlich wenig.
Ein bewährtes Muster: Kartieren Sie die Anwendung nach Änderungshäufigkeit und Fehlerdichte. Wo beides hoch ist, liegt der Hebel.
Wie bauen Sie kontinuierlich ab?
- Reservieren Sie in jedem Sprint 15 bis 20 Prozent für gezielte Aufräumarbeiten — nicht mehr, nicht weniger.
- Verbessern Sie Code bei jeder Änderung im gleichen Bereich (Boy-Scout-Regel): sauberer verlassen als angetroffen.
- Verhindern Sie neue Schulden über Code-Reviews und automatisierte Qualitätsprüfungen.
- Dokumentieren Sie bewusste Abkürzungen als „Schuldposten“ — nur was benannt ist, wird zurückgezahlt.
Wann ist eine große Sanierung sinnvoll?
Selten. Große Neuschriften sind teuer, riskant und liefern monatelang keinen fachlichen Fortschritt. Sinnvoll sind sie nur, wenn die Technik grundlegend nicht mehr trägt — etwa eine abgekündigte Plattform oder ein Framework ohne Sicherheitsaktualisierungen.
Technische Schulden sind wie Zinsen: Man zahlt sie, ob man sie beziffert oder nicht.