"Wir haben technische Schulden" – diesen Satz höre ich in fast jedem Erstgespräch. Direkt gefolgt von betroffenem Nicken aller Anwesenden und der kollektiven Hoffnung, dass sich das Problem irgendwie von selbst löst, wenn man nur lange genug wartet. Spoiler: Tut es nicht. Technische Schulden sind kein Wein – sie werden mit der Zeit nicht besser.

Das Problem mit unsichtbaren Schulden

Tech-Debt ist keine abstrakte Metapher – er schlägt sich in konkreten Kosten nieder: längere Entwicklungszeiten, häufigere Bugs, frustrierte Entwickler, schwierige Onboardings. Das Problem ist: Diese Kosten verteilen sich unsichtbar auf den Alltag, statt als eindeutiger Posten in einem Budget aufzutauchen. Niemand bucht "drei Stunden Kampf mit dem Legacy-Modul" als technische Schulden – aber genau das sind sie.

Deshalb ist der erste Schritt nicht Refactoring, sondern Sichtbarkeit.

Drei Metriken, die ich immer erhebe

1. Zyklomatische Komplexität pro Datei

Dateien mit sehr hoher zyklomatischer Komplexität sind Hotspots – sie sind schwer zu testen, fehleranfällig und bremsen Entwickler aus. Tools wie phploc oder pdepend liefern diese Kennzahl für das gesamte Projekt in Sekunden.

2. Änderungsfrequenz (Git-Log-Analyse)

Welche Dateien werden am häufigsten geändert? In Kombination mit Komplexitätswerten entsteht das klassische "Hotspot-Diagramm": Dateien, die sowohl komplex als auch häufig angefasst werden, verursachen den größten Schaden und sind die wichtigsten Refactoring-Kandidaten. Meistens kennt das Team diese Dateien bereits beim Namen – und nennt sie intern nur "das Monster" oder "die Hydra".

3. Test-Coverage nach Modul

Nicht die Gesamt-Coverage ist entscheidend, sondern die Coverage der kritischen Business-Logik. Ein Modul mit 10% Coverage, das täglich geändert wird, ist ein ernstes Risiko. Ein Modul mit 0% Coverage, das seit drei Jahren nicht angefasst wurde, ist es deutlich weniger – es schläft, und man lässt es besser schlafen.

Visualisierung schafft Verständnis

Zahlen allein überzeugen selten. Was wirkt, sind visuelle Darstellungen, die Nicht-Techniker verstehen. Ein einfaches Bubble-Chart, das Komplexität gegen Änderungsfrequenz trägt, reicht oft aus, um in einem Gespräch mit Stakeholdern Prioritäten zu setzen – ohne technischen Detailkram, der alle außer dir einschlafen lässt.

Tech-Debt-Abbau beginnt nicht mit dem ersten Commit, sondern mit dem ersten Gespräch. Und das Gespräch beginnt mit einem Bild, das alle verstehen.

Fazit

Wer technische Schulden sichtbar macht, gibt dem Team und der Führungsebene eine gemeinsame Sprache. Damit werden Priorisierungsgespräche möglich – und gezielte Investitionen in Codequalität, statt blindes Refactoring nach Bauchgefühl.