Technische Schulden

Je nach Höhe bzw. Größe der technischen Schuld muss diese im Laufe der Software- oder Produktentwicklung durch zusätzliche und höhere Aufwände getilgt werden. Lassen sich Produkte in der Folge nur schwer ändern, erweitern oder warten, führt dies möglicherweise “nur” zu längeren Entwicklungszyklen, schlimmstenfalls jedoch zum Ende einer Produktweiterentwicklung.

Die “Debt Metaphor” von Ward Cunningham

Die “Debt Metaphor” stammt von Ward Cunningham, einem der 17 Autoren des Agilen Manifests und dem Erfinder des Wiki-Systems². Im Zuge der Entwicklung eines Portfoliomanagement-Systems namens WyCash³ versuchte Cunningham, die Bedeutung von Refactorings zu betonen⁴:

“With borrowed money you can do something sooner than you might otherwise, but then until you pay back that money you’ll be paying interest. I thought borrowing money was a good idea, I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it”.

Aus dieser Metapher lassen sich einige Aspekte herauslesen:

• Es kann durchaus in Ordnung sein, Schulden zu machen, um schneller ein Ziel zu erreichen oder einen Vorteil zu realisieren, sofern sich die Beteiligten bewusst sind, dass Zinsen und Tilgung unabdingbar sind. Wer in der Folge seine Zinsen nicht regelmäßig bezahlt und seine Schulden nicht tilgt, wird irgendwann nicht mehr in der Lage sein, neue Funktionen zu realisieren. In anderen Worten: Refactoring ist wesentlich für die erfolgreiche Weiterentwicklung einer Software.
• Es ist erstrebenswert, Erfahrungen zu sammeln, die zur Optimierung einer Software genutzt werden. Die “Debt Metaphor” passt somit u.a. sehr gut zur iterativen, inkrementellen Entwicklung, zu Extreme Programming, zum agilen Mindset, zu Scrum oder zur Verwendung von Minimum Viable Products (MVP).
• Es ist wichtig, eine “technical debt balance” zwischen den Vorteilen und den technischen Schulden zu finden, wobei diese davon abhängt, ob Code so “clean” geschrieben wurde, dass er zu einem späteren Zeitpunkt einem Refactoring unterzogen werden kann. Clean Code Prinzipien und Praktiken helfen dabei, die Schulden zu minimieren.

Zu guter Letzt geht es Ward Cunningham nicht darum, “schlechten” Code zu implementieren, der zu einem späteren Zeitpunkt durch einen besseren Code ersetzt wird:

“You are wise to make that software reflect your understanding as best as you can, so that when it does come time to refactor, it’s clear what you were thinking when you wrote it, making it easier to refactor it into what your current thinking is now”. 

Code sollte also stets das aktuelle Verständnis repräsentieren, um ein Problem durch Software zu lösen. Und Code sollte durch Refactorings verbessert wenn, wenn neue Erkenntnisse bzw. ein besseres Verständnis gewonnen werden. Und das bedeutet: Technische Schulden werden nicht absichtlich aufgebaut, sondern sie entstehen im Zuge einer Entwicklung unwillkürlich! Übrigens auch durch technischen Fortschritt.

Verschiedene Perspektiven auf technische Schulden

Auch wenn “technical debt” bzw. “tech debt” auf Ward Cunningham zurückgeht, zahlreiche andere Softwareentwickler haben sich ebenfalls dazu geäußert.

• Robert C. Martin bestärkt die Perspektive von Cunningham und differenziert zwischen technischen Schulden und schlechtem, auf Faulheit oder Unprofessionalität basierenden Code, dessen Implementierung sich niemals auszahlen kann. “Tech Debt” ist also kein Anti-Pattern.⁵
• Shaun McCormick erachtet technische Schulden als positiv, notwendig und beabsichtigt, denn es ermöglicht Unternehmen ihre Produkte schnell und zum richtigen Zeitpunkt auf den Markt zu bringen und das sei wichtiger als eine hohe Codequalität.⁶
• Alistair Cockburn vertritt die Meinung, dass “technical debt” eine Entwicklung mit einer gleichbleibenden Geschwindigkeit gefährdet und somit die Bereitschaft zur Aufnahme von Schulden den Grundwerten der agilen Softwareentwicklung widerspricht.⁷
• Steve McConnell nimmt eine andere Position ein und unterscheidet zwischen beabsichtigten und unbeabsichtigten, sowie kurzfristigen und langfristigen Schulden. Unbeabsichtigt entstehen Schulden bspw. wenn unerfahrene Softwareentwickler unwissentlich schlechten Code schreiben. Unter “Long-Term Debt” versteht er strategische Entscheidungen wie bspw. die Wahl einer Plattform oder einer Datenbank, die zu zahlreichen Herausforderungen in der Zukunft führen.⁸
• Martin Fowler nutzt zusätzlich den Begriff “Cruft”. Cruft ist mittelmäßiger Code, der redundant, schlecht entworfen oder sogar unbrauchbar ist. Technische Schuld entspricht der Entwicklungsarbeit, die benötigt wird, um die Folgen der Implementierung von mittelmäßigem Code zu beseitigen. Seiner Meinung nach können Schulden bewusst (deliberate) oder unbeabsichtigt (indavertent) entstehen, wobei es einen Unterschied macht, ob sie umsichtig (prudent) oder rücksichtslos (reckless) gemacht werden. Diese Einordnung spiegelt sich in dem von ihm entworfenen “Technical Debt Quadrant” wider.⁹

