AI tools

Technische Schulden

Metapher für mögliche Konsequenzen technisch schlecht umgesetzter Software Aus Wikipedia, der freien Enzyklopädie

Technische Schulden oder Technische Schuld (englisch technical debt) 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.[1]

Beispiele

Zusammenfassung
Kontext
Weitere Informationen rücksichtslos, umsichtig ...
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.“[2]
versehentlich „Was ist eine Schichtenarchitektur?“ „Jetzt wissen wir, was wir hätten tun sollen.“
Schließen

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:[3]

Üblicherweise werden in Softwareentwicklungsprojekten folgende Technische Schulden (umsichtig oder rücksichtslos, überlegt oder versehentlich) aufgenommen:

Ursachen

Zusammenfassung
Kontext

Ü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.

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.

“Law II – Increasing Complexity: As a program is evolved its complexity increases unless work is done to maintain or reduce it.”

„Gesetz II – Steigende Komplexität: Während Software weiterentwickelt wird, steigt ihre Komplexität, es sei denn, es werden Anstrengungen unternommen sie beizubehalten oder zu reduzieren.“

– Meir Manny Lehman: Proceedings of the IEEE[4]

Alistair Cockburn zeigt auf, dass das Aufnehmen von technischen Schulden einem der Grundwerte der agilen Softwareentwicklung, dem der aufrechterhaltbaren Geschwindigkeit, widerspricht.[5]

Geschichte

Zusammenfassung
Kontext

Meir Manny Lehmans Gesetz zeigte als erstes 1980 auf, dass die Komplexität mit der Zeit wächst, es sei denn, es werden Anstrengungen dagegen unternommen. Ward Cunningham zog jedoch als erster Parallelen zwischen Komplexität einer Software und Schulden im Sinne von finanziellen Schulden:

“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

„Software zu schreiben ist wie Schulden aufnehmen. Geringe Schulden aufzunehmen beschleunigt die Softwareentwicklung, solange die Schulden rasch durch eine Überarbeitung getilgt werden… Die Gefahr entsteht, wenn die Schulden nicht zurückgezahlt werden. Jede Minute, die man mit nicht ganz richtigem Code verbringt, zählt als Zins auf diese Schulden. Ganze Entwicklungseinrichtungen können unter der Schuldenlast einer unbereinigten Implementierung (egal ob objektorientiert oder nicht) zum Stillstand gebracht werden.“

– Ward Cunningham[6]

In seinem Buch Refactoring to Patterns nannte Joshua Kerievsky 2004 die Kosten vernachlässigter Architektur Design debt.[7]

Auswirkungen

Zusammenfassung
Kontext

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.[8]

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.[9]

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.[10]

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.[11]

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.[12]

Weblinks

Einzelnachweise

Wikiwand - on

Seamless Wikipedia browsing. On steroids.