Technische Schuld

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

Technische Schuld oder Technische Schulden (engl. technical debt) ist eine in der Informatik gebräuchliche Metapher für die möglichen Konsequenzen schlechter technischer Umsetzung von Software. Unter der technischen Schuld versteht man den zusätzlichen Aufwand, den man für Änderungen und Erweiterungen an schlecht geschriebener Software im Vergleich zu gut geschriebener Software einplanen muss.

Der Begriff „Technische Schuld“ wird von Informatikern wie Ward Cunningham, Martin Fowler, Steve McConnell oder Robert C. Martin verwendet, um Managern und anderen Stakeholdern von Softwareprojekten klarzumachen, dass die Hintanstellung von Maßnahmen zur Sicherung und Erhöhung technischer Qualität die Softwareentwicklung nicht beschleunigt, sondern verlangsamt – je länger desto mehr.

Technische Schuld unterscheidet 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 ist.[1]

Beispiele[Bearbeiten]

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 waghalsigem Eingehen technischer Schuld. Kombiniert ergibt das vier Quadranten zur Einteilung Technischer Schuld:[2]

  überlegt versehentlich
umsichtig ursprüngliche Bedeutung des Begriffs Technische Schuld „Jetzt wissen wir, was wir hätten tun sollen.“
waghalsig „Wir haben keine Zeit für Design!“ „Was heißt Layering?“

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

Ursachen[Bearbeiten]

Üblicherweise verursacht eine Kombination der folgenden Faktoren Technische Schuld:

  • Fachlicher Druck, wenn der Auftraggeber auf die Projektbeteiligten Druck ausübt, neue Fachlichkeiten schnell und bevor technische Aufräumarbeiten abgeschlossen sind, geliefert zu bekommen.
  • Ungenügende qualitätssichernde Prozesse, wenn es in einem Projekt keine qualitätssichernden Prozesse gibt (oder diese nicht gelebt werden), welche die Technische Schuld laufend messen und Verbesserungsmaßnahmen einleiten.
  • Ungenügendes technisches Wissen, um technische Entscheidungen treffen zu können, welche die Technische Schuld 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 Technischer Schuld.
  • Hintangestelltes Refactoring, wenn in Codeteilen, welche verbesserungswürdig sind, weiter Fachlichkeiten umgesetzt werden, ohne davor die Verbesserungen umzusetzen. Je mehr diese notwendigen Refactorings verzögert werden, desto aufwändiger werden sie bzw. die Umsetzung von Fachlichkeiten.

Technische Schuld baut 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öht sich die technische Schuld 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[3]

Alistair Cockburn zeigt auf, dass das Aufnehmen von technischer Schuld einem der Grundwerte der agilen Softwareentwicklung, dem der aufrechterhaltbaren Geschwindigkeit widerspricht.[4]

Geschichte[Bearbeiten]

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 Schuld im Sinne von 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 Neuimplementierung 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 Schuld. Ganze Entwicklungseinrichtungen können unter der Schuldenlast einer unbereinigten Implementierung (egal ob objektorientiert oder nicht) zum Stillstand gebracht werden.“

Ward Cunningham[5]

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

Auswirkungen[Bearbeiten]

Technische Schuld hat 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 ansteigen[7]

Technische Schuld ist einer der wichtigsten Faktoren, warum in Softwareentwicklungsprojekten Meilensteine nicht oder nicht rechtzeitig erreicht werden. Man geht daher davon aus, dass es sinnvoll ist die technische Schuld laufend gering zu halten, um vorhersagbare Meilensteine und Releasezyklen zu erreichen.

Messung[Bearbeiten]

Es ist schwierig exakt zu berechnen, wie viel Aufwand betrieben werden muss, um die technische Schuld einer Software abzuarbeiten. Jede Änderung an der Software erhöht unweigerlich die technische Schuld um einen unbestimmten Anteil.

Es gibt Software, um basierend auf Qualitätsmetriken eine ungefähre Abschätzung für die technische Schuld zu errechnen. Beispielsweise kann SonarQube die technische Schuld in Geldeinheiten errechnen.[8]

Weblinks[Bearbeiten]

Einzelnachweise[Bearbeiten]

  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. 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.“
  3.  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.
  4.  Alistair Cockburn, Pearson Education (Hrsg.): Agile Software Development. Addison-Wesley, Juli 2002, ISBN 0-201-69969-9, The Agile Software Development Manifesto, S. 222.
  5. Ward Cunningham: The WyCash Portfolio Management System. In: OOPSLA '92 Experience Report. 26. März 1992, abgerufen am 30. März 2012.
  6.  Joshua Kerievsky: Refactoring to Patterns. Addison-Wesley, München 2005, ISBN 978-3-8273-2503-7.
  7.  Roger S. Pressman, Thomas Casson (Hrsg.): Software Engineering. A Practitioner's Approach. Mc Graw Hill, 1. Mai 1982, ISBN 0-07-365578-3, 1.4, S. 14 (Figur 1.3).
  8. [1]