Technische Schulden, der stille Kostenfaktor

Was technische Schulden wirklich sind

Der Begriff stammt von Ward Cunningham, einem der Autoren des agilen Manifests. Sein Bild ist präzise. Wer eine schnelle, unsaubere Lösung wählt, nimmt einen Kredit auf. Das Produkt entsteht früher, doch auf den geliehenen Betrag fallen Zinsen an. Diese Zinsen sind der zusätzliche Aufwand, der bei jeder späteren Änderung anfällt, weil der Code komplizierter ist als nötig.

Technische Schulden sind also kein Synonym für schlechten Code. Sie beschreiben die Lücke zwischen der Lösung, die heute existiert, und der Lösung, die das Problem sauber abbilden würde. Diese Lücke kostet Geld, nur eben nicht sofort und nicht sichtbar auf einer Rechnung.

Technische Schulden sind ein finanzielles Versprechen an die Zukunft. Wer sie ignoriert, zahlt sie trotzdem zurück, nur mit Zinsen und ohne Plan.

Wie technische Schulden entstehen

Selten ist eine einzelne Entscheidung schuld. Schulden wachsen aus vielen kleinen Kompromissen, die für sich genommen harmlos wirken. Vier Quellen treten besonders häufig auf.

• Zeitdruck. Ein Termin steht, eine saubere Lösung würde drei Tage länger dauern, also wird die schnelle Variante gewählt. Das ist legitim, wird aber zur Schuld, sobald der geplante Nacharbeitstermin verfällt.
• Fehlendes Wissen zum Zeitpunkt der Entscheidung. Eine Architektur passt zu den Anforderungen von heute, doch die Anforderungen von übermorgen sind noch unbekannt. Was damals richtig war, wird später zur Last.
• Wechselnde Anforderungen. Ein System wurde für einen Zweck gebaut und über Jahre für andere Zwecke verbogen. Jede Erweiterung passte, das Gesamtbild verlor seine Form.
• Inkonsistenz im Team. Verschiedene Personen lösen dasselbe Problem auf verschiedene Weisen. Ohne gemeinsame Konventionen entstehen drei Wege für eine Aufgabe, und niemand weiß, welcher der gültige ist.

Abkürzungen sind nicht das eigentliche Problem. Das Problem ist die Abkürzung, die niemand notiert und die deshalb dauerhaft im System bleibt.

Warum die Weiterentwicklung teurer wird

Der Schaden zeigt sich erst, wenn am System weitergearbeitet wird. Jede neue Funktion muss sich durch die vorhandene Komplexität hindurcharbeiten. Was in einem sauberen System einen Tag dauert, dauert in einem belasteten System drei, weil zuerst verstanden, umgangen und abgesichert werden muss, was vorher liegen blieb.

Besonders tückisch ist der Zinseszins. Eine ungelöste Schuld erschwert die nächste Änderung, und diese Änderung fügt unter demselben Druck neue Schulden hinzu. Das System wird mit jeder Iteration schwerer wartbar, bis selbst kleine Anpassungen unverhältnismäßig viel Zeit kosten.

Die Zahlen sind Richtwerte, keine Naturkonstanten. Die Richtung gilt jedoch durchgängig. Unbezahlte Schulden verschieben Kapazität von der Wertschöpfung zur Verwaltung des Bestehenden. Irgendwann arbeitet ein Team mehr daran, das System am Leben zu halten, als daran, es zu verbessern.

Wie man technische Schulden sichtbar macht

Schulden lassen sich nur steuern, wenn sie benannt sind. Ein Bauchgefühl, dass ein Modul "irgendwie schwierig" ist, hilft niemandem bei der Priorisierung. Sichtbarkeit entsteht auf zwei Ebenen.

Das Schuldenregister

Eine schlichte Liste reicht. Jeder Eintrag beantwortet vier Fragen. Was ist die Schuld, wo im System liegt sie, was kostet ihre Behebung, und was kostet es, sie liegen zu lassen. Diese letzte Spalte ist die wichtigste, denn sie übersetzt ein technisches Detail in eine Sprache, die auch außerhalb der Entwicklung verstanden wird. Ein Eintrag wie "veraltete Bibliothek ohne Sicherheitsupdates, Behebung zwei Tage, Risiko eines ungepatchten Einbruchs" macht aus einem abstrakten Problem eine konkrete Abwägung.

