- Technische Schulden sind erst dann kritisch, wenn sie Änderung, Sicherheit oder Betrieb messbar blockieren.
- Priorität bekommt nicht der hässlichste Code, sondern das größte Produkt- und Betriebsrisiko.
- Gute technische Leitung macht Schulden entscheidbar, statt sie nur zu beklagen.
Technische Schulden sind ein bequemes Wort für sehr unterschiedliche Probleme. Manchmal meint es unsauberen Code. Manchmal veraltete Abhängigkeiten. Manchmal eine Architektur, die neue Produktentscheidungen kaum noch zulässt.
Nicht jede technische Schuld ist ein akutes Problem. Gefährlich wird sie dort, wo sie Änderung, Sicherheit oder Betrieb blockiert.
Woran technische Schulden sichtbar werden
Technische Schulden zeigen sich selten als einzelner Fehler. Sie zeigen sich als Muster:
- Änderungen dauern länger als fachlich erklärbar.
- Kleine Anpassungen lösen unerwartete Seiteneffekte aus.
- Bestimmte Bereiche werden gemieden, weil niemand die Folgen einschätzen kann.
- Sicherheitsupdates bleiben liegen, weil Abhängigkeiten zu alt sind.
- Tests fehlen oder prüfen nicht das Verhalten, das wirklich zählt.
- Neue Funktionen brauchen Workarounds gegen die bestehende Architektur.
Das Problem ist nicht Ästhetik. Das Problem ist verlorene Handlungsfähigkeit.
Nicht jede Schuld hat dieselbe Priorität
Der wichtigste Schritt ist Priorisierung. Der hässlichste Code ist nicht automatisch der dringendste. Dringend ist, was Produkt, Betrieb oder Sicherheit konkret gefährdet.
| Schuldentyp | Priorität steigt, wenn |
|---|---|
| Veraltete Abhängigkeiten | Sicherheitsupdates blockiert sind oder Support ausläuft |
| Fehlende Tests | häufig geänderte Kernlogik betroffen ist |
| Unklare Architektur | wichtige Produktentscheidungen nicht mehr sauber umsetzbar sind |
| Schlechter Betrieb | Fehler spät erkannt werden oder Deployments riskant sind |
| Unverständlicher Code | Wissen nur bei einer Person liegt oder Änderungen vermieden werden |
So wird aus einem diffusen Gefühl eine entscheidbare Liste.
Ein einfaches Priorisierungsmodell
Technische Schulden werden greifbar, wenn jede Schuld nach denselben Kriterien bewertet wird. Eine einfache Skala von 1 bis 5 reicht oft aus.
| Kriterium | Frage |
|---|---|
| Geschäftswirkung | Welcher Umsatz, Prozess oder Kunde hängt daran? |
| Änderungsfrequenz | Wie oft wird dieser Bereich in den nächsten Monaten angefasst? |
| Fehlerrisiko | Wie teuer oder sichtbar wäre ein Fehler? |
| Sicherheitsrisiko | Blockiert die Schuld Updates, Rechte oder Datenschutz? |
| Hebel | Macht die Behebung mehrere spätere Änderungen leichter? |
Priorität bekommen Schulden mit hoher Geschäftswirkung, hoher Änderungsfrequenz und hohem Risiko. Niedrige Ästhetik allein reicht nicht.
Wie man priorisiert
Eine sinnvolle Priorisierung verbindet vier Fragen:
- Welcher Geschäftsprozess hängt daran?
- Wie oft wird dieser Bereich geändert?
- Wie hoch ist das Risiko bei Fehlern?
- Was kostet es, die Schuld jetzt gegenüber später abzubauen?
Diese Fragen verhindern zwei Fehler: alles liegen lassen, bis nichts mehr geht, oder alles auf einmal aufräumen wollen.
Der bessere Umgang
Technische Schulden werden am besten in laufende Produktarbeit eingebettet. Nicht jede Schuld braucht ein eigenes Großprojekt. Viele lassen sich an den Stellen abbauen, an denen ohnehin gearbeitet wird: Tests ergänzen, bevor eine Kernfunktion verändert wird; ein Modul isolieren, bevor es erweitert wird; eine Schnittstelle ordnen, bevor weitere Systeme angebunden werden.
Für größere Schulden braucht es dagegen bewusste Modernisierungsphasen. Dort ist entscheidend, dass nicht nur Code ersetzt wird, sondern Tragfähigkeit zurückkommt.
Beispiel für gute Priorität
Ein unleserliches Modul, das seit zwei Jahren nicht geändert wurde, ist ärgerlich. Ein mäßig sauberer Authentifizierungs- oder Abrechnungsbereich, der monatlich geändert wird und keine Tests hat, ist gefährlich. Die zweite Schuld gehört zuerst auf die Liste, auch wenn der Code weniger hässlich aussieht.
Gute Priorisierung fragt deshalb nicht: Was stört Entwickler am meisten? Sondern: Was macht die nächsten wichtigen Produktentscheidungen riskant oder teuer?
Fazit
Technische Schulden sind kein moralisches Versagen. Sie sind ein wirtschaftliches Thema. Entscheidend ist, ob sie sichtbar, bewertet und priorisiert sind.
Wenn technische Schulden wichtige Änderungen blockieren, ist eine Software-Modernisierung oft der bessere Weg als ein kompletter Neubau. Wenn technische Richtung fehlt, hilft technische Leitung auf Zeit, die Schulden entscheidbar zu machen.
