Softwaresysteme neigen dazu,
Müll anzusammeln - interne Fehler, die es schwierig machen, das System im Vergleich zum idealen Code weiter zu modifizieren und zu erweitern. Technische Schulden sind eine Metapher, die von Ward Cunningham erfunden wurde. Sie erklärt, wie man diesen Müll in Analogie zu einem Finanzdarlehen wahrnimmt. Zusätzliche Anstrengungen, die erforderlich sind, um neue Funktionen hinzuzufügen, sind Zinsen für das Darlehen.

Stellen Sie sich vor, in meiner Codebasis befindet sich ein Modul mit einer verwirrten Struktur. Müssen Sie eine neue Funktion hinzufügen. Wenn die Struktur klar wäre, würde die Arbeit vier Tage dauern, aber mit diesem Müll dauert es sechs Tage. Der Unterschied in zwei Tagen - das sind die Zinsen für die Schulden.
Was mich an der Schuldenmetapher am meisten anzieht, ist ein klares Verständnis der Kosten für die Wartung oder Beseitigung. Ich kann fünf Tage damit verbringen, die modulare Struktur zu reinigen, Müll zu entfernen und den „Kreditgeber“ metaphorisch zu bezahlen. Wenn ich dies für diese Funktion mache, verliere ich, weil ich neun statt sechs Tage verbringe. Wenn es jedoch zwei weitere solche Funktionen gibt, ist es rentabler, den Müll zu entfernen.
Mit dieser Formulierung wird die Aufgabe rein mathematisch. Jeder Manager mit einem elektronischen Tablet wird es lösen. Leider können wir
die Leistung nicht messen , sodass keine Kosten objektiv messbar sind. Wir können
grob abschätzen, wie lange es dauert, die Funktion zu entwickeln, wie lange es dauert, bis der Müll entfernt ist - und
die Kosten für das Entfernen übernehmen. Die Genauigkeit solcher Schätzungen ist jedoch eher gering.
Daher ist es normalerweise die beste Option, das zu tun, was wir normalerweise mit Finanzschulden tun: den Kapitalbetrag schrittweise zu zahlen. In der ersten Funktion werde ich ein paar zusätzliche Tage damit verbringen, einen Teil des Mülls zu entfernen. Dies kann ausreichen, um die Zinsen für die Schulden zu senken, damit sie in Zukunft an einem Tag zurückgezahlt werden können. Dies ist noch zusätzliche Zeit, aber mit der Beseitigung von Müll werden zukünftige Änderungen billiger. Der große Vorteil einer schrittweisen Verbesserung besteht darin, dass wir natürlich mehr Zeit damit verbringen, Müll in häufig wechselnden Bereichen zu entfernen. Dies sind genau die Bereiche der Codebasis, die am dringendsten entsorgt werden müssen.
Der Vergleich der Zinszahlungen mit der Zahlung der Hauptschuld hilft zu bestimmen, mit welcher Art von Müll umzugehen ist. Wenn ich einen besonders schrecklichen Bereich der Codebasis habe, verschwindet das Problem, wenn sich herausstellt, dass das Löschen von Müll nicht rentabel ist. Zinsen werden nur gezahlt, wenn Sie mit diesem Teil der Software arbeiten müssen (die Metapher ist an dieser Stelle etwas lahm, weil Sie immer einen Bankkredit bezahlen müssen). Somit können albtraumhafte, aber stabile Codebereiche in Ruhe gelassen werden.
Im Gegensatz zu den stabilen Teilen des Codes erfordern Bereiche mit hoher Aktivität keine Toleranz für Junk, da die Zinszahlungen dort extrem hoch sind. Dies ist besonders wichtig, da sich dort Müll ansammelt, wo Entwickler Änderungen vornehmen, ohne auf die Qualität zu achten: Je mehr Änderungen vorgenommen werden, desto größer ist das Müllrisiko.
Manchmal wird eine Schuldenmetapher verwendet, um einen Code mit schlechter Qualität zu rechtfertigen. Das Argument ist, dass Qualitätscode mehr Zeit und Mühe erfordert. Wenn Sie dringend neue Funktionen benötigen, ist es besser, die Schulden zu übernehmen und sie später zu bearbeiten
Hier besteht die Gefahr, dass diese Analyse häufig fehlerhaft ist. Müll kann sehr schnell Schaden anrichten und die Einführung neuer Funktionen verlangsamen. Infolgedessen überschreiten Entwickler die Kreditlimits und veröffentlichen das Produkt später, als wenn sie sofort Zeit für eine höhere Qualität aufwenden würden. Hier führt die Metapher oft Menschen in die Irre, weil die Dynamik der technischen Verschuldung nicht der Dynamik der Finanzkredite entspricht. Die Annahme, dass Schulden die Veröffentlichung des Produkts beschleunigen, funktioniert nur, wenn Sie in der
Hypothese der Nachhaltigkeit der Architektur unter der Auszahlungsgrenze für das Design bleiben und die Entwickler diese nach einigen Wochen und nicht nach Monaten überschreiten.

Es werden regelmäßig Debatten darüber geführt, ob verschiedene Arten von Müll als Schulden anzusehen sind. Es scheint mir sinnvoll, hier zu berücksichtigen, dass eine Pflicht bewusst und vernünftig - oder rücksichtslos - übernommen wird. So erschien ein
Quadrat technischer Schulden .
Weiterführende Literatur
Soweit ich das beurteilen kann, hat Ward dieses Konzept erstmals im
OOPSLA- Bericht von
1992 vorgestellt . Es wurde auch im
Wiki diskutiert.
Es gibt eine
Videoaufnahme, in der Ward Cunningham seine Metapher bespricht.
Dave Nicolette erweitert Wards Sicht auf technische Schulden, indem er ein
gutes Beispiel für das liefert, was ich als
vernünftige vorsätzliche Schulden bezeichne .
Mehrere Leser haben andere gültige Metaphern vorgeschlagen. David Panarity bezeichnete die Entwicklung von geringer Qualität
als Programmiermangel . Anscheinend begann er vor einigen Jahren, den Begriff zu verwenden, als er mit der Regierungspolitik vereinbar war. Ich denke jetzt ist es wieder relevant.
Scott Wood schlug vor, „
technische Inflation als Bodenverlust zu behandeln, wenn das derzeitige technologische Niveau Ihr Produktniveau so weit überschreitet, dass es allmählich aus der Umwelt herausfällt. Programme bleiben in Sprachversionen so weit zurück, dass der Code nicht mehr mit den Hauptcompilern kompatibel ist. "
Steve McConnell hob einige gute Punkte in der Metapher hervor. Insbesondere da eine Reduzierung der unbeabsichtigten Verschuldung mehr Raum lässt, um absichtlich Schulden anzunehmen, wenn dies hilfreich ist. Ich mag auch seine Formulierung von Mindestzahlungen (die zu hoch sind, um Probleme in eingebetteten Systemen zu beheben, aber nicht auf Websites).
Aaron Erickson sprach über die
Finanzierung von Enron .
Henrik Kniberg argumentiert, dass die alten technischen Schulden das größte Problem verursachen und dass es
ratsam ist, eine qualitativ hochwertige Schuldenobergrenze festzulegen, um die Verwaltung zu vereinfachen.
Eric Dietrich spricht über
menschliche Verluste aufgrund technischer Schulden : Teamkämpfe, Verschlechterung der Fähigkeiten und Burnout.
Bearbeitungen
Dieser Beitrag wurde ursprünglich am 1. Oktober 2003 veröffentlicht. Ich habe es im April 2019 komplett neu geschrieben.