“Ceci n’est pas une pipe”
René Magritte
Hin und wieder geben aktuelle Diskussionen den Anstoß über gerne und häufig verwendete Begriffe einmal etwas genauer nachzudenken. Im diesem Fall über die Technischen Schulden. Was ist damit gemeint und wie ist mit ihnen umzugehen?
Der Begriff Technischen Schulden wurde von Ward Cunningham geprägt und eine gebräuchliche Definition lautet:
“Unter der technischen Schuld versteht man den zusätzlichen Aufwand, den man für Änderungen und Erweiterungen an schlecht geschriebener Software im Vergleich zu gut geschriebener Software einplanen muss.”
Wikipedia
Die deutsche Definition ist etwas unglücklich, da sie die Möglichkeit eröffnet, schlechte Qualität zu liefern unter dem Deckmantel Technische Schulden aufzunehmen. Deshalb besteht unter den Experten auch Uneinigkeit, was nun tatsächlich alles unter den Begriff Technische Schulden fallen sollte.
Martin Fowler differenziert zwischen vorsichtigen und rücksichtslosen Schulden und bewussten und unabsichtlichen Schulden. Vorsichtige Schulden sind absichtsvoll gewählte mindere Lösungen, die dann auch meist bewusst eingegangen werden. Rücksichtslose Schulden sind Entscheidungen, deren katastrophalen Konsequenzen schon im Vorfeld bekannt sein müssten. Unter unabsichtliche Schulden fasst Martin Fowler Entscheidungen zusammen, die entweder auf mangelnden technischen oder fachlichen Kenntnissen basieren.
Robert C. Martin geht strenger mit den Software Entwicklern ins Gericht. Für ihn gehören zu den Technischen Schulden nur die tatsächlich absichtsvoll gewählten minderen Lösungen.
“A Mess is not a Technical Debt“
Robert C. Martin
Die ursprüngliche Verwendung der Technische Schulden von Ward Cunningham beinhaltete auch nur die Abweichungen der Implementierung vom wachsenden fachlichen Verständnis der Entwickler. Dabei ging es ihm nie um Software minderer Qualität, sondern um hochwertige Software, der ein notwendiges Refactoring fehlt.
“A lot of bloggers at least have explained the debt metaphor and confused it, I think, with the idea that you could write code poorly with the intention of doing a good job later and thinking that that was the primary source of debt.”
Ward Cunningham
Letzten Endes sind Technische Schulden nur eine Metapher um Nicht-Entwicklern ein Problem der Software Entwicklung näher zu bringen. Das Problem entsteht aus den Gesetzen von Lehman, insbesondere dem Zweiten.
“Die Komplexität von sich entwickelnden Softwaresystemen entwickelt sich exponentiell zur Lebensdauer, zumindest solange dies nicht gewartet oder reduziert wird.”
Lehmans zweites Gesetz
Ein Softwaresystem wird immer über die Jahre komplexer und damit immer schwieriger zu warten und zu erweitern. Damit ein Team diese Komplexität beherrschen kann, muss die Software also immer wieder auf genau das zugeschnitten werden, was der aktuellen Intention der Entwickler entspricht.
Damit die Auftraggeber der damaligen Finanzsoftware die Hintergründe der Änderungen an der Software verstanden, nutzte Ward Cunningham daher eine Metapher aus der Finanzwelt. Unterlassene Änderungen an der Software sparen zwar augenscheinlich Geld, aber auf längerer Sicht zahlt der Auftraggeber drauf, weil die steigenden Folgekosten ein Äquivalent zu Zinseszinsen sind.
Wer mit Software Entwicklern häufiger diskutiert, kennt aber auch andere, weniger populäre Metaphern. Da gibt es das Beispiel des ungepflegten Gartens.
Ein Garten wurde neu angelegt und danach von niemanden gepflegt. Nach einigen Jahren ist alles zugewachsen, die Blumenbeete überwuchert und Unkraut wohin man schaut. Bevor der Garten wieder genutzt werden kann, muss also erst einmal das ganze Unkraut entfernt werden, neue Blumen angepflanzt und Bäume und Hecken geschnitten werden. Wer diese Mammutaufgabe umgehen möchte, ist also gut beraten, hin und wieder im Gartner nach dem Rechten zu sehen.
Welche Metapher auch gewählt wird, eines muss klar werden: Software ohne Pflege wird über die Zeit immer schlechter und je länger mit der Pflege gewartet wird, desto aufwändiger wird es, die Software von Mängeln zu befreien.
Damit die technischen Schulden nicht stetig anwachsen, müssen sie frühzeitig getilgt werden. Hilfreich ist es deshalb, bei dem Hinzufügen neuer Funktionalitäten nicht nur deren offensichtlichen Aufwände zu betrachten. Drei neue ähnliche Funktionen bedeuten nicht zwangsläufig den dreifachen Aufwand. Notwendige Refactorings können den Gesamtaufwand erhöhen aber auch reduzieren.
Auch müssen die Teams technische Exzellenz vorweisen und gut zusammenarbeiten können. Denn auch gute Teams erstellen keine fehlerfreie Software, aber es kommt seltener vor.
“Even the best teams create cruft”
Martin Fowler
Um am Ende dem großartigen Cartoonisten Martin Perscheid posthum zu huldigen “Muss ich jede Software pflegen? Nein! Nur die, die sie behalten wollen!”