Technische Schulden

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

Quadrant Technischer Schulden
rücksichtslosumsichtig
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.“

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

Ü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 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 eigenen Branches (beispielsweise Featurebranches) führt zu erhöhten Zusammenführungsaufwänden und somit Technischen Schulden.
  • Hintenangestelltes Refactoring, wenn in Codeteilen, welche verbesserungswürdig 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

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

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]

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

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

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

Weblinks

Einzelnachweise

  1. ↑ Robert C. Martin: A Mess is not a Technical Debt. 22. September 2009, abgerufen am 30. März 2012 (englisch): „A mess is not a technical debt. A mess is just a mess. Technical debt decisions are made based on real project constraints. They are risky, but they can be beneficial. The decision to make a mess is never rational, is always based on laziness and unprofessionalism, and has no chance of paying of in the future. A mess is always a loss.“
  2. ↑ ursprüngliche Bedeutung des Begriffs Technische Schulden
  3. ↑ Martin Fowler: TechnicalDebtQuadrant. 14. Oktober 2009, abgerufen am 31. März 2012 (englisch): „So the useful distinction isn’t between debt or non-debt, but between prudent and reckless debt. .. Not just is there a difference between prudent and reckless debt, there’s also a difference between deliberate and inadvertent debt.“
  4. ↑ Meir Manny Lehman: On Understanding Laws, Evolution, and Conservation in the Large-Program Life Cycle. In: Journal of Systems and Software. Nr. 1, 1980, S. 213–221, doi:10.1016/0164-1212(79)90022-0 (englisch).
  5. ↑ Alistair Cockburn: Agile Software Development. Hrsg.: Pearson Education. Addison-Wesley, 2002, ISBN 0-201-69969-9, The Agile Software Development Manifesto, S. 222 (englisch).
  6. ↑ Ward Cunningham: The WyCash Portfolio Management System. In: OOPSLA '92 Experience Report. 26. März 1992, abgerufen am 30. März 2012.
  7. ↑ Joshua Kerievsky: Refactoring to Patterns. Addison-Wesley, München 2005, ISBN 3-8273-2503-X (englisch).
  8. ↑ Adam Thornhill, Markus Borg: Code Red: The business impact of code quality. A Quantitative Study of 39 Proprietary Production Codebases. In: Proceedings of International Conference on Technical Debt. arxiv:2203.04374 (englisch, 10 S.): “The resulting technical debt is estimated to waste up to 42 % of developers’ time. .. low quality code contains 15 times more defects than high quality code. Furthermore, resolving issues in low quality code takes on average 124 % more time in development. Finally, we report that issue resolutions in low quality code involve higher uncertainty manifested as 9 times longer maximum cycle times”
  9. ↑ Roger S. Pressman: Software Engineering. A Practitioner’s Approach. Hrsg.: Thomas Casson. Mc Graw Hill, 1982, ISBN 0-07-365578-3, 1.4, S. 14, Figur 1.3 (englisch).
  10. ↑ ao. Univ.-Prof. Dr. Horst Eidenberger: Software ohne Gewähr. Wann ist die Qualität von Computer-Software mangelhaft? In: Hauptverband der allgemein beeideten und gerichtlich zertifizierten Sachverständigen Österreichs (Hrsg.): Sachverständige. Band 1/2014. Wien 2014, S. 14–18 (gerichts-sv.at [PDF; abgerufen am 8. September 2020]): „Mängel im Quellcode hingegen schlummern als technische Schulden oft unbemerkt vor sich hin. Ihr böses Erwachen betreibt üblicherweise der mit der Zahlung säumige Kunde (Mahnklage).“
  11. ↑ Metric Definitions. Maintainability. SonarSource S.A, abgerufen am 16. Dezember 2021 (englisch): „Technical Debt (sqale_index): Effort to fix all Code Smells. The measure is stored in minutes in the database. An 8-hour day is assumed when values are shown in days.“