Keynesianismus und Austerität in der Softwareentwicklung

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

Dass technische Schulden eine Analogie aus dem Finanzwesen sind, mit deren Hilfe man die Folgen unterlassener Software-Modernisierung und -Instandhaltung beschreiben kann, dürfte zwar weitgehend bekannt sein, welche Ideen genau hinter dem Begriff stehen ist aber nur noch wenig bekannt. Eine nähere Beschäftigung damit wäre dabei durchaus lohnend, denn die Analogie geht weiter als man denken könnte - auch ein weiterer Ansatz der Haushaltsführung kann darin enthalten sein, der Keynesianismus.

Zur Auffrischung: von der Aufnahme technischer Schulden spricht man, wenn in der Software-Entwicklung schnelle Lösungen gesucht werden, die dann dadurch erreicht werden, dass eigentlich wichtige Dinge wie klare Architektur, das Einspielen von Updates oder Test-Absicherung auf später verschoben werden. Dadurch wird man kurzfristig schneller, dafür werden alle Weiterentwicklungen schwieriger. Diese Mehraufwände sind die "Zinsen", die zusätzlich zu den Schulden abzubezahlen sind.

Der in diesem Zusammenhang ebenfalls analogiefähige Haushaltsführungs-Ansatz des nach John Maynard Keynes benannten Keynesianismus (bzw. dessen Konjunkturtheorie) geht davon aus, dass es grundsätzlich sinnvoll sein kann Schulden aufzunehmen wenn Zeit- oder Ressourcenknappheit gegeben sind. Wenn diese Notlage mit dem durch Verschuldung gewonnenen Kapital bewältigt wurde kann die Rückzahlung stattfinden, so dass bis zur nächsten Notlage wieder die Schuldenfreiheit gegeben ist.

Auch auf die Softwareentwicklung kann der Keynesianismus angewendet werden. Um in Druckphasen (z.B. vor dem Weihnachtsgeschäft) schneller zu werden können eigentlich wichtige Aufgaben verschoben werden, sobald der Druck nachlässt finden Refactorings, Updates und nachträgliche Herbeiführung von Testabdeckung statt um die technischen Schulden zurückzuzahlen. Kurzfristige Handlungsfähigkeit wird so im wahrsten Sinn des Wortes erkauft.

Das Problem dabei: in der Realität funktioniert die keynesianistische Konjunkturtheorie nur extrem selten, sowohl in der Wirtschaft als auch in der Softwareentwicklung. Das Aufnehmen von (technischen) Schulden findet zwar statt, deren Rückzahlung in Entspannungsphasen aber nur eingeschränkt. Beim Eintreffen der nächsten Notlage besteht der Schuldenberg daher noch und wird jetzt weiter erhöht, mit dem Risiko eines (technischen) Bankrotts (Software die nicht mehr wartbar und weiterentwickelbar ist).

Die Alternative dazu besteht in einem anderen Haushaltsführungs-Ansatz: der Austerität. In ihm wird auf die Aufnahme von Schulden kategorisch verzichtet, selbst wenn das schrumpfende Haushalte zur Folge hat. Übertragen auf die Softwareentwicklung würde das bedeuten, dass auf die Aufnahme technischer Schulden auch dann verzichtet wird wenn dadurch gewünschte Funktionen erst verspätet oder deutlich verkleinert geliefert werden können.

Welcher der beiden Ansätze (Keynesianismus oder Austerität) von einer Softwareentwicklungs-Einheit gewählt werden sollte ist nicht klar zu sagen, je nach Kontext kann es sogar sinnvoll sein zwischen den beiden zu wechseln. Bei Teams die immer wieder falsch verstandenen Keynesianismus anwenden (Schulden aufnehmen aber nicht zurückzahlen) besteht aber irgendwann nur noch die Auswahl zwischen technischem Bankrott und Austerität.