Technische Schulden oder Technische Schuld () ist eine in der Informatik gebräuchliche Metapher für die möglichen Konsequenzen schlechter technischer Umsetzung von Software. Der Begriff wird von Informatikern verwendet, um Managern und anderen Stakeholdern von Softwareprojekten klarzumachen, dass das Aufschieben von Maßnahmen zur Sicherung und Erhöhung technischer Qualität die Softwareentwicklung nicht beschleunigt, sondern verlangsamt – je länger desto mehr.
Technische Schulden unterscheiden sich von Anti-Pattern insofern, als die Entscheidung, technische Schulden zu machen, auch bewusst und nach Abwägung der Vor- und Nachteile getroffen werden kann, während Anti-Pattern immer eine Folge von Faulheit und Unprofessionalität sind.
Beispiele + Quadrant Technischer Schulden rücksichtslos umsichtig bewusst „Wir haben keine Zeit für Design.“ „Wir müssen schnell liefern und kümmern uns später um die Konsequenzen.“ursprüngliche Bedeutung des Begriffs Technische Schulden versehentlich „Was ist eine Schichtenarchitektur?“ „Jetzt wissen wir, was wir hätten tun sollen.“
Martin Fowler unterscheidet folgende Arten von technischen Schulden: Diejenigen, die man bewusst aufgenommen hat, um beispielsweise einen Meilenstein zu erreichen, und diejenigen, die man unwissentlich eingegangen ist, beispielsweise weil das Team gängigen Designprinzipien nicht gefolgt ist. Darüber hinaus unterscheidet er zwischen umsichtigem und rücksichtslosem Eingehen technischer Schulden. Kombiniert ergibt das vier Quadranten zur Einteilung Technischer Schulden:
Üblicherweise werden in Softwareentwicklungsprojekten folgende Technische Schulden (umsichtig oder rücksichtslos, überlegt oder versehentlich) aufgenommen: Aufschieben oder Nicht-Aktualisierung technischer und fachlicher Softwaredokumentation Fehlende technische Infrastruktur wie Versionsverwaltung, Datensicherung, Build-Tools, Kontinuierliche Integration Aufschieben, Verzicht oder ungenügende Umsetzung automatisierter Modultests und Regressionstests Fehlende Coding Standards und Code Ownership Missachtung von TODO- oder FIXME- oder XXX-Hinweisen im Code Missachtung von Codewiederholungen und anderen Code-Smells Verwendung von Programmierungs-Anti-Pattern Missachtung von Compiler-Warnungen und Ergebnissen statischer Code-Analyse Versäumen der Korrektur von zu großem oder zu komplexen Code und Design Fehlerhafte Definition oder Umsetzung der Architektur durch enge Kopplung, Zirkelbezug der Komponenten oder das Fehlen geeigneter Schnittstellen und Fassaden
Ursachen Üblicherweise verursacht eine Kombination der folgenden Faktoren Technische Schulden: Fachlicher Druck, wenn der Auftraggeber auf die Projektbeteiligten Druck ausübt, neue Funktionalitäten schnell und bevor technische Aufräumarbeiten abgeschlossen sind geliefert zu bekommen. Dieser Druck könnte beispielsweise durch ein zeitnahes Produkt-Release erfolgen. Ungenügende qualitätssichernde Prozesse, wenn es in einem Projekt keine qualitätssichernden Prozesse gibt (oder diese nicht gelebt werden), welche die Technischen Schulden laufend messen und Verbesserungsmaßnahmen einleiten. Ungenügendes technisches Wissen, um technische Entscheidungen treffen zu können, welche die Technischen Schulden nicht erhöhen und im Optimalfall sogar reduzieren. Ungenügende Kommunikation der gewählten technischen Lösungen und ihrer Hintergründe. Die Kommunikation kann auf vielerlei Arten erfolgen, beispielsweise durch selbsterklärenden Code, Dokumentation, Diagramme, Videos etc. Parallele Entwicklung in verschiedenen Branches (beispielsweise Featurebranches) führt zu erhöhten Zusammenführungsaufwänden und somit Technischen Schulden. Hintangestelltes Refactoring, wenn in Codeteilen, welche verbesserungsbedürftig sind, weiter Funktionalitäten umgesetzt werden, ohne davor die Verbesserungen umzusetzen. Je mehr diese notwendigen Refactorings verzögert werden, desto aufwändiger werden sie bzw. die Umsetzung von Funktionalitäten. Schnelle Codeerzeugung durch KI-Assistenten ohne entsprechende Prüfung.
Technische Schulden bauen sich aber auch auf – wenn auch in geringerem Maße –, wenn keiner der oben genannten Faktoren zutrifft. Technische Fehler entstehen bei der Softwareentwicklung ebenso wie fachliche Fehler. Wenn ihnen nicht durch qualitätssichernde Maßnahmen entgegengewirkt wird, erhöhen sich die technischen Schulden unwillkürlich mit jeder Änderung und Erweiterung der Software.
Alistair Cockburn zeigt auf, dass das Aufnehmen von technischen Schulden einem der Grundwerte der agilen Softwareentwicklung, dem der aufrechterhaltbaren Geschwindigkeit, widerspricht.
KI-gestützte Softwareentwicklung Mit dem Einsatz von KI-Programmierassistenten und Coding-Agenten wird eine weitere Entstehungsweise technischer Schulden diskutiert. Klassisch entstehen technische Schulden häufig unter Zeitdruck, etwa wenn Stakeholder eine schnelle Auslieferung von Funktionen einfordern. Bei KI-gestützter Entwicklung sinkt dagegen der Aufwand für das Erzeugen von Quellcode selbst erheblich. Technische Schulden können dann auch entstehen, wenn generierter Code übernommen wird, ohne dass er ausreichend geprüft, verstanden oder in die bestehende Architektur eingepasst wurde, und wenn mehr Code entsteht, als ein Team langfristig warten kann. Eine Untersuchung von rund 300.000 nachweislich von KI-Assistenten verfassten Commits in über 6.000 GitHub-Repositories fand in mehr als 15 % der Commits jedes untersuchten Assistenten mindestens ein durch statische Analyse erkennbares Problem, überwiegend Code-Smells; knapp ein Viertel der nachverfolgten Probleme bestand in der jeweils neuesten Version der Repositories fort.
Auswertungen des Code-Analyseanbieters GitClear zeigen seit der Verbreitung von KI-Assistenten einen höheren Anteil duplizierten Codes und einen geringeren Anteil an Refactoring; einen ursächlichen Zusammenhang weisen sie nicht nach. Der Accelerate State of DevOps Report 2024 des Google-Forschungsprogramms DORA fand einen Zusammenhang zwischen stärkerer KI-Nutzung und geringerer Stabilität der Softwareauslieferung und empfiehlt, an Grundsätzen wie kleinen Änderungspaketen und automatisierten Tests festzuhalten.
Geschichte Meir Manny Lehmans Gesetz zeigte als erstes 1980 auf, dass die Komplexität mit der Zeit wächst, es sei denn, man arbeitet dem entgegen. Ward Cunningham zog jedoch als erster Parallelen zwischen Komplexität einer Software und Schulden im Sinne von finanziellen Schulden:
In seinem Buch Refactoring to Patterns nannte Joshua Kerievsky 2004 die Kosten vernachlässigter Architektur Design debt.
Auswirkungen Im Schnitt wird in der Softwareentwicklung 23–42 % der Entwicklungszeit durch technische Schulden verschwendet. Code mit schlechter Qualität enthält 15 Mal mehr Fehler, diese zu beheben benötigt 124 % länger als bei Code mit guter Qualität.
Für die USA werden die Kosten der technischen Schulden 2022 auf 1,52 Billionen Dollar geschätzt, 33 % der Artbeitszeit eines typischen Entwicklers wird für technische Schulden verwendet.
Technische Schulden haben eine direkte Auswirkung auf die Wartbarkeit einer Software und somit auf den Aufwand für Wartung und Weiterentwicklung der Software. Üblicherweise rechnet man in der Softwareentwicklung damit, dass im Laufe eines Projektes der Aufwand für neue oder zu ändernde Funktionalitäten auf das 60- bis 100-fache ansteigt.
Technische Schulden sind einer der wichtigsten Faktoren, warum in Softwareentwicklungsprojekten Meilensteine nicht oder nicht rechtzeitig erreicht werden. Man geht daher davon aus, dass es sinnvoll ist, die technischen Schulden laufend gering zu halten, um vorhersagbare Meilensteine und Releasezyklen zu erreichen.
Technische Schulden können wie andere Qualitätsmängel auch zu Gewährleistungsklagen führen. Stellt das Gericht beispielsweise mittels eines Gerichtsgutachters fest, dass die vorhandenen technischen Schulden nicht dem Stand der Technik entsprechen, also die Software mangelhaft ist, können diese Klagen zu Preisminderung führen.
Messung Es ist schwierig, exakt zu berechnen, wie viel Aufwand betrieben werden muss, um die technischen Schulden einer Software abzuarbeiten.
Es gibt Software, um basierend auf Qualitätsmetriken eine ungefähre Abschätzung für die technischen Schulden zu errechnen. Beispielsweise kann SonarQube den Aufwand für den Abbau der technischen Schulden errechnen.
Weblinks Ward explains debt metaphor – YouTube (video) von Ward Cunningham zur Entstehung des Begriffes Managing Technical Debt Webinar – Webinar von Steve McConnel über Technische Schulden und wie man damit umgehen kann
Einzelnachweise
Kategorie:Softwaretechnik Kategorie:Programmierung Kategorie:Vorgehensmodell (Software)