Technische Schulden

Kompromisse wie Quick-and-Dirty-Lösungen, Hotfixes und Workarounds, die kurzfristig Zeit sparen, aber die innere Qualität einer Software verschlechtern. Mit der Zeit degenerieren Systeme dadurch: Änderungen werden riskant, teuer und langsam. Gegenmittel ist regelmässige „präventive Wartung“ durch Refactoring.

Systeme degenerieren

„Systeme degenerieren mit der Zeit“: Was gestern einfach war, ist durch Änderungen heute kompliziert geworden (Quelle - Effektive Softwarearchitekturen, S. 319). Am Anfang eines Projekts sieht alles ordentlich aus. Dann weicht die Ordnung dem Chaos, Ausnahmen werden zur Regel, und das Team spricht von „historisch gewachsen“ (S. 321).

Die Teams verlernen dabei nicht das saubere Arbeiten. Meist erzwingen äussere Einflüsse Kompromisse. Auftraggeber interessieren sich für neue Features und schnelle Fehlerbehebung, weniger für konzeptionelle Integrität und verständlichen Code. Gerade diese innere Qualität sichert aber niedrige Änderungskosten (S. 321–322).

Symptome

Nach dem Buch (S. 319–320):

• Die Teams verlieren den Überblick und können die Folgen von Änderungen nicht mehr abschätzen.
• Die Tests reichen nicht mehr, Änderungen haben unerkannte Nebenwirkungen (ripple effect).
• Fehler im Betrieb häufen sich, ihre Behebung frisst immer mehr Zeit.
• Qualitätsziele wie Performance, Sicherheit und Robustheit werden nicht mehr erreicht.
• Änderungs-, Wartungs- und Betriebskosten steigen; die time-to-market wird immer länger.

Ursachen

• übermässige strukturelle Komplexität, umständliche Abläufe und Konventionen;
• fehlende konzeptionelle Integrität: gleiche Probleme werden verschieden gelöst (Entwurfsprinzip);
• schlechter Code: hohe Kopplung, niedrige Kohäsion, unverständlich;
• unpassende Technologie: „mit Kanonen auf Spatzen schiessen“ oder Missbrauch, etwa eine Produktionsanlage mit Excel-Makros steuern;
• Probleme in Entwicklungs-, Betriebs- und Managementprozessen: lange Entscheidungswege, fehlende Kompetenz, Politik, am falschen Ende sparen (S. 320).

Das Fuhrpark-Argument

Speditionen warten ihre Lastwagen vorbeugend, auch wenn das Öl noch ein paar Kilometer reichen würde. Wer ein Jahr lang auf Ölwechsel verzichtet, spart kurzfristig. Dafür bleiben Fahrzeuge liegen, Kunden werden unzufrieden, der Umsatz sinkt. Starkes Rat: auch in die präventive Wartung von Software investieren, also regelmässig refaktorieren und aufräumen. Das Beispiel verstehe auch das Management; die Idee stammt aus dem Roman „The Phoenix Project“ (S. 321).

Was tun?

Die Welt lässt sich nicht anhalten, um aufzuräumen. Verbesserungen müssen in die normale Wartung eingebaut werden, in vielen kleinen Schritten. Wie das systematisch geht, beschreibt aim42. Refactoring braucht automatisierte Tests, ohne sie ist es riskant (Softwaretest). In arc42 gehören bekannte Schulden in Abschnitt 11 „Risiken“.

Herkunft des Begriffs

Das Buch nennt die Herkunft nicht. Den Begriff „technical debt“ prägte Ward Cunningham 1992 im Erfahrungsbericht über das WyCash-Portfoliosystem auf der Konferenz OOPSLA '92 (Quelle - Recherche - Softwarearchitektur heute 2026). Gemeint war ursprünglich Code, der noch nicht ganz richtig ist und dessen Korrektur man aufschiebt. Wie bei einem Kredit zahlt man Zinsen in Form von Mehraufwand bei jeder Änderung, bis die Schuld getilgt ist.

Verwandt

• aim42 – Methode zur systematischen Verbesserung
• Architekturbewertung – Schulden finden mit ATAM und Metriken
• Entwurfsprinzip – verfaultes Design und wie man es vermeidet
• Softwaretest – Voraussetzung für sicheres Refactoring
• Softwarearchitektur – Fokus auf Langlebigkeit