Gründe für technische Schulden

Aus den genannten Perspektiven lassen sich zentrale Gründe für technische Schulden ablesen:

• die bewusste Entscheidung für eine “schnelle” Lösung bzw. Implementierung (Cunningham, Martin und McCormick),
• und die unbeabsichtigte Entstehung durch Cruft oder fehlendes Wissen in Verbindung mit rücksichtlosen Vorgehen, das keinen Wert auf Qualität legt (McConnell und Fowler).

Und welche Ursachen können zu “tech debt” führen? Unter anderem:

• fachlicher Druck,
• interne oder externe Deadlines,
• Erwartungen von Kunden bzw. vom Markt,
• Wettbewerb,
• ungenügende interne oder externe Kommunikation,
• fehlerhafte Aufwandsschätzung,
• mangelhafte Qualitäts- und Testprozesse,
• mangelndes Qualitätsbewusstsein der Entwickler,
• fehlende oder verschobene Refactorings,
• Unterscheidung zwischen interner und externer Softwarequalität,
• Verzicht auf Standards, Prinzipien oder etablierten Praktiken,
• Fokus auf andere Softwarekomponenten,
• mangelnde Fähigkeiten aus Fehlern zu lernen oder
• fehlendes Leadership und Ownership.

Die Liste lässt sich leicht verlängern, insbesondere wenn jedes Defizit einer Software als “Debt” klassifiziert wird.

Arten von technischen Schulden

Wie lassen sich technische Schulden klassifizieren, wenn sie nicht nur als Folge einer bewussten, strategischen Priorisierung bzw. Entscheidung verstanden werden? Das Software Engineering Institute der Carnegie Mellon University hat 13 Arten definiert:¹⁰

• Architecture Debt – bspw. durch die Entwicklung von Monolithen, den Verzicht auf Modularisierung oder Herausforderungen bei der Umstellung auf Microservices
• Build Debt – z.B. durch den Verzicht auf Continuous Integration oder Continuous Delivery.
• Code Debt – bspw. durch die Verletzung gängiger Prinzipien wie DRY oder KISS
• Defect Debt – z.B. durch den Verzicht auf Bugfixes
• Design Debt – bspw. durch die Verletzung von Design-Prinzipien mit negativen Auswirkungen auf die User Experience
• Documentation Debt – z.B. durch fehlende Coding and Documentation Guidelines
• Test Debt – z.B. durch mangelnde Testabdeckung oder eine zu geringe Codeüberdeckung
• Test Automation Debt – bspw. durch den Verzicht auf automatisierbare Unittests

Die folgenden Arten lassen sich zusätzlich auch als organisatorische Schulden einordnen:

• Infrastructure Debt – bspw. bei Impediments wie fehlende Softwarelizenzen oder nicht funktionierende Hardware
• Service Debt – bspw. durch die Bestimmung der Softwarestruktur basierend auf der Organisationsstruktur des Produzenten (Conway’s Law)
• Requirement Debt – z.B. durch fehlerhaftes Backlog Refinement oder einen nicht definierten Systemkontext
• People Debt – z.B. bei Mitarbeitenden, die nichts Neues lernen oder implementieren wollen, die sich nicht als Team wahrnehmen und sich nicht an Commitments wie eine Definition of Done gebunden fühlen
• Process Debt – bspw. durch fehlende Workflows oder die ungenügende Umsetzung von Vorgehensweisen

Sind Bugs technische Schulden?

Immer wieder gibt es in Organisationen Diskussionen darüber, ob Bugs technische Schulden sind. Ja, nein, vielleicht? Die Antwort hängt davon ab, welcher Interpretation Sie folgen:

• Bugs entstehen nicht absichtlich. Verstehen Sie technische Schulden als bewusste Entscheidung für eine Priorisierung in der Softwareentwicklung und folgen somit der Interpretation von Ward Cunningham, dann wäre die Antwort: nein.
• Verstehen Sie Bugs als Einschränkung der Funktionalität einer Software, implementiert durch mittelmäßigem Code und folgen somit der Interpretation von Steve McConnell und Martin Fowler, dann lautet die Antwort: ja.

Und wie lautet die Antwort, wenn ein Entwickler glaubt, ein Fehler würde nicht entdeckt und er müsste ihn daher nicht beheben? Oder wenn sich das Entwicklungsteam entscheidet, einen bekannten Bug nicht zu beheben? Möglicherweise lautet die Antwort dann: vielleicht.

