Engineering-Handwerk · Tag 8: Technische Schulden abbauen

Willkommen zu Tag 8 unserer Serie Engineering-Handwerk. Wir schließen die Reihe heute mit dem Thema ab, das früher oder später jedes Projekt einholt: technische Schulden. Fast jedes Team, das wir kennenlernen, spürt sie – als das dumpfe Gefühl, dass alles länger dauert als früher, dass kleine Änderungen unerwartete Fehler auslösen und dass niemand mehr so recht weiß, warum ein bestimmter Teil des Codes ist, wie er ist. Technische Schulden sind selten der Grund, warum ein Projekt an einem einzelnen Tag scheitert. Sie sind der Grund, warum es über Monate hinweg immer zäher wird. In dieser letzten Episode zeigen wir, wie du technische Schulden sichtbar machst, ehrlich bewertest und kontrolliert abbaust – ohne dass daraus ein endloses Refactoring-Projekt wird, das den Betrieb lahmlegt.

Was technische Schulden wirklich sind

Die Metapher stammt vom Programmierer Ward Cunningham und ist präziser, als sie zunächst klingt. Wer schnell eine unsaubere Lösung baut, um früher live zu gehen, nimmt einen Kredit auf. Der Kredit ist nicht per se schlecht – manchmal ist er sogar klug, weil man dadurch schneller lernt oder eine Deadline hält. Das Problem sind die Zinsen: Jede weitere Änderung an diesem Code kostet ab jetzt ein bisschen mehr Zeit und ein bisschen mehr Nerven. Und diese Zinsen zahlst du still weiter, Sprint für Sprint, bis du die Schuld tilgst.

Wichtig ist die Unterscheidung zwischen zwei Arten. Es gibt bewusste Schulden: Das Team weiß, dass eine Lösung provisorisch ist, entscheidet sich absichtlich dafür und notiert das. Und es gibt unbewusste Schulden: Sie entstehen, weil man es zum Zeitpunkt der Umsetzung nicht besser wusste – weil sich Anforderungen später verschoben haben, weil eine Bibliothek anders funktioniert als erwartet, oder weil das Wissen über die Domäne erst mit der Zeit wuchs. Unbewusste Schulden sind die tückischeren, weil niemand sie aufgeschrieben hat und sie erst dann auffallen, wenn sie schon weh tun.

Nicht jede Unsauberkeit ist eine Schuld

Hier lohnt sich Ehrlichkeit in beide Richtungen. Nicht jeder Code, der dir nicht gefällt, ist eine echte Schuld. Ein hässlicher, aber stabiler Modul, den seit zwei Jahren niemand mehr angefasst hat und der auch in Zukunft nicht angefasst wird, verursacht keine Zinsen. Er ist einfach nur alt. Umgekehrt kann ein sauber aussehender Code eine massive Schuld sein, wenn die falsche Abstraktion darunter jede neue Anforderung zum Kampf macht. Die entscheidende Frage lautet also nicht „Ist das schön?“, sondern „Bremst uns das aus, wenn wir hier weiterarbeiten wollen?“.

Warum technische Schulden unsichtbar teuer sind

Der gefährlichste Aspekt technischer Schulden ist, dass sie in keiner Rechnung auftauchen. Es gibt keine Position im Budget mit der Aufschrift „Zinsen für schlechte Architektur“. Stattdessen verteilen sich die Kosten auf tausend kleine Momente, die einzeln harmlos wirken.

Änderungen werden langsamer

In einem gesunden System kostet ein neues Feature ungefähr das, was seine Komplexität erwarten lässt. In einem verschuldeten System kostet dasselbe Feature das Zwei- oder Dreifache, weil man erst verstehen muss, wie die verworrene bestehende Logik funktioniert, weil man an drei Stellen dasselbe ändern muss statt an einer, und weil man Angst hat, etwas kaputtzumachen, das man nicht überblickt. Diese Verlangsamung ist selten dramatisch genug, um an einem einzelnen Tag aufzufallen – aber über ein Jahr summiert sie sich zu einer erheblichen Menge verlorener Entwicklungszeit.

Fehler häufen sich

