Technische Schulden – aufgedeckt

Die Bedeutung und der Ursprung von „technischen Schulden“

Die Metapher der technischen Verschuldung (Technical Debt, TD) im Zusammenhang mit Software wurde von Ward Cunningham geprägt, der damals an der Codierung eines Finanzsystems arbeitete. Er nutzte die Metapher, um seinen Finanzkollegen die Gründe für das Refactoring und Umschreiben von Teilen des Codes zu erklären, wenn sich das Wissen über die Anforderungen weiterentwickelte.

„Wenn ein Entwicklungsteam Abkürzungen nimmt und Code liefert, der nicht ganz für die aktuelle Programmieraufgabe geeignet ist, entsteht TD. Diese Schulden verringern die Produktivität. Dieser Produktivitätsverlust liegt im Interesse des TD.“

Wards ursprünglich beabsichtigte Erklärung war ziemlich eng und spezifisch, aber die Metapher hat jetzt ein Eigenleben angenommen:

Heutzutage bedeutet technische Verschuldung mehrere Dinge:

• Code, der geändert werden muss, um problematische Verknüpfungen zu beseitigen, die erstellt wurden, bevor wir ein weiterentwickeltes Verständnis dafür entwickelt haben, was benötigt wird. (ursprüngliche Bedeutung).
• Code, der fehlerhaft ist.
• Mängel in Architektur und Design, die durch taktische Entscheidungen entstanden waren
• Code, der schwer zu warten ist
• Code, der von veralteten Bibliotheken, Betriebssystemen oder anderen technischen Komponenten abhängt
• Mängel in Anforderungen, die dadurch entstanden sind, dass Abkürzungen beim Verständnis der Anforderungen verwendet wurden.

Der Unterschied zwischen Tech Debt, Legacy und Software-Obsoleszenz:

Legacy-Systeme

Bei TD handelt es sich in der Regel um technische Abkürzungen, die zu Problemen führen. Veraltete Softwareanwendungen und Komponenten, die auf einer Technologie basieren, für die man sich heute nicht entscheiden würde, werden oft als solche eingestuft Legacy-Systeme. Zu der Zeit, als sie gebaut wurden, gab es möglicherweise noch keine Abkürzungen, daher gäbe es dort auch keine technischen Schulden. Oft wird ein Altsystem fälschlicherweise als Technologieschuld eingestuft, obwohl es in Wirklichkeit kurz vor der Veralterung steht. Wenn ein Legacy-System über geeignete Schnittstellen zu anderen Systemen verfügt und seine Kernaufgabe einwandfrei erfüllt, kann es zwar Legacy sein, aber weder TD noch veraltet sein. Wenn ein System dem Unternehmen nicht mehr dient, auch wenn dies eine Zeit lang der Fall war, betrachten wir dies als ein Problem veraltet System, nicht unbedingt TD.

Software-Obsoleszenz

Der Wert einer Software für ein Unternehmen nimmt mit der Zeit ab. Nach Jahren der Nutzung wird sich der wirtschaftliche Nutzen für die Wartung des alten Systems wahrscheinlich verringern. Die Anwendung hat eine lange Lebensdauer und letztendlich ist es wirtschaftlicher, sie außer Betrieb zu nehmen oder zu ersetzen, als sie weiterzuführen. Software wird veraltet, wenn die Betriebsumgebung, die sie ausführen muss, nicht mehr unterstützt wird (Hardware, Betriebssystem, Bibliotheken) oder wenn die Software selbst nicht mehr den Zweck erfüllt, für den sie benötigt wird.

Sobald eine neue Software geschrieben und bereitgestellt ist, ist es für Führungskräfte ratsam, für einige Jahre Upgrades einzuplanen und ihre eventuelle Stilllegung/Ersetzung zu planen. Die wirtschaftliche Lebensdauer einer Software variiert. Einige Arten von Software veralten bereits nach wenigen Jahren (viele Verbrauchersoftware), während andere möglicherweise erst nach Jahrzehnten veraltet sind (z. B. COBOL-Banking-Systeme oder Aufzeichnungssysteme im Allgemeinen). Obsoleszenz ist nicht dasselbe wie Tech-Schulden. Eine sehr zuverlässige Software kann veraltet sein und dennoch kein TD haben.

Die Kosten technischer Schulden

Um mit der Finanzmetapher fortzufahren, können wir sagen, dass der Zinssatz für diesen TD für einige Softwareanwendungen sehr hoch sein kann, während er für andere niedriger sein kann. Wenn die Kosten für das Unternehmen, das Problem nicht zu beheben, gering sind, ist der Zinssatz für den TD niedrig. Die Gesamtkosten von TD variieren je nach der Auswirkung auf den Geschäftsbetrieb und die Ausrichtung. Nehmen wir zum Beispiel ein Projekt, bei dem Abstriche bei der Anforderungsqualität gemacht werden. Die Konsequenz daraus ist, dass die Software neu geschrieben werden MUSS, bevor sie live geht. Dies ist eine dumme Erfindung von TD, die wahrscheinlich vermeidbar ist – und erklärt weitgehend, warum einige Softwareprojekte, die Anforderungen vernachlässigen, zu spät kommen oder scheitern. Für die Folgenabschätzung ist ein Einzelfallansatz erforderlich, für die Bemessung der Schulden kann jedoch ein allgemeinerer Ansatz in Betracht gezogen werden.

KOSMISCHE Dimensionierung der technischen Schulden

