Technische Schulden
Was sind technische Schulden?
Der Begriff âTechnical Debtâ geht auf den amerikanischen Softwareentwickler Ward Cunningham zurĂŒck, der 1992 eine Analogie zur Finanzwelt zog: So wie ein Kredit kurzfristig Handlungsspielraum schafft, aber langfristig Zinsen kostet, schaffen Kompromisse im Code kurzfristig Geschwindigkeit â erzeugen aber langfristig Mehraufwand.
Technische Schulden bezeichnen den Zustand einer Codebasis, in dem vergangene Entscheidungen die aktuelle Arbeit verteuern. Das kann veralteter Code sein, der nie refaktorisiert wurde. Es können fehlende Tests sein, die jede Ănderung zum Risiko machen. Oder es ist eine Architektur, die fĂŒr zehn Benutzer entworfen wurde und jetzt tausend bedienen soll.
Der entscheidende Punkt: Technische Schulden sind nicht per se schlecht. Wie bei einem Kredit kommt es darauf an, ob man die Schulden bewusst aufnimmt, einen Plan fĂŒr die Tilgung hat und die Zinsen im Blick behĂ€lt. Problematisch wird es, wenn die Schulden unbemerkt wachsen und irgendwann jede Weiterentwicklung blockieren.
Wie technische Schulden entstehen
Es gibt selten den einen Moment, in dem ein Softwareprojekt âverschuldetâ. Technische Schulden akkumulieren sich ĂŒber Monate und Jahre â oft in kleinen, einzeln vertretbaren Entscheidungen, die in Summe eine Codebasis belasten.
Zeitdruck in der Entwicklung. Die hĂ€ufigste Ursache. Ein Feature muss bis Freitag fertig sein, also wird die saubere Lösung ĂŒbersprungen und eine schnelle Variante implementiert. Die Absicht, âdas spĂ€ter aufzurĂ€umenâ, wird selten eingelöst. Ăber mehrere Sprints hinweg summieren sich diese Kompromisse zu einer Codebasis, in der jede neue Funktion auf wackeligen Fundamenten steht.
Fehlende oder veraltete Dokumentation. Wenn kein Entwickler mehr erklĂ€ren kann, warum eine bestimmte Architekturentscheidung getroffen wurde, ist jede Ănderung an dieser Stelle ein Risiko. Undokumentierter Code ist nicht per se schlecht geschrieben â aber er ist teuer zu warten, weil die Einarbeitungszeit fĂŒr jeden Entwickler steigt.
Veraltete AbhĂ€ngigkeiten. Frameworks, Bibliotheken und Laufzeitumgebungen entwickeln sich weiter. Wer Updates aufschiebt, handelt sich nicht nur SicherheitslĂŒcken ein, sondern auch InkompatibilitĂ€ten, die mit jedem aufgeschobenen Update gröĂer werden. Ein Patch Management, das nicht systematisch betrieben wird, ist eine der verlĂ€sslichsten Quellen fĂŒr technische Schulden.
Wachstum ĂŒber die ursprĂŒngliche Architektur hinaus. Software, die fĂŒr einen Anwendungsfall konzipiert wurde und dann schrittweise erweitert wird, ohne die Architektur anzupassen, trĂ€gt strukturelle Schulden. Die Datenbank, die fĂŒr hundert DatensĂ€tze entworfen wurde, funktioniert â aber sie skaliert nicht. Das Berechtigungssystem, das zwei Rollen kannte, wird durch immer neue SonderfĂ€lle aufgeblĂ€ht.
Personalwechsel ohne Wissenstransfer. Wenn der Entwickler, der das System gebaut hat, das Unternehmen verlĂ€sst und niemand eingearbeitet wurde, entsteht eine besondere Form der Schuld: Das System funktioniert, aber niemand versteht es vollstĂ€ndig. Jede Ănderung wird zum Experiment.
Typen technischer Schulden
Martin Fowler hat 2009 eine Klassifikation vorgeschlagen, die bis heute nĂŒtzlich ist. Sie unterscheidet entlang zweier Achsen: bewusst vs. unbewusst und ĂŒberlegt vs. unĂŒberlegt.
Bewusst und ĂŒberlegt. Das Team weiĂ, dass es eine AbkĂŒrzung nimmt, und entscheidet sich trotzdem dafĂŒr â weil der Business Value einer schnellen Auslieferung die spĂ€teren Kosten rechtfertigt. Beispiel: Ein Prototyp wird ohne automatisierte Tests ausgeliefert, weil zuerst die Marktresonanz getestet werden soll. Die Schuld ist bekannt, der Tilgungsplan existiert.
Bewusst und unĂŒberlegt. Das Team nimmt AbkĂŒrzungen, obwohl es weiĂ, dass es bessere Lösungen gibt â ohne Plan, die Schulden zurĂŒckzuzahlen. Beispiel: Copy-Paste statt Refactoring, weil âdafĂŒr keine Zeit istâ. Diese Schulden wachsen schnell und unkontrolliert.
Unbewusst und ĂŒberlegt. Das Team trifft eine Entscheidung, die sich erst im Nachhinein als suboptimal herausstellt â etwa eine Architekturentscheidung, die bei den damaligen Anforderungen sinnvoll war, aber nicht mehr zur heutigen Nutzung passt. Diese Schulden sind normal und unvermeidbar.
Unbewusst und unĂŒberlegt. Das Team weiĂ schlicht nicht, dass es schlechte Entscheidungen trifft â etwa durch mangelnde Erfahrung mit dem eingesetzten Framework oder fehlende Kenntnis von Best Practices. Hier hilft nur Weiterbildung oder die Hinzunahme erfahrener Entwickler.
Wie man technische Schulden erkennt und misst
Technische Schulden sind nicht immer offensichtlich. Oft Ă€uĂern sie sich in Symptomen, die zunĂ€chst als normale KomplexitĂ€t wahrgenommen werden.
Steigende Entwicklungszeiten. Wenn jedes neue Feature ĂŒberproportional lĂ€nger dauert als vergleichbare Features in der Vergangenheit, deutet das auf wachsende Schulden hin. Die Ursache ist nicht mangelnde Kompetenz, sondern eine Codebasis, die jede Ănderung verteuert.
HĂ€ufige Regressionen. Wenn eine Fehlerbehebung an Stelle A regelmĂ€Ăig neue Fehler an Stelle B verursacht, ist das ein Zeichen fĂŒr enge Kopplung und fehlende Testabdeckung â beides typische Schuldensymptome.
Hohe Einarbeitungszeiten. Wenn neue Teammitglieder Wochen brauchen, um produktiv zu werden, liegt das oft nicht an der KomplexitÀt der DomÀne, sondern an einer Codebasis, die schwer zu verstehen ist.
FĂŒr die systematische Messung gibt es Werkzeuge: Statische Code-Analyse (SonarQube, CodeClimate) quantifiziert Code Smells, Duplikate und KomplexitĂ€tsmetriken. Dependency Scanner (Snyk, Dependabot) identifizieren veraltete AbhĂ€ngigkeiten. Testabdeckungstools messen, welcher Anteil des Codes durch automatisierte Tests abgesichert ist. Keines dieser Werkzeuge misst technische Schulden vollstĂ€ndig â aber zusammen liefern sie ein belastbares Bild.
Technische Schulden abbauen: Strategien
Der Abbau technischer Schulden erfordert keine Vollbremsung. Die wenigsten Unternehmen können es sich leisten, die Feature-Entwicklung fĂŒr ein halbes Jahr zu stoppen und den gesamten Code zu refaktorisieren. Stattdessen haben sich pragmatische AnsĂ€tze bewĂ€hrt.
Die Boy-Scout-Rule. âHinterlasse den Code besser, als du ihn vorgefunden hast.â Bei jeder Ănderung wird ein kleiner Teil der umgebenden Schulden getilgt. Das verlangsamt die aktuelle Aufgabe minimal, verhindert aber, dass die Schulden weiter wachsen.
Dedizierte Tech-Debt-Sprints. RegelmĂ€Ăig â etwa jeden dritten Sprint â wird ein Sprint oder ein Teil davon fĂŒr den gezielten Abbau technischer Schulden reserviert. Das schafft Planbarkeit und macht die Investition fĂŒr Stakeholder transparent.
Strangler-Fig-Pattern. Bei stark verschuldeten Legacy-Systemen wird nicht der gesamte Code auf einmal ersetzt, sondern Modul fĂŒr Modul durch neue Implementierungen abgelöst. Das alte System âschrumpftâ ĂŒber die Zeit, wĂ€hrend das neue System wĂ€chst. Dieser Ansatz ist eng verwandt mit der Software-Modernisierung.
Wartungsvertrag als struktureller Rahmen. FĂŒr Unternehmen, die ihre Software nicht selbst warten, ist ein Wartungsvertrag der verlĂ€sslichste Weg, technische Schulden systematisch zu adressieren. Ein guter Wartungsvertrag beinhaltet nicht nur Fehlerbehebung und Sicherheitsupdates, sondern auch regelmĂ€Ăige Architektur-Reviews und geplantes Refactoring. Die Details dazu beschreibt unser Leitfaden zum Wartungsvertrag fĂŒr Individualsoftware.
Technische Schulden und Sicherheit
Es gibt eine direkte Verbindung zwischen technischen Schulden und Sicherheitsrisiken. Veraltete AbhÀngigkeiten enthalten bekannte Schwachstellen. Fehlende Tests bedeuten, dass Sicherheits-Patches nicht zuverlÀssig validiert werden können. Undokumentierte Architektur erschwert Security Audits.
FĂŒr Unternehmen in regulierten Branchen â insbesondere KRITIS-Betreiber und Organisationen unter NIS-2-Pflichten â sind technische Schulden kein reines QualitĂ€tsthema. Sie sind ein Compliance-Risiko. Eine Codebasis, die nicht auditierbar ist, kann die gesetzlich geforderten Nachweise nicht liefern. Eine sichere Softwareentwicklung setzt voraus, dass die zugrunde liegende Codebasis beherrschbar bleibt.
