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