Der TDin-Code kann in CFP gemessen werden.

Wie der TD entsteht, kann auf schlechte Anforderungen, Architektur- und Designentscheidungen und Abkürzungen zurückzuführen sein. Dies führt dann zu Code, der entweder das Falsche tut oder es auf eine Art und Weise tut, die zu unangemessener Funktionalität führt.

Quantifizierung technischer Schulden

Dies sind die Fragen, die sich umsichtige Führungskräfte stellen sollten:

• Wie groß ist der TD?
• Wie hoch sind die Kosten, wenn wir das Problem nicht beheben?
• Wie hoch sind die Kosten, wenn wir das tun?

Für Unternehmen, die Hunderte von Anwendungen mit operativen und strategischen Daten ausführen, ist es hilfreich, die Antwort auf diese Fragen zu normalisieren, damit die Investitionen zur Bewältigung von TD priorisiert werden können.

Größe und Reparaturkosten

Die funktionale Größenbestimmung ist ein hervorragender Ansatz zur Standardisierung der Größenbestimmung von TD. Die Maßeinheit ist der KOSMISCHE Funktionspunkt oder Funktionspunkt. Beispielsweise hat die Anwendung eine Gesamtgröße von 1000 CFP, wovon 100 CFP Schnittstellen sind, die neu geschrieben werden müssen (TD). Die Kosten pro CFP oder die Kosten pro FP für das Ersetzen oder Umschreiben der Verknüpfung können normalerweise leicht anhand von Benchmark-Daten ermittelt werden. Die Reparaturkosten können zwischen $800 und $1500 pro CFP liegen. Die Verwendung eines universellen Größenansatzes bedeutet, dass er im gesamten TD in Code, Designs, Architektur und sogar Anforderungen angewendet werden kann. Es ist sehr wichtig, auch die Kosten der Migration vom Vorher- und Nachher-Zustand sowie alle nichttechnischen Auswirkungen, wie z. B. Personen- und Prozessänderungen, zu berücksichtigen.

Auswirkungen auf das Geschäft

Bei der Ermittlung der Gesamtkosten des TD müssen Sie sowohl die Auswirkungen auf Ihr Unternehmen als auch die Kosten für die Reparatur berücksichtigen. Der Einzelfallansatz für die Folgenabschätzung ist angemessen. Und dies kann in der Regel nur dadurch festgestellt werden, dass Fachleute aus der Wirtschaft und aus der Technik zusammenarbeiten, um die Frage zu beantworten: „Inwieweit hindern technische Abkürzungen das Unternehmen daran, seine Ziele zu erreichen?“

Technische Schulden aufdecken

Die Offenlegung von TD ist nützlich, da sie dazu beitragen kann, frühzeitig Informationen für strategische Entscheidungen über Softwaresysteme bereitzustellen. Beispielsweise kann ein System, das mit TD belastet ist, ein Kandidat für einen vorzeitigen Austausch sein. Eine andere Software mit eingeschränkter TD hingegen eignet sich möglicherweise besser zur Verlängerung ihrer Lebensdauer.

Erkennen Sie technische Schulden in Ihrem Unternehmen

Wenn eine Softwareanwendung aufgrund der Art und Weise, wie sie Daten speichert/verarbeitet/strukturiert, ständig als unflexibel beschrieben wird, dann ist dies möglicherweise TD, das Sie zurückhält. Mit anderen Worten: technische Abkürzungen oder schlechte Designentscheidungen, die nie geändert wurden, um den Anforderungen der Unternehmen gerecht zu werden.

Wenn bei einem Projekt zur Implementierung neuer Software oder Änderungen an der Software längere Zeiträume für die Fehlerbehebung oder Umgestaltung erforderlich sind, kann dies daran liegen Schlechte Arbeitsanforderungen, die zu technischen Schulden führten.

Technische Schulden vermeiden

Das ist der umsichtigste Ansatz überhaupt. Man geht davon aus, dass es am günstigsten ist, die Software gleich beim ersten Mal richtig zu entwickeln. Unter Berücksichtigung der ursprünglichen Definition des Begriffs durch Ward Cunningham ist dies jedoch nicht möglich. Wenn der (strategische) Bedarf und die Verwendung der Software beim ersten Schreiben des Codes nicht bekannt waren, war ein TD unvermeidlich. Es sollten jedoch alle Anstrengungen unternommen werden, um diese Überarbeitung auf ein Minimum zu beschränken. Der Ansatz hierfür besteht darin, ausreichend Zeit und Ressourcen einzuplanen, um die Anforderungen, Architektur und Designarbeit angemessen zu erledigen, bevor mit dem Codieren begonnen wird. Dadurch sollten die erkennbaren Unbekannten offengelegt werden, sodass die Entstehung und Beseitigung von TD vermieden wird.

Technische Schulden reduzieren

Es gibt zwei allgemeine Ansätze zur Reduzierung von TD:

1. Führen Sie die detaillierte Neufassung durch, um die problematische Abkürzung oder die Fehler zu beseitigen.

2. Überspringen Sie die Schulden. Führen Sie einen umfassenden Ersatz von TD durch geeigneten wiederverwendbaren Code durch. („Leapfrog the Legacy“, die Idee, das Erbe zu überspringen, ist nicht neu, obwohl ich diesen Ausdruck geprägt habe, weil ich denke, dass er auch Nicht-Technikern hilft, die Gründe für einige komplizierte technische Entscheidungen zu verstehen.)