Technische Schulden erkennen und abbauen: ein pragmatischer Leitfaden

Technische Schulden sind kein Beweis für schlechte Softwareentwicklung. Fast jedes langlebige System enthält Abkürzungen, alte Annahmen und Strukturen, die heute nicht mehr gut passen. Problematisch werden sie erst, wenn niemand mehr weiß, wo sie liegen, welchen Preis sie verursachen und wann sie zurückgezahlt werden sollten.

Ich arbeite seit mehr als 14 Jahren an Webplattformen. Die gefährlichsten technischen Schulden waren selten die auffälligsten Code-Stellen. Teurer waren unsichtbare Schulden: ein Deployment, das nur eine Person versteht, eine Datenmigration ohne Rückweg oder dieselbe Sicherheitsregel in mehreren voneinander abweichenden Pfaden.

Dieser Leitfaden zeigt, wie ich technische Schulden erkenne, bewerte und in kleinen, überprüfbaren Schritten abbaue.

Was sind technische Schulden?

Technische Schulden entstehen, wenn eine heutige Entscheidung zukünftige Änderungen oder den Betrieb verteuert. Die Entscheidung kann bewusst und vernünftig sein. Ein Prototyp braucht andere Qualitätsgrenzen als ein Abrechnungssystem. Schulden werden jedoch riskant, wenn ihre Bedingungen nicht dokumentiert sind oder der ursprüngliche Zeitgewinn längst von laufenden Folgekosten überholt wurde.

Typische Formen sind:

• Code-Schulden: doppelte Regeln, unklare Zuständigkeiten oder schwer testbare Funktionen,
• Daten-Schulden: fehlende Constraints, unklare Eigentümerschaft oder nicht rücksetzbare Migrationen,
• Betriebs-Schulden: manuelle Deployments, unbekannte Wiederherstellungszeiten oder veraltete Abhängigkeiten,
• Wissens-Schulden: kritische Abläufe, die nur einzelne Personen kennen,
• Produkt-Schulden: dauerhaft gepflegte Funktionen, die kaum noch jemand nutzt.

Nicht jede dieser Stellen muss sofort verschwinden. Entscheidend ist ihr tatsächlicher Einfluss.

Woran erkenne ich technische Schulden?

Ein Code-Kommentar mit TODO ist nur ein Hinweis. Verlässlicher sind wiederkehrende Kosten im Entwicklungs- und Betriebsalltag.

Ich achte besonders auf fünf Signale:

1. Kleine Änderungen werden regelmäßig groß. Eine Beschriftung oder Regel muss an vielen Stellen angepasst werden.
2. Fehler treten in derselben Zone wieder auf. Die Symptome wechseln, die verantwortliche Grenze bleibt gleich.
3. Deployments brauchen Sonderwissen. Schritte leben in Chatverläufen oder im Gedächtnis statt in einem reproduzierbaren Ablauf.
4. Tests verhindern keine bekannten Rückfälle. Es gibt viele Tests, aber keinen für die geschäftskritische Regel.
5. Teams umgehen einen Bereich. Änderungen werden verschoben oder mit lokalen Ausnahmen umschifft, weil der eigentliche Besitzer unklar ist.

Metriken helfen, diese Wahrnehmung zu prüfen. Nützlich sind zum Beispiel fehlgeschlagene Deployments, Änderungsdurchlaufzeit, wieder geöffnete Fehler, Alarmhäufigkeit und die Zahl der Stellen, die für eine fachliche Regel geändert werden müssen. Eine einzelne Zahl ist kein Schuldenstand. Mehrere wiederkehrende Signale zeigen aber, wo genaueres Hinsehen lohnt.

Ein kleines Register statt einer riesigen Liste

Eine ungeordnete Sammlung von hundert technischen Aufgaben wird schnell zu einem zweiten Friedhof. Ich dokumentiere nur Schulden, die eine beobachtbare Folge haben.

Für jeden Eintrag reichen zunächst sechs Angaben:

So bleibt das Register entscheidbar. Ein Eintrag ohne konkrete Folge oder nächsten Schritt ist eher eine technische Meinung als eine Arbeitsgrundlage.

Wie priorisiere ich technische Schulden?

Ich priorisiere nicht nach Hässlichkeit des Codes, sondern nach Risiko und wiederkehrendem Preis.

Hohe Priorität haben Schulden, wenn sie:

• Datenverlust oder falsche Berechtigungen ermöglichen,
• Sicherheits- oder Datenschutzgrenzen schwächen,
• häufige Produktionsfehler auslösen,
• Releases oder Wiederherstellung blockieren,
• oder viele geplante Änderungen verteuern.

Niedrigere Priorität haben Stellen, die lokal, stabil und selten verändert sind. Ein alter, gut getesteter Parser kann weniger dringlich sein als eine moderne, aber dreifach duplizierte Löschregel.

Eine einfache Entscheidungshilfe ist:

Priorität = Auswirkung × Häufigkeit × Änderungsnähe

Das ist keine mathematisch exakte Formel. Sie zwingt das Team aber dazu, drei verschiedene Fragen zu beantworten: Wie schlimm ist der Fehler? Wie oft entsteht die Kostenstelle? Stehen dort überhaupt Änderungen an?

