Was sind technische Schulden?

Technische Schulden (englisch technical debt) sind Abkürzungen und Versäumnisse in Software, die heute Zeit sparen und jede spätere Änderung teurer machen. Wie bei einem Kredit zahlt man Zinsen: Jede neue Funktion dauert länger, solange die Schuld nicht abgebaut ist.

Die Metapher stammt von Ward Cunningham, einem der Unterzeichner des Agilen Manifests. Sie hat sich durchgesetzt, weil sie ein technisches Problem in eine Sprache übersetzt, die jede Geschäftsführung versteht.

Wie technische Schulden entstehen

Technische Schulden sind nicht automatisch ein Zeichen schlechter Arbeit. Manchmal sind sie eine bewusste Entscheidung, etwa wenn ein MVP schnell zeigen soll, ob eine Idee trägt. Problematisch wird es, wenn niemand die Schuld notiert und niemand sie zurückzahlt.

Die häufigsten Ursachen:

• Termindruck: „Wir machen das erst einmal schnell und räumen später auf.“ Das Später kommt selten.
• Fehlende Tests: Ohne automatische Tests traut sich niemand, bestehenden Code zu verbessern.
• Veraltete Bibliotheken und Frameworks: Jedes ausgelassene Update macht das nächste größer.
• Wissen in einem Kopf: Nur ein Entwickler versteht einen Teil des Systems, dokumentiert ist nichts.
• Gewachsene Sonderfälle: Jede Kundenanforderung wurde als Ausnahme eingebaut, bis niemand mehr den Überblick hat.
• Keine reproduzierbare Umgebung: Die Software läuft nur auf einem bestimmten Rechner, eine saubere Entwicklungsumgebung auf localhost lässt sich nicht mehr aufsetzen.

Bewusste und unbewusste Schulden

Der Softwareautor Martin Fowler unterscheidet technische Schulden danach, ob sie bewusst und ob sie umsichtig entstanden sind. Für Entscheider reicht eine einfache Fassung:

Die obere linke Zelle ist ein legitimes Werkzeug. Die rechte Spalte ist das, was Projekte ausbremst.

Beispiele und Warnzeichen für die Geschäftsführung

Technische Schulden sieht man nicht im Code, sondern im Alltag. Diese Anzeichen sollten aufhorchen lassen:

• Kleine Änderungen dauern Wochen. Ein neues Feld im Formular zieht Anpassungen an fünf Stellen nach sich.
• Angst vor Updates. Jede neue Version bringt Fehler an Stellen, die niemand angefasst hat.
• „Das darf nur Herr X anfassen.“ Ein einzelner Kopf hält das System zusammen.
• Sicherheitswarnungen werden ignoriert, weil das Update der Bibliothek zu viel kaputt machen würde.
• Entwickler schätzen immer höher, obwohl die Aufgaben nicht größer werden.

Ein typisches Beispiel aus dem Mittelstand: Eine Auftragsverwaltung wurde vor Jahren auf Basis einer Access-Datenbank gebaut und immer wieder erweitert. Sie funktioniert, aber niemand kann sie mehr an den Onlineshop anbinden, ohne den Rest zu gefährden. Aus technischen Schulden ist ein Legacy-System geworden.

Kosten und Risiken

Die Zinsen technischer Schulden zahlen Sie in drei Währungen:

• Zeit: Neue Funktionen kommen langsamer, das Team verbringt mehr Zeit mit Umgehungen als mit Fortschritt.
• Sicherheit: Veraltete Komponenten haben bekannte Lücken, die nicht geschlossen werden.
• Abhängigkeit: Wenn das Wissen an wenigen Personen hängt, ist jeder Wechsel im Team ein Betriebsrisiko.

Das Tückische: Die Zinsen steigen nicht linear. Lange geht es gut, dann kippt es, und selbst kleine Anpassungen werden zum Projekt.

Hinzu kommt ein Effekt, der in keiner Rechnung auftaucht: Gute Entwickler arbeiten ungern dauerhaft in einem System, das sie bei jeder Änderung ausbremst. Wer technische Schulden über Jahre liegen lässt, verliert oft genau die Menschen, die das System noch verstehen.

Technische Schulden abbauen

1. Sichtbar machen. Schulden gehören auf dieselbe Liste wie neue Funktionen, mit einer kurzen Beschreibung, was sie kosten.
2. Regelmäßig tilgen. Ein fester Anteil jeder Entwicklungsrunde geht in Aufräumen, Tests und Updates. Nicht als Sonderprojekt, sondern als Routine.
3. Tests zuerst. Bevor alter Code verbessert wird, sichern automatische Tests das heutige Verhalten ab.
4. Automatisieren. Mit CI/CD laufen Tests und Auslieferung bei jeder Änderung, Fehler fallen früh auf.
5. Schrittweise ersetzen statt neu schreiben. Der komplette Neubau klingt verlockend, ist aber das riskanteste Vorgehen. Besser: Teil für Teil ablösen, während das System weiterläuft.

In der Praxis: wie SEODACH unterstützt

Wir übernehmen Software mit Altlasten, auch solche, die wir nicht selbst gebaut haben. Zuerst prüfen wir, was das System heute tatsächlich leistet und wo die größten Risiken liegen. Danach bekommen Sie einen Fahrplan: was zuerst abgesichert wird, was sich schrittweise ablösen lässt und was bleiben kann. Der Betrieb läuft dabei weiter.

Wie das im Einzelnen aussieht, beschreibt die Seite Softwaremodernisierung und Legacy-Ablösung. Damit neue Schulden gar nicht erst entstehen, kümmern wir uns im laufenden Betrieb und in der Wartung um Updates, Tests und Sicherheitskorrekturen. Wann sich die Ablösung eines Altsystems lohnt, erklärt der Beitrag Legacy-Software ablösen.

Häufige Fragen

Was ist technical debt?

Technical debt ist der englische Begriff für technische Schulden: Abkürzungen im Code oder in der Architektur, die spätere Änderungen verteuern, so wie Zinsen auf einen Kredit.

Sind technische Schulden immer schlecht?

Nein. Eine bewusst aufgenommene, notierte und terminierte Schuld kann sinnvoll sein, etwa um schnell zu testen, ob eine Idee Kunden überzeugt. Schädlich wird sie, wenn sie vergessen wird.

Wie erkenne ich technische Schulden ohne Programmierkenntnisse?

An den Folgen: Änderungen dauern immer länger, Updates werden aufgeschoben, einzelne Personen sind unersetzlich, und nach jeder neuen Version tauchen Fehler an unerwarteten Stellen auf.