Schuldentilgung

Technische Schulden à Pleitegeier?
 Adrian Korte

Nimmt man in einem Softwareprojekt Technische Schuld auf sich, so könnte man versucht sein diese ähnlich zu betrachten, wie private finanzielle Schulden. Doch im Gegensatz zu privaten Schulden gibt es keine Konten auf denen die Technische Schuld beziffert wird, keine halbwegs fixen Zinssätze, die bei Aufrechthaltung der Schulden zu zahlen sind, keine Umschuldungen oder Schuldentilgungspläne. Im Gegenteil: Das Ausmaß der Technischen Schuld ist meist unbekannt, gleichzeitig zahlt man dafür Wucherzinsen.


Wie in Schuldhafte Softwareentwicklung beschrieben geht man mit Technischer Schuld am besten so um, dass man sie von vornherein gar nicht entstehen lässt. Dies ist leicht möglich, wenn zu Beginn des Projektes umfassende und strikte Quality-Gates eingebaut werden, welche die Technische Schuld bereits im Keim ersticken. Doch in der Praxis wird zu Projektbeginn noch selten in technische Qualität investiert - "erste Resultate", "Zeigen was das Team so drauf hat", "Beweisen dass wir diesmal schneller sind", ... das sind leider zumeist die treibenden Faktoren zu Projektbeginn.

Schuldentilgung ist leider ein in der Softwareentwicklung kaum bekanntes Konzept. Die meisten Auftraggeber, Projektleiter, Analytiker etc. denken entweder blauäugig, dass in ihrem Projekt keine Technische Schuld aufgenommen wurde, oder dass Technische Schulden wie zinsenlose Kredite zu behandeln sind. Weit gefehlt: Es gibt kein Softwareentwicklungsprojekt ohne Technische Schuld und für Technische Schuld zahlt man Wucherzinsen.

Was also, wenn man erkennt, dass die Technische Schuld bereits Größenordnungen angenommen hat, dass die Produktivität merkbar darunter leidet bzw. Teilbereiche der Software als unwartbar gelten? Die wenigsten mir bekannten Projekte schaffen es ihre Technische Schuld zu tilgen. Der übliche Umgang mit Technischer Schuld ist "Ignorieren bis zum Konkurs": So lange unter Hochdruck weiterarbeiten (= weitere Technische Schuld aufnehmen), bis die Wartungs-und Weiterentwicklungsaufwände untragbar hoch geworden sind. Dann bleibt nichts anderes übrig, als die Software einzustampfen und (wenn das das Unternehmen überlebt) neu zu schreiben. Ca. 70% aller großen Softwareentwicklungsprojekte erleiden dieses Schicksal.

Was aber tun, wenn man bereits angefallene Technische Schuld tilgen möchte? Dafür sind folgende Schritte notwendig:

1. Bezifferung Technischer Schuld: Den wenigsten Projektleitern ist klar, wieviel Technische Schuld bisher aufgenommen wurde. Die einfachste (und eleganteste) Möglichkeit um die Technische Schuld zu beziffern ist der Einbau von Sonar in den Buildprozess und die Ermittlung der Technischen Schuld durch das Technical Debt Plugin. Zwar erkennt dieses Plugin nur einen Teil der Technischen Schuld (da es nur automatisch ermittelbare und auch davon nur wenige Metriken überprüft), meist ist der dabei errechnete Betrag aber hoch genug um Projektmanager erblassen zu lassen.
2. Laufende Bestandsaufnahme Technischer Schuld: Sonar liefert bereits in der Standardkonfiguration einen guten Überblick über die Technische Schuld eines Projektes. Diese Konfiguration gehört an das Projekt angepasst und Sonar um weitere Plugins zur Erkennung Technischer Schuld erweitert. Darüberhinaus muss den Entwicklern die Möglichkeit gegeben werden Technische Schuld, die nicht automatisiert durch Tools erkennbar ist, in Form von Tasks zu sammeln. Laufend, da sich die Technische Schuld ständig ändert und ständig neue Schulden an den Tag kommen.
3. Limbotanzen mit Technischer Schuld: Auf diese Technik möchte ich in meinem nächsten Blogpost näher eingehen. Im Prinzip geht es darum, Technische Schuld einzufrieren (die Limbo-Stange der Technischen Schuld darf nicht erhöht werden). Darüberhinaus ermöglicht diese Technik den sukzessiven Abbau Technischer Schulden ohne dafür Aufwände zu betreiben.
4. Sukzessive, geplante und controllte Reduktion Technischer Schuld: Iterative Definition einer Maßnahme zur Reduktion Technischer Schuld (z.B. Korrektur der Architekturverletzungen zwischen Komponente A und B durch Dependency Inversion), Abschätzung und Umsetzung dieser Maßnahme, Controlling des Erfolges dieser Maßnahme (z.B. Entfernung der Projektabhängigkeit zwischen A und B).

Die ersten drei Schritte sind am einfachsten und kostengünstigsten umzusetzen. Je nach vorliegendem Buildprozess, benötigen sie in Summe zwischen wenigen Personentagen und -wochen. Diese Schritte reichen bereits in den meisten Projekten aus, um die Technische Schuld in Summe nicht anwachsen zu lassen. Diese Maßnahmen amortisieren sich so schnell, dass dafür de facto kein Budget benötigt wird.

Der vierte Schritt ist der aufwändigste - je nach Maßnahme kann dadurch kurzfristig die Produktivität mehr oder weniger deutlich sinken. Dieser Schritt ist aber notwendig um die Technische Schuld deutlich zu senken, und damit langfristig die Produktivität zu steigern. Idealerweise wird diesem Schritt laufend ein Teil des Projektbudgets gewidmet - wieviel hängt von der im Schritt 1 errechneten Technischen Schuld ab.