Mit der Zeit steigt in jedem Softwareprojekt die Komplexität. Neue Features erfordern neue Strukturen und Bausteine, die Übersichtlichkeit nimmt zunehmend ab. Im schlimmsten Fall treten immer häufiger unerwünschte Seiteneffekte auf und die Zeitspanne für die Fertigstellung einzelner Funktionen wächst. Mit nicht zu geringer Wahrscheinlichkeit tritt der Worst-Case ein: Bei ansteigenden Kosten tangiert die Produktivität gen Null und die Weiterführung des Projekts wird zunehmend unwirtschaftlicher. Der US-amerikanische Informatiker Howard G. Cunningham etablierte bereits 1992 ein Konzept, welches darauf abzielt, genau diesen Umstand zu systematisieren: die technische Schuld.
Technische Schulden sind finanzielle Schulden
Cunningham zieht mit den technischen Schulden einen direkten Vergleich zu finanziellen Schulden. Als Beispiel dient ein Bankkredit. Auf diesen Kredit fallen regelmäßig Zinsen an, deren Höhe abhängig vom noch zu tilgendem Kreditbetrag ist. Dementsprechend mehrt sich die Kreditmenge und damit auch die absolute Menge der Zinsen mit fortschreitender Zeit exponentiell. Fallen beispielsweise nach dem ersten Monat auf einen Kredit über 100.000 Euro (bei einem Zinssatz von 5 Prozent) 5.000 Euro Zinsen an, sind im zweiten Monat bereits 5.250 Euro zu bezahlen. Es ist offensichtlich, dass die kumulierten Schulden irgendwann so enorm gestiegen sind, dass es dem Schuldner nicht möglich ist, sie zurückzuzahlen und es droht die Insolvenz. Optimalerweise tilgt der Kreditnehmer in regelmäßigen Abständen gewisse Anteile und behält damit die Kontrolle über die Situation.
Was Softwareentwicklung und Finanzkredite gemeinsam haben
Was hat das ganze aber nun mit Softwareprojekten zu tun? Laut Cunningham lässt sich der Entwicklungsprozess mit der Aufnahme eines Kredits vergleichen, bei welchem die Kosten nicht in monetärer Form anfallen, sondern in Form von Komplexität. Dieser Vergleich scheint auf den ersten Blick nicht stimmig, lässt sich aber bei genauerer Betrachtung gut übertragen. Mit dem Start und der Planung eines jeden Softwareprojekts wird ein gewisser Kredit an Komplexität aufgenommen. Alle weiteren Features, welche entwickelt und ergänzt werden, erhöhen die Komplexität, sind also quasi zu zahlende Zinsen.
Auch hier kumulieren sich die Schulden exponentiell, denn Features, welche auf komplexen Bausteinen basieren oder diese nutzen, tragen immer weiter zur Zunahme der Komplexität bei. Dieses Verhalten ist auch vollständig erwünscht. Gleichermaßen wie bei einem finanziellen Kredit, ermöglicht uns erst die Aufnahme von Schulden, unser Vorhaben umzusetzen. Es entstehen jedoch mit der Zeit die allseits bekannten Probleme von unerwünschten Seiteneffekten und steigenden Entwicklungskosten bei abnehmender Produktivität. In Reinform zu betrachten ist dies beispielsweise an Code-Blöcken, von denen niemand so genau weiß, was sie machen, das Löschen dieser Blöcke aber zu massiven Fehlern im System führt.
Ähnlich wie bei finanziellen Krediten droht auch bei Softwareprojekten im schlimmsten Fall die technische Insolvenz: Die Weiterführung des Projekts ist so unwirtschaftlich, dass es vollständig abgebrochen wird. Außerdem sorgt die zunehmend kritische Situation zum Verlust der Motivation bei allen Projektbeteiligten, das Gefühl des Kontrollverlusts verbreitet sich. Damit es nicht dazu kommt, müssen technische Schulden abgebaut werden, das heißt die Komplexität muss gemindert werden. Das entspricht der Tilgung eines Kredits.
Wie technische Schulden abgebaut werden
Um die Komplexität in einem Softwareprojekt zu mindern, gibt es viele Methoden. Bereits zu Beginn sollten die besonders kritischen Bausteine eines Systems gut geplant werden. Dabei muss nicht jede Einzelheit im Detail klar sein, lediglich grundlegende Aspekte, wie beispielsweise eine wohldefinierte Schnittstelle für weitere Bausteine, genügen. Die Orientierung an bereits erprobten Architekturmustern und Designprinzipien (an dieser Stelle seien die SOLID-Prinzipien betont), unterstützt dabei maßgeblich. Nicht nur der Code an sich trägt zur Komplexität bei: Eine differenzierte Dokumentation der Architektur und aller wichtigen Entscheidungen trägt nachhaltig dazu bei, Verständnis für das System zu schaffen und damit Komplexität abzubauen.
Technische Schulden mindern mit Refactoring
Das wohl wichtigste Werkzeug zur Minderung der Schuld stellt jedoch das kontinuierliche Refactoring dar, bei dem regelmäßig einzelne Teile oder auch das gesamte System betrachtet werden, um Optimierungen vorzunehmen. Dabei kann man sich von der Faustregel „beim ersten Mal macht man es nie perfekt“ leiten lassen und alle noch nicht überarbeiteten Aspekte erneut betrachten und verbessern. Wird beispielsweise erkannt, dass gewisse Abläufe häufig in diversen Bausteinen wiederholt werden, bietet es sich an, diesen Ablauf zu extrahieren und ein querschnittliches Konzept oder einen gesonderten Baustein für dieses zu etablieren. Die allgemeine Komplexität und damit auch die Wahrscheinlichkeit für unerwünschtes Verhalten sind somit gesunken. Wichtig ist, dass die Refactorings tatsächlich regelmäßig und vorzugsweise häufig stattfinden, da sie umso simpler werden, je weniger Aspekte betrachtet werden müssen. Ist erstmal bewusst, dass steigende Komplexität im Prinzip nichts anderes als steigende Kosten sind, wird deutlich, dass Zeit und Ressourcen in Überarbeitungen gesteckt werden müssen. Zwar ist auf den ersten Blick, insbesondere für fachfremde Stakeholder, kein Mehrwert ersichtlich. Auf lange Sicht sind die anfallenden Kosten jedoch deutlich geringer als die potenzielle technische Insolvenz und der Projekterfolg bleibt erreichbar.