Wo Zuständigkeiten unklar sind und dieselbe Regel an mehreren Stellen dupliziert wurde, entstehen Fehler fast von allein. Man ändert eine der drei Kopien und übersieht die anderen beiden. Ein Randfall, den vor einem Jahr jemand mühsam abgefangen hat, geht bei einem Umbau verloren, weil niemand mehr wusste, wofür diese seltsame Bedingung eigentlich da war. Steigende Fehlerraten sind oft das erste messbare Symptom wachsender technischer Schulden.

Das Team verliert Vertrauen

Der teuerste, aber am seltensten benannte Effekt ist psychologisch. In einem stark verschuldeten System trauen sich Entwickler irgendwann nicht mehr, mutige Änderungen vorzuschlagen. Jede Anpassung fühlt sich riskant an, also wählt man die kleinste, vorsichtigste, hässlichste Variante – die wiederum neue Schulden hinzufügt. So entsteht eine Abwärtsspirale, in der die Schulden schneller wachsen, als man sie tilgen kann.

Ein konkretes Praxisbeispiel

Ein Beispiel aus unserer Arbeit, leicht anonymisiert. Ein Kunde betrieb einen Onlineshop, bei dem die Berechnung des Endpreises – Rabatte, Mengenstaffeln, Versandkosten, Steuersätze – über die Jahre gewachsen war. Ursprünglich gab es eine einzige Rabattart. Dann kam ein Gutscheincode dazu. Dann kundenspezifische Preise für Geschäftskunden. Dann eine Aktion mit gestaffelten Mengenrabatten. Jede dieser Erweiterungen wurde dort eingebaut, wo es am schnellsten ging: als zusätzliche Bedingung in einer bereits langen Funktion, die inzwischen über 600 Zeilen umfasste.

Das Symptom, mit dem der Kunde zu uns kam, war nicht „unsere Preisberechnung ist unübersichtlich“. Das Symptom war: „Jedes Mal, wenn wir eine neue Aktion einführen, dauert es zwei Wochen statt zwei Tagen, und in etwa jedem dritten Fall entsteht ein Preisfehler, den erst ein Kunde bemerkt.“ Das ist der typische Weg, wie technische Schulden ans Licht kommen – nicht als Beschwerde über den Code, sondern als Beschwerde über Geschwindigkeit und Fehler.

Wir haben die Schuld zuerst sichtbar gemacht: Wie viele verschiedene Preisregeln gibt es? Wie oft wird diese Funktion pro Quartal geändert? Wie viele der letzten Bugs im Ticketsystem hingen mit ihr zusammen? Die Antworten waren eindeutig – zwölf Regeln, im Schnitt zwei Änderungen pro Monat, und sieben der letzten zehn Preis-Bugs stammten aus dieser einen Funktion. Damit war klar, dass sich ein Umbau lohnt, weil hier ständig Zinsen anfielen. Wir haben die eine Riesenfunktion in klar getrennte, einzeln testbare Regeln zerlegt, jede mit einem eigenen Namen und eigenen Tests. Der Umbau kostete rund anderthalb Wochen. Die nächste Aktion danach war in drei Tagen umgesetzt – und ohne neuen Preisfehler. Die Investition hatte sich nach zwei weiteren Aktionen amortisiert.

Technische Schulden sichtbar machen

Schulden, die niemand sieht, werden nie priorisiert. Der erste und wichtigste Schritt ist deshalb, sie aus dem Bauchgefühl in etwas Greifbares zu überführen. Drei Werkzeuge haben sich für uns bewährt.

Im Code markieren

Wenn du bewusst eine Abkürzung nimmst oder eine problematische Stelle entdeckst, hinterlasse eine kurze, einheitliche Markierung direkt im Code – zusammen mit einem Satz, warum es so ist und was besser wäre. Das kostet zehn Sekunden und macht aus einer unbewussten eine bewusste Schuld. Wichtig ist Einheitlichkeit, damit sich alle Markierungen später mit einer einzigen Suche auflisten lassen. So verwandelst du verstreutes Wissen in eine durchsuchbare Landkarte deiner Schwachstellen.

Ein sichtbares Schulden-Backlog führen

