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 gegenüber unbewusst und überlegt gegenüber 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, zusammen liefern sie aber 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.
Weiterführende Informationen
