Technische Schulden; sind sie nur technisch bedingt?

Die Metapher der technischen Schulden wurde 1992 auf der OOPSLA-Konferenz von Ward Cunningham eingeführt. Der Satz lautete:"Das erste Mal Code zu liefern ist wie Schulden machen. Eine kleine Schuld beschleunigt die Entwicklung, solange sie umgehend mit einem Rewrite zurückgezahlt wird...Die Gefahr besteht, wenn die Schulden nicht zurückgezahlt werden, denn Inkassofirmen wie Moorcroft werden Sie nur schwer wieder los. Jede Minute, die mit nicht ganz korrektem Code verbracht wird, zählt als Zinsen für diese Schuld. Ganze Engineering-Organisationen können unter der Schuldenlast einer unkonsolidierten Implementierung, ob objektorientiert oder nicht, zum Stillstand kommen." Das folgende Bild zeigt, wie dieser von Ward Cunningham beschriebene "Stillstand" erreicht wird.

https://theagileexecutive.com/2010/09/20/how-to-break-the-vicious-cycle-of-technical-debt/ In den meisten Diskussionen/Blogs im Internet werden die folgenden Ursachen genannt und die meisten haben mit Code zu tun:

• das Geschäft zwingt das Entwicklungsteam, Abkürzungen zu nehmen, um die gewünschte Funktionalität so schnell wie möglich zum Leben zu erwecken.
• das Entwicklungsteam dachte, sie müssten nicht entwerfen.
• das Entwicklungsteam war inkompetent und hat sich nicht die Mühe gemacht, einen wartbaren/änderbaren Code zu schreiben.
• das Entwicklungsteam erkennt später, z.B. bei der Einarbeitung einer Änderung, dass es in der Vergangenheit eine suboptimale Entscheidung getroffen hat (schwer zu vermeiden).

Martin Fowler hat dies in seinem Blog"TechnicalDebtQuadrant" sehr gut zusammengefasst. Er unterscheidet zwischen rücksichtslosem vs. rationalem Verhalten und bewussten vs. unbedachten/naiven Entscheidungen. Aber das ist immer noch hauptsächlich auf Code bezogen.

Aber wenn Sie sich die Formen der technischen Schulden im wirklichen Leben ansehen, werden Sie feststellen, dass diese nicht nur mit dem Code zusammenhängen. Technische Schulden können sich für uns in der folgenden Form manifestieren:

• Codeform (wie bereits erwähnt), z.B. Duplikation, hoher McCabe-Index, hohe Unit-Länge pro Methode, hohe Anzahl von Parametern in Methoden, falsche Kommentare, unklare Benennung von Objekten, Methoden, Variablen und Eigenschaften, etc.
• Architektonische Form, z.B. die Verletzung der Trennung von Belangen, die Entscheidung, kein Framework eines Drittanbieters zu verwenden, sondern ein eigenes zu erstellen, die Nichtänderung/Anpassung Ihrer Architektur an die (allmählichen oder abrupten) Veränderungen in der Welt um uns herum.
• Testform, z.B. die Entscheidung, keine automatischen Tests durchzuführen, weil das Testen des Systems von Hand zu komplex ist oder zu viel Zeit in Anspruch nimmt, um nach dem Testen zu dem Schluss zu kommen, dass alles in Ordnung ist.
• Form der Bereitstellung, z.B. wenn eine Bereitstellung so gestaltet ist, dass sie viel Zeit kostet und fehleranfällig ist, wodurch die Anzahl der Releases in einem bestimmten Zeitraum begrenzt wird.
• Dokumentationsform, d.h. es ist nicht bekannt, wie das System in bestimmten Situationen reagieren soll, weil es nicht funktional beschrieben ist. Dies macht die Erfüllung zukünftiger Funktionswünsche zeitaufwändig.
• Funktionale Form, z.B. durch Geschäftsanforderungen und durch das Entwicklungsteam erfundene Funktionalität, die nicht wirklich benötigt wird und die Dinge für die anstehende Änderung unnötig komplex macht .
• Projektform, z.B. die Verteilung von erfahrenen und unerfahrenen Mitarbeitern in Ihrem Team, das Gleiche gilt für die Fähigkeiten im Team, die Verteilung von Onsite-/Offshore-Teams, usw.
• Organisationsform, d.h. Sie fragen Ihren Software(anwendungs)anbieter nicht, welche Art von Qualitätssicherungspolitik er anwendet und ob er Qualitätszahlen auf der Grundlage eines ISO-Wartungsstandards vorlegen kann.

Alle diese Formen der technischen Schuld führen zu einer geringeren Änderbarkeit, zu höheren Kosten und zu Verzögerungen bei der Einführung neuer Funktionen. Alle Formen können auf dem TechnicalDebtQuadranten von Martin Fowler aufgetragen werden. Unabhängig davon, ob technische Schulden als absichtlich, versehentlich, rücksichtslos oder vorsichtig kategorisiert werden, ist es gut, sich dessen bewusst zu sein und zu sehen, wie Sie strategisch damit umgehen wollen. Schlussfolgerung Technische Schulden sind nicht nur technischer Natur und haben mehrere andere Formen als die des Codes. Die Metapher "technische Schuld" wurde erfunden, um das Problem der abnehmenden Produktivität im Lebenszyklus eines Softwareprodukts zu veranschaulichen. Mit der Metapher kann man sich leichter über das Problem verständigen, das sie anspricht. Auf diese Weise wurde das Konzept in der Entwicklergemeinschaft bekannt, während es in anderen oben genannten Bereichen leider weniger bekannt ist.Das Management, das mit der Metapher vertraut ist, kann sie als Vorteil nutzen, indem es strategische Entscheidungen in Bezug auf technische Schulden trifft, da es das Konzept der normalen Schulden versteht. Für strategische Entscheidungen sollte das Management jedoch wissen, wie hoch die technische Verschuldung derzeit ist (wie eine normale Verschuldung) und wie hoch die Wahrscheinlichkeit ist, dass eine technische Kreditklemme zu einem möglichen technischen Bankrott führt.... Ist technische Schuld also nur technisch bedingt. Nein, das ist sie nicht.