Technische Schulden

Die Metapher "Technische Schulden"

Als Folge von Entscheidungen im Entwicklungsprozess für eine schnelle oder günstige, statt einer effektiven Lösung verbleiben Unzulänglichkeiten in Code und Architektur. Für diese Unzulänglichkeiten hat sich in der Softwareentwicklung die Metapher Technische Schulden (engl. Technical Debt) eingebürgert. Diese Technische Schulden bewirken zusätzliche Aufwendungen für Nachbesserungen um unmittelbare, mittelbare oder auch zukünftige Probleme in der Weiterentwicklung der Software zu vermeiden.

Technische Schulden sind durch die Realitäten in der Softwareentwicklung (knappe Budgets, unterbesetzte Teams oder unrealistische Launchdates) in einem gewissen Umfang unvermeidbar. Werden diese jedoch im Rahmen der Wartungszyklen nicht zeitnah abgebaut, können sie die Weiterentwicklung der Software nach und nach erheblich beeinträchtigen. Statt der erhofften Beschleunigung der Entwicklung, wird die Weiterentwicklung der Software in seinem Life-Cycle immer langsamer und aufwändiger, bis hin zu nicht mehr sinnvoll. Die Metapher "Technische Schulden" weist richtigerweise auf diesen Zins und Zinseszins-Effekt hin.

Warum gibt es immer Technische Schulden in einer Software?

In der Softwareentwicklung ist die Zeitdauer bis zur Marktreife, die sogenannte „time to market“ ein wichtiger Wettbewerbsfaktor zur Gewinnung einer führenden Marktposition. Unternehmen bemühen sich stets, die Dauer dieser Produktentwicklung zu verkürzen, um somit die Software schneller am Markt zu platzieren. Als häufige Folge von Zeitdruck in der Entwicklung kann die Software erhöhte Technische Schulden enthalten.

Technische Schulden sind das Ergebnis der Priorisierung für einen schnelleren Beginn der Vermarktung statt für einen Fokus aud einen „perfekten“ Code. Sie sind die kummulative Summe aller während der Entwicklung aber auch in der Wartung getroffenen Designentscheidungen, die stets durch hohe Anfordungen, ein knappes Budget und Zeitdruck ein Kompromiss sind. Sie sind die Konsequenz, wenn eine heutige Zeitersparnis höher gewichtet wird als der zukünftige Aufwand zur nachträglichen Qualitätsverbesserung oder Weiterentwicklung der Software.

Für diese kurzfristige Einhaltung von Entwicklungsmeilensteine zahlt das Unternehmen aufgrund der wachsenden Technischen Schulden den Preis immer höherer Aufwendungen um die Software weiterzuentwickeln. Die Entwicklungsdauer wird damit mittelfristig nicht beschleunigt sondern sogar verlangsamt. Je nach Umfang und Komplexität der Technischen Schuld muss diese im Laufe der Softwareentwicklung mit immer höheren Kosten und Aufwände getilgt werden. Dies führt in der Folge zu längeren Entwicklungszyklen, schlimmstenfalls sogar zum Ende einer wirtschaftlich und technisch sinnvollen Produktweiterentwicklung.

Welche Arten von Technischen Schulden gibt es

Das Software Engineering Institute der Carnegie Mellon University hat 13 Arten von Technischen Schulden definiert. Nachfolgend sind die 13 Arten mit Bespielen aufgeführt.

Infolge technologischer Gründe:

• Architecture Debt – Durch eine Monolithische Architektur, den Verzicht auf Modularisierung oder Probleme bei der Umstellung auf Microservices
• Build Debt – Durch Verzicht auf Continuous Integration oder Continuous Delivery.
• Code Debt – Durch die Verletzung gängiger Prinzipien wie DRY oder KISS
• Defect Debt – Durch den Verzicht auf Bugfixes
• Design Debt – Durch die Verletzung von Design-Prinzipien was sich negativ auf die User Experience auswirkt
• Documentation Debt – Durch fehlende Coding and Documentation Guidelines wird das Nachvollziehen für Entwickler erschwert
• Test Debt – Durch üngenügende Testabdeckung oder eine zu geringe Codeüberdeckung
• Test Automation Debt – Durch Verzicht auf automatisierbare Unittests

• Infrastructure Debt – Bei Impediments wie fehlende Softwarelizenzen oder nicht funktionierende Hardware
• Service Debt – Durch die Bestimmung der Softwarestruktur basierend auf der Organisationsstruktur des Produzenten (Conway’s Law)
• Requirement Debt – Durch fehlerhaftes Backlog Refinement oder einen nicht definierten Systemkontext
• People Debt – Bei Mitarbeitenden die lernunwillig sind und sich ausserhalb des Teams stellen und sich nicht an Commitments wie eine Definition of Done halten
• Process Debt – Durch ungeeeignete, fehlende oder nicht angewendete Workflows und Methoden

Herausforderungen bei der Beseitigung von Technischen Schulden

