5 Warnsignale für kritische technische Schulden

Technische Schulden kündigen sich nicht an

Jedes Startup, das ich auditiert habe, hatte dieselbe Aussage parat: „Wir wissen, dass wir technische Schulden haben, aber wir haben keine Zeit, uns darum zu kümmern." Das Problem: Technische Schulden verhalten sich nicht wie Finanzschulden. Sie häufen keine gleichmäßigen Zinsen an — sie explodieren auf einen Schlag, wenn es zu spät ist.

Nach 14 Jahren und mehr als 30 technischen Audits habe ich 5 Signale identifiziert, die sich nicht täuschen lassen.

1. Explodierende Deployment-Zeiten

Wenn ein Deployment länger als 30 Minuten dauert, ist das selten ein Infrastrukturproblem. Es ist ein Symptom:

• Flaky Tests, die zufällig fehlschlagen und mit gedrückten Daumen neu gestartet werden
• CI/CD-Pipeline ohne Cache, die bei jedem Commit alles neu baut
• Keine Feature Flags, weshalb sich Code in immer länger werdenden Branches ansammelt

Die Alarmgrenze: Wenn Ihr Team zögert, einen Freitagabend zu deployen, haben Sie ein Problem.

So messen Sie es

Durchschnittliche Zeit zwischen Merge und Produktion
< 15 Min → ausgezeichnet
15–60 Min → akzeptabel
> 1 Std → kritische technische Schulden

2. Neue Features dauern dreimal so lang

Wenn ein Feature, das „zwei Tage dauern sollte", regelmäßig sechs Tage in Anspruch nimmt, ist das kein Schätzproblem. Es bedeutet, dass jede Änderung 15 Dateien berührt, drei unnötige Abstraktionsebenen erfordert und man nur hofft, nichts zu zerstören.

Die klassischen Ursachen:

• Starke Kopplung zwischen Modulen — man kann nichts anfassen, ohne Seiteneffekte zu erzeugen
• Vorzeitige Abstraktionen, die „für alle Fälle" erstellt wurden und nie wie geplant genutzt werden
• Fehlende Dokumentation vergangener Architekturentscheidungen

3. Bus-Faktor von 1

Wenn nur eine einzige Person das Zahlungssystem, die API-Integration oder die Deployment-Konfiguration versteht, haben Sie einen Bus-Faktor von 1. Das ist keine technische Schuld im engeren Sinne, aber ein Risiko, das sich auf dieselbe Weise materialisiert: eine Kündigung, und alles steht still.

Konkrete Warnsignale

• Code Reviews werden immer derselben Person zugewiesen
• Bestimmte Dateien haben seit 12 Monaten nur einen einzigen Contributor
• Das Onboarding eines neuen Entwicklers dauert länger als zwei Wochen

4. Produktionsfehler gelten als „normal"

Wenn das Team Sentry-Alerts als Hintergrundrauschen behandelt, ist etwas in der Qualitätskultur zerbrochen. Die Symptome:

• Mehr als 50 ungelöste Fehler im Tracker
• try/catch-Blöcke, die Exceptions stillschweigend verschlucken
• Monitoring ist vorhanden, aber niemand schaut hin

Bei ETX Majelan war das Erste, was ich nach meinem Start tat, die Uptime von 99,2 % auf 99,9 % zu bringen. Nicht mit Wunderwerkzeugen — sondern indem wir jeden Fehler ernst nahmen.

5. Das Team meidet bestimmte Code-Bereiche

Wenn Entwickler einen Modul systematisch umgehen, anstatt ihn zu ändern, ist das das deutlichste Zeichen für toxische technische Schulden. Sie haben durch Erfahrung gelernt: Wer diesen Code anfasst, öffnet die Büchse der Pandora.

Der einfache Test

Fragen Sie drei Entwickler: „Welcher Teil des Codes macht Ihnen am meisten Angst?" Geben alle drei dieselbe Antwort, ist das Ihre Priorität Nummer eins.

Wie Sie handeln

Technische Schulden lassen sich nicht auf einen Schlag abbauen. Dies ist der Ansatz, den ich bei Audits verfolge:

1. Kartieren — Risikobereiche identifizieren (Komplexität, Kopplung, Testabdeckung)
2. Beziffern — den Einfluss auf die Velocity schätzen (wie viel Zeit pro Sprint verloren geht)
3. Priorisieren — zuerst das angehen, was die Velocity blockiert, nicht das, was Puristen stört
4. Budgetieren — 20 % jedes Sprints für die Sanierung reservieren, nicht einen „Schulden-Sprint" alle sechs Monate

Technische Schulden sind kein Versagen. Sie sind das natürliche Ergebnis von Entscheidungen, die unter den richtigen Rahmenbedingungen des jeweiligen Moments getroffen wurden. Das Problem ist, sie nicht zu messen.