Technische Schulden: was sie kosten und wie man sie abbaut

Technische Schulden sind Abkürzungen im Code und in der Architektur, die heute Zeit sparen und später jede Änderung teurer machen. Der Begriff stammt aus der Buchhaltung: Wer eine Abkürzung nimmt, leiht sich Geschwindigkeit und zahlt Zinsen in Form von Aufwand. Sichtbar wird das erst, wenn kleine Anpassungen unerklärlich lange dauern.

Technische Schulden: der Begriff

Gemeint ist nicht schlechter Code an sich, sondern eine bewusste oder unbewusste Abweichung vom sauberen Weg. Bewusst aufgenommene Schulden sind legitim: Ein Termin steht an, eine Vereinfachung wird eingebaut, und die Rückzahlung wird eingeplant. Unbewusst entstandene Schulden sind der gefährlichere Teil, weil niemand weiß, wo sie liegen.

Formen, die in Webprojekten regelmäßig auftreten: doppelte Logik an mehreren Stellen, fehlende Tests, veraltete Bibliotheken, ein Datenmodell, das den heutigen Fachbegriffen nicht mehr entspricht, Konfiguration im Code statt in Einstellungen, und Wissen, das nur in einem Kopf existiert.

Wie technische Schulden entstehen

• Termindruck. Die schnelle Lösung wird geliefert, die saubere verschoben und nie nachgeholt.
• Wechselnde Anforderungen. Der ursprüngliche Entwurf passt nicht mehr, wird aber weiter gedehnt statt angepasst.
• Fehlende Beschreibung. Ohne festgehaltene Anforderungen entstehen Sonderfälle als Ausnahmen im Code, siehe Lastenheft und Pflichtenheft.
• Personalwechsel. Neue Entwickler bauen daneben statt hinein, weil sie den Bestand nicht überblicken.
• Werkzeuge von gestern. Aufbau und Auslieferung laufen nur auf einem bestimmten Rechner oder in einem Verfahren, das niemand mehr vollständig beschreiben kann.
• Alterung. Auch unveränderter Code veraltet, wenn Umgebung und Bibliotheken weiterziehen.

Was sie im Alltag kosten

Technische Schulden erscheinen nie als Position in einer Rechnung, sondern als Verhalten des Teams. Typische Anzeichen: Eine überschaubare Änderung braucht mehrere Anläufe. Jede Auslieferung erzeugt Fehler an anderer Stelle. Niemand traut sich an ein bestimmtes Modul. Einarbeitung dauert Monate statt Tage. Fachbereiche hören öfter „das geht nicht“ als „das dauert“.

Für die Geschäftsführung ist die entscheidende Größe nicht die Menge des Altbestands, sondern die Zeit vom Wunsch bis zur Auslieferung. Wächst diese Zeit bei gleichbleibender Mannschaft, wächst der Schuldenstand.

Ein einfacher Weg, das Thema mit der Geschäftsführung zu besprechen, ist der Vergleich zweier Quartale: Wie viele Wünsche des Fachbereichs wurden umgesetzt, wie viel Aufwand ging in Fehlerbehebung und Wartung? Verschiebt sich dieses Verhältnis über mehrere Quartale in dieselbe Richtung, ist das ein Befund und keine Stimmung.

Wie man sie sichtbar macht

Was nicht im selben Vorgangssystem steht wie die fachlichen Aufgaben, wird nicht priorisiert. Bewährt hat sich ein Register, das jeden bekannten Posten mit vier Angaben führt: betroffener Bereich, Auswirkung im Alltag, geschätzter Aufwand für die Behebung und Risiko beim Nichtstun.

Ergänzend helfen messbare Signale: Testabdeckung in den kritischen Bereichen, Anzahl veralteter Bibliotheken mit bekannten Sicherheitslücken, Fehlerrate nach Auslieferungen, Dauer eines vollständigen Durchlaufs der automatischen Prüfungen. Diese Zahlen ersetzen die Diskussion über Geschmack durch einen Verlauf.

Wie man sie geordnet abbaut

Die große Aufräumaktion ist selten die richtige Antwort: Sie bindet die Mannschaft, liefert dem Fachbereich nichts und wird beim ersten dringenden Wunsch abgebrochen. Besser sind drei Regeln:

1. Anteil reservieren. Ein fester Teil jeder Etappe geht an den Abbau – klein genug, dass er nie gestrichen wird.
2. Am Ort der Arbeit aufräumen. Wer ein Modul ohnehin anfasst, hinterlässt es besser als er es vorgefunden hat; die Kenntnis ist ohnehin gerade da.
3. Nach Schmerz priorisieren. Zuerst die Bereiche, die häufig geändert werden. Selten berührter Code darf alt bleiben.

Wird der Bestand zu groß für diesen Weg, ist der nächste Schritt eine geplante Ablösung, siehe Legacy-Modernisierung.

Wichtig ist außerdem, den Abbau messbar zu machen. Wer eine Kennzahl vor und nach der Arbeit erhebt – etwa die Dauer der automatischen Prüfungen oder die Fehlerrate nach einer Auslieferung –, kann den Nutzen belegen und bekommt beim nächsten Mal leichter Zeit dafür bewilligt.

Wie wir neue Schulden begrenzen

In unseren Projekten gehören automatische Prüfungen, Code-Review und eine wiederholbare Auslieferung von Anfang an dazu, nicht als spätere Ergänzung; bewusst aufgenommene Abkürzungen werden im Register festgehalten, damit sie nicht in Vergessenheit geraten. Auch ein erster Versuch bekommt ein tragfähiges Fundament, siehe MVP-Entwicklung. Wie wir Projekte insgesamt zuschneiden, steht auf der Seite Softwareentwicklung.