Die Herausforderung bei der Beseitigung von Code Debt

Wie lässt sich Code Debt beseitigen? Natürlich gilt es als erstes die konkrete Schuld zu identifizieren und Möglichkeiten zur Beseitigung zu analysieren. Häufig gibt es Überschneidungen zu Architecture Debts oder Design Debts, so dass ein klein wirkendes Problem schnell zu einer großen Herausforderung wird. In der Folge müssen Lösungsansätze ermittelt, Aufwände geschätzt, die Implementierung gemeinsam mit Stakeholdern priorisiert, je nach Vorgehen geeignete Mitarbeiter allokiert und die Realisierung eingeplant werden. In anderen Worten: die Beseitigung von Code Debt lässt sich wie eine “normale Anforderung” handhaben. Die eigentliche Herausforderung bei der Beseitigung liegt aber an anderer Stelle.

In der Unternehmenspraxis wünschen sich Kunden und Anwender neue Funktionen. Die Beseitigung von Fehlern ist für sie selbstverständlich. Obwohl ihnen durchaus bewusst ist, dass Software quasi per Definition nicht fehlerfrei sein kann, wenn sie die Wahl zwischen neuem Feature und Beseitigung eines Problems haben, werden sie meist nach einem neuen Feature rufen; insbesondere dann, wenn sie selbst von dem Fehler nicht direkt betroffen sind. Ähnlich verhält es sich mit dem Vertrieb: der möchte mit neuen Features neue Kunden gewinnen. Auch für ihn ist die Beseitigung von Schulden selbstverständlich und selbst wenn er den Sinn und die Notwendigkeit eines Refactorings versteht, ein neuer Kunde ist für ihn oftmals wichtiger als ein Bestandskunde und die (interne) Qualität einer Software.

Die große Herausforderung liegt also in der Priorisierung der Beseitigung von Code Debts und damit in der Priorisierung von Refactorings.

Für die Einplanung und Durchführung von Refactorings gibt es grundsätzlich zwei Optionen:

• In jeder Iteration müssen aktiv Aufwand und konkrete Aufgaben eingeplant werden. Handelt es sich lediglich um einen fixierten Wert – bspw. 10 Prozent der Gesamtkapazität – wird dieser Zeitraum gerne als Puffer für andere Aufgaben missbraucht.
• Eine gesamte Iteration oder gar ein gesamtes Release wird für ein Refactoring genutzt. Kunden ist dies jedoch schwer zu vermitteln, vor allem wenn sie den Eindruck haben, die technische Schulden und die mangelhafte Beseitigung wären im wahrsten Sinne des Ausdrucks vom Hersteller selbstverschuldet.

Idealerweise versuchen Unternehmen reine Refactoring-Iterationen oder -Releases zu vermeiden. Für viele Organisationen ist es aber häufig jedoch die einzige Möglichkeit, da die technischen Schulden einen solchen Umfang eingenommen haben, dass eine sinnvolle Weiterentwicklung des Produkts nicht mehr möglich ist. Im übertragenen Sinne zahlen diese Organisation den Zinseszins für ihre Priorisierung.

Impulse zum Diskutieren:

• Technische Schulden sollten nicht vermieden, müssen aber gemanagt werden.
• Schuldenfreie Softwareentwicklung ist aufgrund des technischen Fortschritts nicht möglich.
• Technische Schulden erlöschen sobald ein Produkt nicht mehr weiterentwickelt wird – ist damit die Metapher fehlerhaft?
• Da sich die Höhe der Schulden nicht exakt berechnen lässt (und Aufwandsschätzungen oftmals ungenau sind), ist die Metapher “nett”, aber als Hilfsmittel für die Softwareentwicklung nur bedingt brauchbar.
• Wie sinnvoll ist die Betrachtung der “Cost of Delay” bei der Beurteilung der “tech debt”?

Hinweise:

Haben Sie Interesse an einem neuen Lieblings-Newsletter?

Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.

[1] Die Marktstellung als Aspekt eines Marktziels
[2] History of Wikis
[3] Die Entwicklung von WyCash
[4] Ward Cunningham: Debt Metaphor
[5] Robert C. Martin: A Mess is not a Technical Debt
[6] Shaun McCormick: Why the way we look at technical debt is wrong
[7] Alistair Cockburn: Agile Software Development
[8] Steve McConnell: Managing Technical Debt
[9] Martin Fowler: Technical Debt und Technical Debt Quadrant
[10] Carnegie Mellon University, Software Engineering Institute: Towards an Ontology of Terms on Technical Debt

Wenn Code Debt eine Art von Tech Debt ist, dann ist es falsch es synonym zu verwenden.

Und hier finden Sie ergänzende Informationen aus unserer Sektion Wissen kompakt:

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.