Zunächst sollte die Technischen Schuld identifiziert und lokalisiert werden. Häufig werden sowohl Architecture Debts als auch Design Debts festgestellt. Dieses gleichzeitige Auftreten unterschiedlicher Schuldenarten macht das Lösungskonzept und den Abbau der Technischen Schuld oft aufwändig und komplex. Diese Aufwendungen werden häufig unterschätzt und sind damit auch nicht in den jährlichen Entwicklungsbudgets im notwendigen Umfang enthalten.

Dieses „Wegschauen“ bei der Budgetierung von Kapazitäten, um die absichtlich und unabsichtlich eingegangen Kompromisse in der Entwicklung der Software zu korrigieren, führt zu immer höheren Technische Schulden. Dennoch entscheiden sich viele R&D Führungskräfte, bei der Frage, ob sie Kapazitäten für den Abbau von Technische Schulden oder für ein neues Feature einsetzen sollen, meist für das neue Feature.

Wer nicht von Anfang an 10-15 % seiner Entwicklungskapazitäten für das Refactoring zum Abbau der Technischen Schulden einplant, dem gehen infolgedessen die Argumente aus, wenn die Geschäftsführung oder der Vertrieb den Einsatz aller Entwickler für neue Produkte fordert. Ein neuer Kunde ist wird nun mal meist höher bewertet, als ein Bestandskunde, der auf Updates wartet, die die Qualität der Software verbessert. An einem neuen Feature zu arbeiten, finden aber auch die Entwickler meist spannender, als einen vorhanden Code zu verbessern.

Die große Herausforderung im Entwicklungsalltag liegt also in der Priorisierung der Technischen Schulden, die das größte Problempotential haben. Damit würden dann die Prioritäten für die Verbesserungen in der Software (z.B. Refactoring) und der Entwicklungsprozesse festliegen.

Es ist unbedingt zu empfehlen, dass für jede Code Iteration ausreichend Kapazitäten für dafür eingeplant und reserviert werden. Damit bleiben die Technischen Schulden im unkritischen Bereich. Für den Kunden bedeutet das, dass regelmäßig neue Features zum genannten Launchdate zur Verfügung stehen und Bugs zeitnah verschwinden.

Was bewirken Technische Schulden im Unternehmen?

1. Problematische Technische Schulden können sich auf vielfache Art und Weise negativ in den Unternehmen auswirken: Die Fähigkeit zur Innovation wird beeinträchtigt. Die dafür notwendigen Entwickler Kapazitäten sind entweder mit dem Refactoring der problematischen Code-Passagen beschäftigt oder der Code selbst erfordert immer mehr Aufwand um z.B neue Features zu integrieren.
   
   
2. Aus den gleichen Gründen wird die Fähigkeit zeitnah auf Marktveränderungen zu reagieren beeinträchtigt. Das ist in einem Wettbewerbs- und Kundenumfeld, die sich zunehmend digitalisieren ein schwerwiegender Nachteil.
   
   
3. Die Zufriedenheit und Loyalität der Entwickler wird beeinträchtigt. Ständiges Reparieren an einem Legacy Code frustriert einen Entwickler. Diese beschäftigen sich lieber mit der Entwicklung neuer innovativer Features. Motivationsprobleme, Qualitätsprobleme und Fluktuation im Team sind die (teure) Folge.
   
   
4. Die Kunden bemerken die sinkende Performance, die späten Updates und die ausbleibenden oder zu späten Innovationen. Sie werden unzufrieden und suchen sich Alternativen, die diese Probleme nicht haben.
   
   
5. Die Kosten und der Aufwand für Wartung und Weiterentwicklung der Software steigen stetig an und sind kaum noch noch akkurat zu budgetieren.

Ist die Entscheidung pro Technische Schulden grundsätzlich schlecht?

Technische Schulden sind eine logische Folge einer agile Arbeitsweise. Sie sind nicht per se positiv oder negativ zu bewerten. Die Gründe die zu diesen Schulden geführt haben, sind entscheidend, ob es sich um eine sinnvolle oder um eine problematische "Aufnahme" von Schulden handelt. Ein guter Grund wäre z.B. um dadurch das Produkt schneller als ein Wettbewerber auf den Markt zu bringen. Werden diese Schulden aber nicht zeitnah abgebaut, werden auch diese Technische Schulden früher oder später zu problematische Schulden.

Sind in der Pandemie die Technischen Schulden angestiegen?

Eindeutig ja. Nach der Studie "The Software AG Situation Report - 2022" hat der durch die Pandemie erzeugte Druck auf eine beschleunigte Digitaliserung der Unternehmen auch das Niveau der Technischen Schulden ansteigen lassen. Fast 80 % der befragten Unternehmen gaben an, dass in 2021 die Technischen Schulden gestiegen sind. Die Hälfte davon gab sogar an, dass diese sogar wesentlich angestiegen seien. Bei den befragten Unternehmen gehört deshalb die Reduktion der Technischen Schulden neuerdings zu den Top 3 Prioritäten in der IT.