Technische Schulden: wie messen und was zuerst beheben?

Technische Schulden bremsen die Entwicklung, sobald jede neue Funktion länger dauert als die vorherige. Für die Firma heißt das: eine Roadmap, die sich verschiebt, und Entwickler, die Brände löschen statt zu bauen.

Messen lassen sie sich ohne teures Tool, aus der Git-Historie und den Fehlern. Beheben Sie zuerst die Schulden im Code, der sich am häufigsten ändert, nicht im hässlichsten.

KI schreibt heute unseren gesamten Code, für das Ergebnis haftet ein Senior. Filip hat davor 7 Jahre lang ein SaaS-Produkt entwickelt. Schulden in einem Produkt, das jahrelang lebt, lösen Sie nicht in einem Sprint. Sie bauen sie laufend ab.

Woran erkennen Sie, dass technische Schulden Sie bremsen?

Schulden melden sich nicht selbst. Sie zeigen sich als Langsamkeit, die jeder anders erklärt. Ein Button, der einen Tag dauern sollte, dauert eine Woche. Haken Sie ab, was für Ihr Team gilt. Jeder offene Punkt ist ein Signal für Schulden.

Wie misst man technische Schulden ohne teures Tool?

Sie brauchen keine Plattform zur Codeanalyse. Sie brauchen eine Antwort auf die Frage, wo Änderungen Sie am meisten kosten.

Das stärkste Signal sind die ersten beiden Zeilen zusammen. Eine Datei, die sich oft ändert und zugleich Fehler bringt, ist eine Schuld mit Zinsen. Die Liste der am häufigsten geänderten Dateien liefert ein Befehl:

git log --since="6 months ago" --format= --name-only | sort | uniq -c | sort -rn | head -20

Notieren Sie zu jeder Datei im Ergebnis die Fehler, die sie betrafen. Die obersten Zeilen sind Ihre Liste.

Was sollte man zuerst beheben?

Nicht das Hässlichste. Das, was Sie gerade am meisten Zeit kostet. Die Reihenfolge, die wir nutzen:

Ganz am Ende stehen Ästhetik und der Wechsel auf ein neueres Framework, „weil es neuer ist“. Code, den monatelang niemand anfasst, darf hässlich bleiben. Er kostet Sie nichts. Wird er gar nicht genutzt, bauen wir ihn nicht ab, sondern löschen ihn. So machen wir es auch in unseren eigenen Repositories: ungenutzter Code und Werkzeuge, die niemand aufruft, fliegen raus.

Sind die Schulden in einem Teil so groß, dass Sie ein Neuschreiben erwägen, beginnen Sie genauso. Erst Tests für das heutige Verhalten, dann die Entscheidung. Wie Tests und Review eine schlechte Änderung wirklich stoppen, beschreiben wir in Wie führt man KI im Entwicklungsteam ein?.

Wie baut man Schulden ab, ohne die Roadmap zu stoppen?

Im selben Ablauf wie Funktionen. Nicht in einem „Refactoring-Sprint“, der sich immer wieder verschiebt, weil eine dringende Funktion kam.

• Ein fester Anteil der Kapazität. Vereinbaren Sie ihn vorab mit dem Produkt und greifen Sie beim ersten Notfall nicht darauf zu.
• Bauen Sie dort ab, wo Sie arbeiten. Wenn Sie eine Funktion in einem verschuldeten Modul bauen, räumen Sie es im selben Pull Request auf.
• Erst Test, dann Änderung. Ein Test für das heutige Verhalten fängt ab, was Sie sonst kaputt machen würden.
• Keine neuen Schulden ohne Eintrag. Wenn Sie bewusst eine Abkürzung nehmen, legen Sie sie als Aufgabe mit Begründung an.

So sieht das an einer Roadmap-Funktion aus:

KI ändert hier die Rechnung. Tests für bestehenden Code, Verschieben und Umbenennen waren teuer und wurden deshalb aufgeschoben. Mit KI sind sie günstig. Ohne Regeln und Review fügt KI aber genauso schnell Schulden hinzu. Was wir ihr dafür ins Repository legen, beschreiben wir in Regeln für KI-Code im Team.

Erste Schritte für diesen Monat:

1. Ziehen Sie die Liste der am häufigsten geänderten Dateien aus Git.
2. Notieren Sie zu jeder die Fehler der letzten Monate.
3. Wählen Sie drei Stellen, die die nächste Roadmap-Funktion blockieren.
4. Vereinbaren Sie mit dem Produkt einen festen Kapazitätsanteil für Schulden.
5. Prüfen Sie, dass die CI einen schlechten Merge stoppen kann.

Wann wir es nicht empfehlen

• Die Schulden bremsen Sie nicht, sie gefallen Ihnen nur nicht. Wenn sich dieser Code nicht ändert, lassen Sie ihn. Stecken Sie die Kapazität in die Roadmap.
• Das Produkt wird in ein paar Monaten abgeschaltet oder ersetzt. Schulden in Code abzubauen, der endet, lohnt sich nicht.

Wollen Sie Schulden mit jemandem abbauen, der das täglich macht?

Ein Senior steigt ab dem ersten Tag in Ihr Repository und Ihre Pull Requests ein. Er baut die Schulden im Weg der Roadmap ab, neben den Funktionen, nicht statt ihrer. So arbeiten wir als externer Entwickler für Produktteams.

Schreiben Sie uns, welcher Teil des Systems Sie am meisten bremst. Wir melden uns innerhalb von zwei Arbeitstagen und wählen gemeinsam, was wir zuerst lösen.

Wenn Sie lieber zuerst sprechen möchten, buchen Sie ein 15-Minuten-Meeting mit Filip.

Welche Datei in Ihrem Repository traut sich das ganze Team nicht zu öffnen?

Häufige Fragen

Wie misst man technische Schulden?

Am einfachsten aus der Git-Historie und den Fehlern. Dateien, die sich am häufigsten ändern und zugleich Fehler erzeugen, sind die Schulden, die Sie wirklich Zeit kosten. Dazu beobachten Sie, wie Schätzungen bei kleinen Änderungen wachsen.

Was sollte man zuerst beheben?

Schulden im Code, den Sie für die nächste Funktion der Roadmap brauchen. Dann häufig geänderten Code mit Fehlern. Code, den niemand anfasst, lassen Sie in Ruhe, auch wenn er hässlich ist.

Wie erklärt man technische Schulden der Geschäftsführung?

Über Zeit und Risiko, nicht über Codequalität. Zeigen Sie, wie viel länger Änderungen in einem bestimmten Teil dauern und wie viele Fehler von dort kommen. Am besten an einer Roadmap-Funktion, auf die die Geschäftsführung wartet.

Erhöht KI technische Schulden?

Ohne Regeln und Review ja, weil sie schnell und ohne Kontext schreibt. Mit Regeln im Repository, Tests und Review durch jemand anderen hilft sie beim Abbau. Tests und das Verschieben von Code sind mit KI günstig.