Technische Schulden abbauen, ohne alles neu zu schreiben

Ein Komplettumbau klingt sauber, verschiebt aber viel Risiko in einen einzigen Moment. Meist ist ein schrittweiser Abbau sicherer.

1. Das aktuelle Verhalten festhalten

Vor dem Umbau braucht die kritische Regel einen kleinen Test oder einen anderen reproduzierbaren Nachweis. Das gilt auch dann, wenn das heutige Verhalten nicht schön ist. Ohne Ausgangspunkt lässt sich nicht erkennen, ob die Änderung etwas verbessert oder nur anders kaputt macht.

2. Die verantwortliche Stelle finden

Liegt dieselbe Regel in mehreren Aufrufern, sollte sie an die gemeinsame fachliche Grenze wandern. Ein zentraler Guard ist kleiner und zuverlässiger als dieselbe Prüfung in jeder Route, jedem Job und jedem Import.

3. Einen kompatiblen Übergang bauen

Datenformate, APIs und Konfigurationen lassen sich selten in einem Schritt austauschen. Der sichere Weg ist meistens: neue Form ergänzen, bestehende Daten migrieren, Leser umstellen, Schreiber umstellen und erst danach die alte Form entfernen.

4. Den kleinsten vollständigen Schnitt liefern

Ein halber Umbau, der zwei dauerhafte Wahrheiten erzeugt, ist neue Schuld. Der Schritt sollte klein sein, aber eine Regel vollständig an ihren neuen Besitzer bringen. Wie ich solche Grenzen vorab bewerte, beschreibe ich ausführlicher in Softwarearchitektur in der Praxis.

5. Die Wirkung messen

Nach der Änderung prüfe ich die Folge, wegen der der Eintrag priorisiert wurde. Sinkt die Fehlerzahl? Ist das Deployment reproduzierbar? Müssen weniger Dateien geändert werden? Erst diese Beobachtung schließt den Eintrag.

Drei Beispiele aus der Praxis

Doppelte Löschlogik

Wenn jede neue Tabelle in eine manuelle Löschliste eingetragen werden muss, wird Vergessen zum Datenrisiko. Die bessere Grenze ist nicht ein weiterer Erinnerungskommentar, sondern eine gemeinsame, aus dem Schema abgeleitete Regel mit einem Test für Ausnahmen.

Ein manuelles Release

Ein Release, das nur mit einer privaten Befehlsfolge funktioniert, erzeugt Wissens- und Betriebs-Schulden. Ein dokumentierter, automatisierter Ablauf mit sichtbarem Status reduziert beides. Wichtig ist dabei nicht die Zahl der CI-Schritte, sondern dass Aufbau, Prüfung und Veröffentlichung reproduzierbar getrennt sind.

Eine zu große Produktfunktion

Manche Funktionen sind technisch korrekt und trotzdem dauerhaft teuer. Die Bewertungen auf Kann KI das? trennen deshalb einen nachbaubaren Funktionskern vom vollständigen Produkt und seinem Betrieb. Dieselbe Trennung hilft beim Schuldenabbau: Oft muss nicht das ganze System ersetzt werden. Es reicht, einen klar begrenzten, teuren Ablauf neu zu besitzen.

Wann darf technische Schuld bleiben?

Bewusst akzeptierte Schuld darf bleiben, wenn ihr Rahmen klar ist:

• Die Folge ist bekannt und begrenzt.
• Sicherheits-, Daten- und Berechtigungsgrenzen bleiben geschützt.
• Der aktuelle Aufwand ist kleiner als der Umbau.
• Es gibt einen Auslöser für die nächste Bewertung.
• Das Team weiß, wie die Stelle im Fehlerfall behandelt wird.

Bei HitKeep ist der kleine Betriebsumfang zum Beispiel eine bewusste Architekturentscheidung: ein einzelnes Go-Binary mit eingebetteter Speicherung und Queue statt mehrerer Pflichtdienste. Auch diese Entscheidung hat Grenzen. Sie ist tragfähig, solange Last, Datenmenge und Betriebsmodell zu den dokumentierten Fakten und Grenzen passen.

Die praktische Checkliste

Wenn du eine technische Schuld bewerten willst, beantworte diese Fragen:

1. Welche beobachtbare Folge verursacht sie heute?
2. Wie häufig und wie teuer ist diese Folge?
3. Berührt sie Daten, Sicherheit oder Berechtigungen?
4. Welche geplanten Änderungen laufen durch denselben Bereich?
5. Wo gehört die verantwortliche Regel hin?
6. Was ist der kleinste vollständige, kompatible Schritt?
7. Welcher Test schützt das Verhalten?
8. Welche Messung zeigt nachher, ob der Schritt geholfen hat?

Technische Schulden verschwinden nicht durch eine große Aufräumwoche. Sie werden beherrschbar, wenn ein Team ihre Folgen sichtbar macht, die wichtigste Regel an den richtigen Besitzer bringt und nach jedem kleinen Schritt prüft, ob die laufenden Kosten tatsächlich sinken.

Weitere Beispiele meiner Arbeit findest du unter Projekte und Kompetenzen. Wenn du eine langlebige Plattform bewerten oder einen riskanten Umbau strukturieren möchtest, erreichst du mich über Kontakt.