Zahlen bitte! – Neue Studie zu Technical Debt

Technical Debt: Eine neue Studie von Besker, Martini und Bosch (2017) [1] befasst sich mit der Frage, wer in einem langlebigen Software-Projekt die Zeche für „Sünden der Vergangenheit“ zahlen muss. Die Studie mit dem Titel „The Pricey Bill of Technical Debt – When and by whom will it be paid?“, die im Rahmen der 33rd. International Conference on Software Maintenance and Evolution  vorgestellt wurde, ist mit diesem Zuschnitt und der Qualität der Analyse mittels quantitativer und qualitativer Methoden ein Novum.

Während Software-Wartung in der Praxis immer wieder ein kritisches Thema ist, führt es in Forschung und Lehre maximal ein Nischendasein oder wird sogar gänzlich ausgeklammert: Es gibt in meinen Augen ein Theorie-Defizit – und das wird in der Studie adressiert:

Aus den Einschätzungen der Befragten ergibt sich (mit wenig Streuung), dass etwa 36 Prozent der insgesamt investierten Entwicklungszeit für das Verstehen und Verwalten von Altlasten und „Abkürzungen“ der Vergangenheit aufgewendet werden müsse. Damit wären die technischen Schulden (Technical Debt) jedoch noch keineswegs bezahlt – das wären lediglich die Zinsen, um in der Schuldner-Metaphorik zu bleiben. Ein wahrer Zins-Schock, denn das hieße gleichzeitig, dass ein Drittel der Entwicklungsarbeit mit verbreiteten Methoden wie Scrum nicht steuerbar, sondern maximal anhand sinkender Velocity erkennbar wäre.

Technical Debt – Zentrale Schlussfolgerungen aus der Studie

• Das Alter der Systeme spielt keine einfach zu verstehende Rolle. Das ist meiner Meinung nach schon eine Überraschung. Erwähnt werden sollte jedoch, dass in der Datengrundlage der Studie ein großer Anteil „Embedded“-Entwicklung steckt. Es kann aber vermutet werden, dass typische Business-Anwendungen ähnlich oder schlechter dastehen, sofern sich ihre Anforderungen schneller ändern, als die von Embedded-Systemen, die wiederum oft durch die Hardware-Rahmenbindungen mit definiert sind.
  
  
• Komplizierte Architektur wird als stärkste Ursache für Technical Debt angegeben. Das wirft aber gleichzeitig die Frage auf, wie sich eine komplizierte Architektur eigentlich darstellt. Fachliche Komplexität und technische Komplexität mischen sich. Häufig ist nicht klar, ob die Befragten zum Beispiel eine Softwarelandschaft mit vielen Micro-Services (insbesondere in verschiedenen gleichzeitig aktiven Versionen, mit hohem Sicherheitsanspruch und mit anspruchsvoller Container-Infrastruktur), eine Umgebung mit vielen ausdifferenzierten Schichten oder andere Architektur-Muster als Teil der Lösung bewerten würden, oder als Teil des Problems.

Unabhängig davon ist es interessant zu sehen, dass hier im Durchschnitt jeweils mehr Zeit für das Finden, Verstehen und Verwalten von solchen Technical Debt Items benötigt wird, als für die Behebung der Probleme. Aus eigener Erfahrung kann ich sagen: Manche Debt Items müssen mehrfach gefunden werden, bevor man ihre Zusammenhänge und Bedeutungen erkennen kann.

Während die Frage „Wer zahlt?“ für den Einzelnen sicher entscheidend ist, ist sie in Zeiten von agiler Software-Entwicklung und verschwimmenden Rollenbildern schnell pauschal mit „das Team“ beantwortet und schwer weiter zu differenzieren. Die Studie zeigt auch auf, dass beispielsweise das Produktmanagement ebenfalls signifikant Zeit investiert. Dies ist konkret immer dann spürbar, wenn Machbarkeiten, Prioritäten und Zeitpläne zu verhandeln sind.

Die Diskussion zum Thema Technical Debt ist mit der Studie nicht abgeschlossen, aber sicher bereichert. Ich freue mich auf eine Fortsetzung. Auch Wartungs-Forschung braucht einen langen Atem.