Objektive Metriken

Das Register beruht auf Einschätzungen. Metriken ergänzen es um harte Daten. Die Testabdeckung zeigt, wie viel Code überhaupt automatisch geprüft wird. Eine steigende Build-Dauer deutet auf wuchernde Abhängigkeiten hin. Die Fehlerrate aus dem laufenden Betrieb zeigt, wo der Code brüchig ist. Statische Analysewerkzeuge melden Duplikate, überlange Funktionen und ungenutzte Teile. Keine dieser Zahlen erzählt allein die ganze Geschichte, doch zusammen zeichnen sie ein verlässliches Bild.

Wer Schulden sichtbar macht, denkt bereits weiter, statt nur das nächste Feature abzuarbeiten. Genau diese Haltung beschreibt unsere Mission mit den vier Bewegungen weiter denken, weiter planen, weiter umsetzen und weiter gehen.

Wie man Schulden kontrolliert abbaut

Ein System auf null Schulden zu bringen, ist weder möglich noch sinnvoll. Das Ziel ist Kontrolle, nicht Perfektion. Drei Prinzipien haben sich bewährt.

Erstens, fester Anteil statt großer Aufräumprojekte. Ein dauerhaft reservierter Teil der Kapazität, oft im Bereich von 15 bis 20 Prozent, hält die Schuld in Schach, ohne die Entwicklung neuer Funktionen zu stoppen. Das große Refactoring-Projekt, das alles auf einmal lösen soll, scheitert dagegen meist am ersten verschobenen Termin.

Zweitens, nach Wirkung priorisieren. Nicht jede Schuld ist gleich teuer. Code, der selten angefasst wird und stabil läuft, darf unsauber bleiben. Energie gehört dorthin, wo häufig gearbeitet wird und wo Fehler den Betrieb treffen. Eine einfache Matrix aus Häufigkeit der Änderung und Höhe des Risikos genügt, um die richtigen Stellen zu finden.

Drittens, Abbau in den normalen Fluss einbetten. Die Pfadfinderregel bringt es auf den Punkt. Wer ohnehin in einem Bereich arbeitet, hinterlässt ihn ein wenig besser als vorgefunden. So sinkt die Schuld kontinuierlich genau dort, wo gearbeitet wird, ohne dass ein gesondertes Budget verhandelt werden muss.

Begleitet wird der Abbau durch Vorsorge. Eine solide Testabdeckung macht Änderungen sicher, eine automatisierte Pipeline fängt Regressionen früh ab, und klare Konventionen verhindern, dass neue Schulden in gleichem Tempo nachwachsen. Sicherheit gehört dabei nicht als Nachgedanke behandelt, denn eine veraltete Abhängigkeit ist eine Schuld mit unmittelbarem Risiko, etwa wenn personenbezogene Daten betroffen sind, deren Verarbeitung nach Art. 6 DSGVO ohnehin eine saubere Grundlage verlangt.

Schulden als Führungsthema, nicht nur als Technikfrage

Der häufigste Grund für überbordende technische Schulden ist nicht mangelnde Sorgfalt im Code. Es ist eine Steuerung, die ausschließlich neue Funktionen belohnt und Pflege als verlorene Zeit betrachtet. Solange der Aufwand für den Abbau unsichtbar bleibt, verliert er jede Priorisierung gegen den nächsten sichtbaren Termin.

Sichtbar gemachte Schulden ändern dieses Gespräch. Sobald die laufenden Kosten in Tagen und Risiken ausgedrückt sind, wird der Abbau zu einer wirtschaftlichen Entscheidung wie jede andere. Die Frage lautet dann nicht mehr, ob man sich Pflege leisten kann, sondern ob man sich die Zinsen weiter leisten will. In den meisten Fällen lautet die ehrliche Antwort nein.

Wir gehen technische Schulden als Teil der Produktstrategie an, nicht als nachträgliche Reparatur. Wer früh misst, sauber priorisiert und den Abbau fest einplant, hält die Entwicklung schnell und die Kosten vorhersehbar. Für eine ehrliche Einschätzung eines bestehenden Systems lohnt ein Gespräch.

---

Wo steht ein System wirklich? Wir nehmen es unter die Lupe und zeigen die größten Schuldenposten samt Abbauplan.