Technische Schulden

Bild: Wikimedia Commons / r2hox - CC BY-SA 2.0

Schon seit einigen Jahren steht es auf meiner To Do-Liste, etwas über technische Schulden zu schreiben. Dieses Phänomen ist in praktisch jedem Softwareentwicklungs-Vorhaben vorhanden und es kann zu spürbaren Verzögerungen führen, bis hin zum totalen Stillstand, dadurch ist es auch eine der Hauptquellen für Frustration und Demotivation der Entwickler. Gleichzeitig ist es einem grossen Teil der oberen Management-Ebenen bis heute unbekannt, was viele Fehlplanungen in IT-Projekten erklärt.

Entwickelt wurde der Begriff als bewusste Analogie zu den finanziellen Schulden. In beiden Fällen werden Verbindlichkeiten aufgenommen um kurzfristig handlungsfähiger zu werden, in beiden Fällen weiss man von Anfang an, dass man sie irgendwann zurückzahlen muss und in beiden Fällen ist es auch klar, dass die Rückzahlung um so teurer wird je später sie stattfindet, da für die gesamte Dauer der Verschuldung Zinsen fällig werden, die zusätzlich abzuzahlen sind.

Der Hintergrund dieser Analogie ist, dass ihr Erfinder, Ward Cunningham, sie sich auf einem Projekt einfallen liess auf dem Buchhaltungs-Software entwickelt wurde. Um für die Fachabteilungen die Probleme der IT nachvollziehbar zu machen wählte er für seine Erklärungen Begriffe die dort bekannt waren, darunter eben den der technischen Schulden. Durch einen Konferenz-Vortrag wurde der Begriff dann bekannt und fand auch branchenübergreifend Verwendung.

Zu Stande kommen technische Schulden dadurch, dass irgendwann in der Software-Entwicklung "schnelle Lösungen" gesucht werden, die dann dadurch erreicht werden, dass eigentlich wichtige Dinge weggelassen werden. Das kann eine verständliche Strukturierung und Formatierung des Code sein, eine Absicherung durch automatisierte Tests, das Integrieren neuer Software-Versionen, etc. Ohne sie wird zwar das kurzfristige Ziel erreichbar, dafür werden ab jetzt alle Weiterentwicklungen schwieriger.

Diese Schwierigkeiten können z.B. daraus bestehen, dass es ab jetzt unverhältnismässig viel Zeit erfordert den schlecht geschriebenen Bestands-Code überhaupt zu verstehen, dass Fehler aufgrund der fehlenden Tests zu spät gefunden werden (und schlimmstenfalls bereits neue Funktionen auf ihnen aufbauen, die dann auch überarbeitet werden müssen) oder daraus, dass veraltete Software-Versionen ständige Probleme mit Stabilität, Kompatibilität oder Regel-Konformität haben.

Wichtig ist dabei eine Abgrenzung: es handelt sich nicht bei nicht jeder qualitativ schlechten Software um technische Schulden, der Begriff ist nur dann angemessen wenn sie bewusst "aufgenommen" wurden. Und genau wie bei finanziellen Schulden kann es auch bei technischen Schulden sinnvoll sein sie aufzunehmen, etwa um vor der Konkurrenz am Markt zu sein. Problematisch werden sie vor allem dann wenn die Rückzahlung immer wieder verzögert wird.

Nicht abgebaute technische Schulden türmen sich mit der Zeit auf, sorgen dafür, dass selbst kleine Veränderungen einem immensen Umsetzungsaufwand mit sich bringen und erzeugen dadurch den Wunsch nach noch mehr "schnellen Lösungen", die dann zu noch mehr technischen Schulden führen. Dreht dieser Kreislauf sich zu lange kann es zu "technischem Bankrott" kommen, einer Situation in der Weiterentwicklung und schlimmstenfalls sogar Betrieb der Systeme nicht mehr möglich sind.

Um es dazu nicht kommen zu lassen empfiehlt sich ein konsequenter Abbau der technischen Schulden, und auch der lässt sich mit Finanz-Analogien erklären. Beide Schuldenberge verschwinden nicht über Nacht sondern nur nach und nach, bei beiden sollte man für den Abbau einen spürbaren Teil der verfügbaren Mittel einplanen und bei beiden sollte man die Schulden mit den besonders hohen Zinsen zuerst angehen, die weniger kostenintensiven dagegen erst später abbauen.

Gegebenenfalls kann sogar eine "Umschuldung" sinnvoll sein, z.B. indem für einige Zeit auf ein Versions-Upgrade verzichtet wird um dafür die alte Version stabilisieren und durch Tests absichern zu können. Überlegungen wie diese zeigen auf, dass technische Schulden nicht per se schlecht sind. Es kann gute Gründe dafür geben sie aufzunehmen - man sollte sich nur der Konsequenzen bewusst sein.