Größere Schulden gehören nicht nur in den Code, sondern in dasselbe Backlog, in dem auch Features und Bugs stehen. Nur dort werden sie im Planungsgespräch überhaupt sichtbar. Jeder Eintrag sollte zwei Dinge festhalten: Was kostet uns diese Schuld gerade konkret (welche Arbeit wird dadurch langsamer oder riskanter)? Und was würde es kosten, sie abzubauen? Ohne diese beiden Zahlen bleibt jede Diskussion über Schulden reine Geschmackssache – mit ihnen wird sie eine nüchterne Abwägung.

Messbare Signale beobachten

Du musst technische Schulden nicht ausschließlich nach Gefühl bewerten. Ein paar einfache Signale helfen, die schlimmsten Stellen objektiv zu finden: Welche Dateien werden am häufigsten geändert – und tauchen dieselben Dateien auffällig oft in Fehlerberichten auf? Solche „Hotspots“, die gleichzeitig oft angefasst werden und oft Ärger machen, sind fast immer die lohnendsten Kandidaten für einen Abbau. Es ergibt wenig Sinn, einen eleganten, aber ruhenden Modul zu polieren, während der eigentliche Schmerz woanders sitzt.

Technische Schulden kontrolliert abbauen

Sichtbarmachen allein ändert nichts. Der Abbau muss zum festen Bestandteil der Arbeit werden – aber ohne dass daraus ein monatelanges Stillstands-Refactoring wird, bei dem keine neuen Features entstehen. Wir setzen auf drei Strategien parallel.

Die Boy-Scout-Regel

Der Grundsatz lautet: Hinterlasse den Code ein kleines bisschen sauberer, als du ihn vorgefunden hast. Wer ohnehin gerade in einer Datei arbeitet, benennt nebenbei eine irreführende Variable um, zieht eine doppelte Bedingung zusammen oder ergänzt einen fehlenden Test. Diese Mikro-Verbesserungen kosten fast nichts, weil du sowieso schon im Kontext bist, und sie halten die Bereiche gesund, die tatsächlich in Bewegung sind. Wichtig ist die Disziplin, es beim „ein bisschen“ zu belassen und nicht mitten in einer Feature-Aufgabe einen riesigen Umbau zu starten.

An Feature-Arbeit koppeln

Der wirksamste Hebel: Baue Schulden dort ab, wo du ohnehin gerade ein Feature entwickelst. Wenn ein neues Feature einen bestimmten Bereich berührt, ist genau das der richtige Moment, um diesen Bereich vorher aufzuräumen. Man macht die Änderung, die man braucht, einfach zu machen – und macht dann die einfache Änderung. So zahlt sich der Abbau sofort im laufenden Vorhaben aus, statt eine separate Rechtfertigung zu brauchen. Das Preisberechnungs-Beispiel oben folgte genau diesem Muster: Der Umbau lohnte sich, weil dort ständig neue Features anstanden.

Dedizierte Zeit einplanen

Manche Schulden sind zu groß, um sie nebenbei zu erledigen, und liegen in Bereichen, die gerade keine neuen Features bekommen. Dafür braucht es bewusst reservierte Zeit – etwa ein fester Anteil jeder Iteration oder gelegentlich eine ganze Woche für einen größeren Umbau. Entscheidend ist, diesen Anteil realistisch und dauerhaft zu halten. Ein regelmäßiger, kleiner Anteil ist wirkungsvoller als eine einmalige große Aufräumaktion, die danach nie wiederholt wird und deren Ergebnis binnen Monaten neu verschuldet ist.

Wann man Schulden bewusst aufnimmt

Der reife Umgang mit technischen Schulden bedeutet nicht, sie um jeden Preis zu vermeiden. Manchmal ist es die richtige Entscheidung, bewusst Schulden aufzunehmen. Wenn du noch nicht weißt, ob ein Feature überhaupt angenommen wird, wäre eine perfekt gebaute Lösung Verschwendung – eine schnelle, klar als provisorisch markierte Variante ist klüger. Wenn eine harte Deadline über dem geschäftlichen Erfolg entscheidet, kann es sinnvoll sein, einige Zinsen in Kauf zu nehmen, um rechtzeitig live zu gehen.

