Technische Schulden

Begriff und Grundidee

Technische Schulden oder technische Schuld (englisch „technical debt“) sind eine in der Informatik gebräuchliche Metapher für die möglichen Folgen einer schlechten technischen Umsetzung von Software. Gemeint ist vor allem, dass Maßnahmen zur Sicherung und Verbesserung der technischen Qualität aufgeschoben oder unzureichend umgesetzt werden. Das kann die Entwicklung kurzfristig scheinbar beschleunigen, verlangsamt sie aber langfristig zunehmend.

Der Begriff soll Managern und anderen Stakeholdern von Softwareprojekten verdeutlichen, dass technische Qualität später zusätzliche Arbeit verursacht. Wie bei finanziellen Schulden entstehen dabei sozusagen „Zinsen“: Jede weitere Änderung wird aufwendiger, solange frühere technische Probleme nicht behoben werden.

Technische Schulden unterscheiden sich von Anti-Patterns. Die Entscheidung, technische Schulden aufzunehmen, kann bewusst und nach Abwägung von Vor- und Nachteilen getroffen werden. Anti-Patterns werden im Artikel dagegen als Folgen von Faulheit und Unprofessionalität beschrieben.

Arten und typische Beispiele

Martin Fowler unterscheidet technische Schulden danach, ob sie bewusst oder versehentlich aufgenommen werden und ob dies umsichtig oder rücksichtslos geschieht. Daraus ergeben sich vier Quadranten:

• bewusst und rücksichtslos: „Wir haben keine Zeit für Design.“
• bewusst und umsichtig: „Wir müssen schnell liefern und kümmern uns später um die Konsequenzen.“
• versehentlich und rücksichtslos: „Was ist eine Schichtenarchitektur?“
• versehentlich und umsichtig: „Jetzt wissen wir, was wir hätten tun sollen.“

In Softwareentwicklungsprojekten entstehen technische Schulden beispielsweise durch:

• aufgeschobene oder nicht aktualisierte technische und fachliche Dokumentation;
• fehlende Infrastruktur wie Versionsverwaltung, Datensicherung, Build-Tools oder kontinuierliche Integration;
• fehlende, aufgeschobene oder unzureichende automatisierte Modul- und Regressionstests;
• fehlende Coding Standards und unklare Code Ownership;
• ignorierte TODO-, FIXME- oder XXX-Hinweise, Codewiederholungen und andere Code-Smells;
• die Verwendung von Programmierungs-Anti-Patterns;
• ignorierte Compiler-Warnungen und Ergebnisse statischer Code-Analyse;
• zu großer oder zu komplexer Code und ein entsprechend zu komplexes Design;
• fehlerhafte Architektur, etwa durch enge Kopplung, Zirkelbezüge zwischen Komponenten oder fehlende geeignete Schnittstellen und Fassaden.

Ursachen und Entstehung

Technische Schulden werden üblicherweise durch eine Kombination mehrerer Faktoren verursacht. Fachlicher Druck kann dazu führen, dass neue Funktionalitäten schnell geliefert werden müssen, bevor technische Aufräumarbeiten abgeschlossen sind, etwa wegen eines zeitnahen Produkt-Releases. Weitere Ursachen sind fehlende oder nicht angewendete qualitätssichernde Prozesse, ungenügendes technisches Wissen und eine unzureichende Kommunikation technischer Lösungen und ihrer Hintergründe. Diese Kommunikation kann beispielsweise durch selbsterklärenden Code, Dokumentation, Diagramme oder Videos erfolgen.

Auch die parallele Entwicklung in verschiedenen Branches, beispielsweise Featurebranches, kann durch zusätzlichen Zusammenführungsaufwand technische Schulden erzeugen. Werden notwendige Refactorings – also Verbesserungen an bestehenden Codeteilen – zurückgestellt, während dort weitere Funktionalitäten umgesetzt werden, steigt der spätere Aufwand für die Überarbeitung und die Weiterentwicklung.

Technische Schulden entstehen auch ohne diese besonderen Faktoren in geringerem Maße. Technische Fehler treten bei der Softwareentwicklung ebenso wie fachliche Fehler auf. Werden sie nicht durch qualitätssichernde Maßnahmen begrenzt, nehmen die technischen Schulden mit jeder Änderung und Erweiterung der Software unwillkürlich zu.

Meir Manny Lehmans „Gesetz II – Steigende Komplexität“ beschreibt: Während Software weiterentwickelt wird, steigt ihre Komplexität, es sei denn, es werden Anstrengungen unternommen, sie beizubehalten oder zu reduzieren. Alistair Cockburn weist darauf hin, dass das Aufnehmen technischer Schulden dem agilen Grundwert einer aufrechterhaltbaren Geschwindigkeit widerspricht.

Geschichtliche Entwicklung

Meir Manny Lehmans Gesetz zeigte bereits 1980, dass die Komplexität von Software mit der Zeit wächst, sofern nicht aktiv dagegen gearbeitet wird. Ward Cunningham zog als Erster Parallelen zwischen der Komplexität von Software und finanziellen Schulden. Er verglich das erstmalige Ausliefern von nicht ganz richtigem Code mit der Aufnahme von Schulden: Ein geringer Schuldenstand könne die Entwicklung beschleunigen, solange er durch eine rasche Überarbeitung zurückgezahlt werde. Bleibe die Rückzahlung aus, wirke jede weitere Arbeitsminute an dem fehlerhaften oder unbereinigten Code wie ein Zins. Unter dieser Schuldenlast könnten ganze Entwicklungsorganisationen zum Stillstand kommen.

Joshua Kerievsky bezeichnete 2004 in seinem Buch „Refactoring to Patterns“ die Kosten vernachlässigter Architektur als „Design debt“.

Auswirkungen und Messung

Technische Schulden beeinträchtigen unmittelbar die Wartbarkeit einer Software und erhöhen den Aufwand für Wartung und Weiterentwicklung. Im Durchschnitt werden in der Softwareentwicklung 23–42 % der Entwicklungszeit durch technische Schulden verschwendet. Code mit schlechter Qualität enthält 15 Mal mehr Fehler; deren Behebung benötigt 124 % länger als bei Code mit guter Qualität.

Für die USA wurden die Kosten technischer Schulden im Jahr 2022 auf 1,52 Billionen Dollar geschätzt. 33 % der Arbeitszeit eines typischen Entwicklers werden dort für technische Schulden verwendet. Im Verlauf eines Projekts steigt der Aufwand für neue oder zu ändernde Funktionalitäten üblicherweise auf das 60- bis 100-Fache an.

Technische Schulden gehören zu den wichtigsten Gründen dafür, dass Meilensteine in Softwareentwicklungsprojekten nicht oder nicht rechtzeitig erreicht werden. Deshalb gilt es als sinnvoll, sie laufend gering zu halten, damit Meilensteine und Releasezyklen besser vorhersehbar bleiben. Wie andere Qualitätsmängel können technische Schulden außerdem zu Gewährleistungsklagen führen. Stellt ein Gericht durch einen Gerichtsgutachter fest, dass sie nicht dem Stand der Technik entsprechen und die Software deshalb mangelhaft ist, können solche Klagen zu einer Preisminderung führen.

Eine exakte Berechnung des Aufwands für den Abbau technischer Schulden ist schwierig. Software kann anhand von Qualitätsmetriken eine ungefähre Schätzung liefern. Beispielsweise kann SonarQube den Aufwand für den Abbau technischer Schulden berechnen.