Drei Missverständnisse über technische Schulden

Unnötige Komplexität macht jedes neue Feature und jede Änderung ein wenig aufwendiger als sie sein müsste. Je höher die unnötige Komplexität, desto schwieriger ist es den Code zu verstehen, den Effekt von Änderungen abzuschätzen und den Code zu testen. All das verlangsamt die weitere Entwicklung.

In den folgenden Abschnitten gehen wir auf einige typische Missverständnisse, die uns immer wieder im Umgang mit technischen Schulden begegnen, ein.

“Wir haben keine technischen Schulden oder sonstige Probleme mit Altlasten.”

Unnötige Komplexität entsteht fast immer von ganz allein. Sei es durch Unwissenheit, die bewusste Inkaufnahme von ‘schlechtem Code’, um Features schnell liefern zu können, durch zu viele unnötige Features usw.

Zusätzlich ist Software Teil einer sich ständig verändernden Umgebung. Neue Technologien entstehen. Das Management wechselt und alte Vorgaben haben keinen Bestand mehr. Anforderungen ändern sich und ein Teil der Features wird nicht mehr benötigt. Die Liste ließe sich beliebig verlängern.

Selbst wenn man von Anfang bis Ende alles richtig gemacht hat, führen die Änderungen in der Umgebung zu technischen Schulden im Projekt. Jede Code-Basis verfällt mit der Zeit.

“Wir müssen alle technischen Schulden beseitigen”

Die Aussage ist natürlich übertrieben. Die Tendenz dazu findet man aber immer wieder. Daher die Frage: Müssen technische Schulden wirklich immer beseitigt werden?

Wenn man genauer hinschaut, sind nicht alle technischen Schulden gleich. Der Unterschied liegt dabei in der Auswirkung auf die tägliche Arbeit der Entwickler.

Technische Schulden, die das Team ständig behindern, Dinge dauerhaft kompliziert machen, immer wieder zu Fehlern führen, haben einen ganz anderen Stellenwert als solche, die an einer Stelle liegen, die weder gelesen noch angefasst wird. Die Realität liegt natürlich meist zwischen den Extremen. Dennoch kann ein Team in der Regel sehr gut abschätzen, was sie im Moment wirklich behindert und was nur gelegentlich stört.

Was ist aber so schlimm daran, immer alle technischen Schulden, auf die man stößt, beseitigen zu wollen?

Dafür gibt es mehrere Gründe:

1. Softwareentwicklung ist kein Selbstzweck. Unser Ziel ist es immer Wert für unsere Nutzer zu schaffen und - in den meisten Fällen - am Ende Geld zu verdienen. Sprich, auch bei technischen Schulden gilt es, das Gleichgewicht zwischen Kosten und Nutzen zu wahren.

2. Es ist unklar was noch kommt. Als Softwareentwickler arbeiten wir in einem Umfeld extremer Unsicherheit. Anforderungen ändern sich, eine neue Technologie kommt und so weiter. Es ist also unklar, ob zu dem Zeitpunkt, zu dem der Code das nächste Mal bearbeitet wird, die Änderungen von heute noch passend sind.

3. Inhärente und unnötige Komplexität sind nicht immer leicht zu unterscheiden. Gerade in Anwendungen die über mehrere Jahre entwickelt werden, steigt nicht nur die Komplexität des Codes sondern auch die der fachlichen Anforderungen. Oft ist es dann das Problem mit einem Refactoring des Codes allein nicht zu lösen. Solange die Anforderungen unnötig komplex sind, ist es schwer sie in guten Code zu übersetzen. In solchen Fällen ist es notwendig gemeinsam mit dem Produkt Management genau zu klären, welche der Anforderungen überhaupt noch relevant sind und was sich ggf. vereinfachen lässt.

Ich persönlich finde ein ausgewogenes Vorgehen am sinnvollsten, bei dem man sich auf die technischen Schulden konzentriert, die aktuell die tägliche Arbeit am meisten behindern und den Rest vorerst ruhen lässt. Damit stellt man sicher, dass die Änderungen einen direkten Nutzen bringen.

“Wir müssen unbedingt eine Technologie oder ein Framework ersetzen, sonst haben wir in 5 Jahren zu hohe technische Schulden.”

Das ist eine wirklich schwierige Situation. Technologien oder Frameworks auf denen ein System aufbaut zu ersetzen, gerade wenn die Entwicklung schon über einen längeren Zeitraum (da reicht oft schon ein halbes Jahr) läuft, ist wirklich schwierig, aufwendig und fehleranfällig. Das gilt insbesondere, wenn die Technologie eng mit dem Code verzahnt ist und viele Stellen angefasst oder neu geschrieben werden müssen.

Einer Tatsache sollte man sich an dieser Stelle bewusst sein: Was heute modern und State-of-the-Art ist, wird in 5 Jahren ebenfalls veraltet sein.

Die Frage ist also: Lohnen sich der Aufwand und das Risiko wirklich?

Sicherlich machen neue Technologien und Frameworks vieles besser und einfacher.

Aber schon Fred Brooks sagte: ‘There is no silver bullet’ - Eine neue Technologie und ein neues Framework können zwar ein paar Prozent mehr Effektivität bringen, sind aber KEIN Game Changer. Es wird keine 10x Beschleunigung in der Softwareentwicklung dadurch geben.

Vielmehr wird es eine lange und zähe Phase der Umstellung geben bis alles wieder wie zuvor läuft.

Ist es das wirklich wert? Es kommt auf die individuelle Situation an. Wichtig ist aus unserer Sicht vor allen Dingen sich vorher über den tatsächlichen Nutzen und die tatsächlichen Kosten bewusst zu werden. In vielen Fällen ist der Nutzen deutlich geringer als angenommen und die Kosten sind deutlich höher.

Technische Schulden sind für alle eine Herausforderung.

Wie es ein Kollege vor einiger Zeit so treffend formuliert hat:

Alles, was wir tun können ist, die technischen Schulden im Blick zu behalten, kontinuierlich an den wichtigsten zu arbeiten und ein gutes Gleichgewicht zwischen dem Abbau technischer Schulden und der Weiterentwicklung zu halten.