Die Bedingungen für gute bewusste Schulden sind aber immer dieselben: Die Entscheidung fällt absichtlich, nicht aus Nachlässigkeit. Sie wird dokumentiert, damit sie nicht in Vergessenheit gerät. Und es gibt eine grobe Vorstellung davon, wann die Schuld getilgt wird. Schulden, die man mit offenen Augen aufnimmt und im Blick behält, sind ein Werkzeug. Schulden, die einem passieren und die niemand mehr kennt, sind ein Risiko.

So gehst du vor

Wenn du in den nächsten Wochen konkret gegen technische Schulden vorgehen willst, hat sich diese Reihenfolge bewährt:

• Schmerz benennen. Frag dein Team, welche Bereiche des Systems sich beim Arbeiten am zähesten anfühlen und wo die meisten Fehler entstehen. Das Bauchgefühl der Leute, die täglich im Code sind, ist erstaunlich treffsicher.
• Mit Daten gegenprüfen. Gleiche die genannten Bereiche mit den Fakten ab: Welche Dateien werden am häufigsten geändert, welche tauchen am häufigsten in Fehlerberichten auf? So findest du die echten Hotspots statt der lautesten Meinungen.
• Sichtbar machen. Trag die größten Schulden als Einträge ins Backlog ein – jeweils mit Kosten der Schuld und geschätztem Abbau-Aufwand. Markiere kleinere Stellen einheitlich im Code.
• Priorisieren. Nimm dir zuerst die Schulden vor, die oft angefasst werden und oft Fehler verursachen. Ignoriere bewusst die ruhenden, hässlichen Ecken, die niemanden ausbremsen.
• Abbau verankern. Koppel den Abbau an anstehende Features, wende die Boy-Scout-Regel im Alltag an und reserviere für die großen Brocken feste Zeit. Halte diesen Rhythmus dauerhaft.
• Wirkung prüfen. Beobachte nach ein paar Wochen, ob Änderungen in den bearbeiteten Bereichen schneller und fehlerärmer werden. Diese Rückmeldung rechtfertigt die Investition gegenüber allen, die Zweifel haben.

Dieser Kreislauf muss nicht perfekt sein. Er muss nur regelmäßig stattfinden. Ein Team, das jede Woche ein kleines Stück Schuld tilgt, ist einem Team, das einmal im Jahr eine große Aufräumaktion plant und dann verschiebt, langfristig weit überlegen.

Fazit

Technische Schulden sind kein moralisches Versagen, sondern ein normaler Nebeneffekt jeder Software, die lange genug lebt und sich weiterentwickelt. Der Unterschied zwischen gesunden und leidenden Projekten liegt nicht darin, ob Schulden entstehen, sondern ob sie sichtbar sind und kontrolliert abgebaut werden. Wer sie benennt, misst, priorisiert und Stück für Stück tilgt, hält sein System dauerhaft änderbar – und genau die Änderbarkeit ist es, die über Jahre den Unterschied macht.

Damit endet unsere Serie Engineering-Handwerk. Über acht Tage haben wir gezeigt, dass gute Software nicht aus einem einzelnen Geniestreich entsteht, sondern aus vielen soliden Gewohnheiten: klaren Anforderungen, ehrlichen Schätzungen, verständlichem Code, verlässlichen Tests, ruhigen Deployments, gepflegter Dokumentation, aufmerksamem Betrieb – und dem bewussten Umgang mit den Schulden, die sich unterwegs ansammeln. Handwerk bedeutet, diese Dinge nicht als lästige Pflicht zu sehen, sondern als das, was Arbeit auf Dauer schnell und angenehm hält.

Alle acht Episoden findest du in der Serien-Übersicht. Wenn du das Gefühl hast, dass technische Schulden dein Team ausbremsen und du einen ehrlichen, pragmatischen Partner suchst, der Software nicht nur baut, sondern langfristig gesund hält, dann schau dir unsere Softwareentwicklung an oder nimm direkt Kontakt mit uns auf. Wir hören zu, bevor wir bauen – und wir sagen ehrlich, wo sich ein Abbau lohnt und wo nicht.