Technische Schulden – warum der Begriff mehr Verwirrung als Klarheit stiftet und wie es besser geht

Unter anderem bestand das Ziel darin, festzustellen, womit Entwickler ihre Zeit verbringen. Das Ergebnis zeigt, dass Entwickler im Durchschnitt ganze 42 Prozent ihrer Zeit mit der Wartung und Behebung von fehlerhaftem und suboptimalem Code verbringen, worunter auch die Beschäftigung mit Technischen Schulden fällt.

Im Umkehrschluss bedeutet dies, dass die Effizienz der Entwickler unter 60 Prozent liegt. Was der eigentlichen Hauptaufgabe von Entwicklern zuwiderläuft, nämlich neue Funktionalitäten zu entwickeln. Dieser Wert ist weit davon entfernt, was in der Branche gemeinhin als Ideal gilt: 80 Prozent Entwicklungsaufwand für neue Features. Denn klar ist auch, dass niemand eine Effizienz von 100 Prozent erwartet. Das wäre realitätsfern, da Wartung, Fehler und Technische Schulden unvermeidlich sind. Aber mit der richtigen Vorgehensweise sollten durchaus 80 Prozent an Entwicklungsaufwand für Features möglich sein.

Oftmals geschieht das Gegenteil und man macht sich das Leben unnötig schwer. Das heißt, man überlässt die Probleme sich selbst, bis sie überhand nehmen und dann einen viel größeren Mehraufwand verursachen, als nötig gewesen wäre, wenn man sie rechtzeitig und regelmäßig angegangen wäre. Unter anderem fällt darunter auch das sogenannte "Firefighting", wenn unter hohem Zeitdruck einem oder mehreren operativen Problemen bzw. Ausfällen schnellstmöglich auf den Grund gegangen werden muss. Und sich dabei die Ursachenforschung aufgrund der angesammelten Probleme als sehr schwierig erweist.

Im Prinzip ist diese Problematik wohlbekannt in der Branche und die Aussage von Brian Foote bringt es auf den Punkt: “If you think good architecture is expensive, try bad architecture!"

Obwohl es merkwürdigerweise fast alle intuitiv verstehen, gibt es immer noch Schwierigkeiten, diesen Gedanken, dass sich interne Qualität und die Arbeit daran immer lohnen, in echten Software-Projekten in die Tat umzusetzen. Daraus folgt natürlich die Frage, warum das so ist und wie man es besser machen könnte.

Wie sieht die Handhabung von Technischen Schulden in der Software-Entwicklung normalerweise aus? Wie man Abb. 2 entnehmen kann, stehen die Entwickler in der Mitte und müssen sich aktuell um alles gleichzeitig und selbst kümmern:

• Sie müssen sich als Hauptleidtragende regelmäßig mit Technischen Schulden befassen.
• Sie müssen sich um das Budget und die verfügbare Zeit dafür kümmern.
• Sie müssen Product Owner, Manager und andere Verantwortliche von der Notwendigkeit überzeugen, dass generell etwas gegen Technische Schulden getan werden muss und dass diese nicht eine bloße Laune der Entwickler sind, sondern ein Problem, das alle angeht.

Das Entwicklungsteam muss also ausgiebig über Technische Schulden sprechen, um letztendlich die Möglichkeit zu bekommen, sie zu adressieren. Einziges Problem dabei: Kein Mensch versteht sie! Zugegeben: Ganz so schlimm ist es nicht, für nichttechnische Kollegen und Verantwortliche gilt es aber sehr häufig [2]. Entsprechend dieses Befundes ist grundsätzlich festzustellen: Es gibt ernsthafte Probleme mit der Begrifflichkeit und mit der Nützlichkeit der Metapher der Technischen Schulden.

Sehen wir uns einige Möglichkeiten an, wie Technische Schulden diskutiert werden. Abb. 3 zeigt die Sicht von Philippe Kruchten [3]. Er unterteilt Aspekte, die bei der Entwicklung auftauchen, in gut und schlecht sowie sichtbar und unsichtbar. Features sind zum Beispiel klar positiv und sichtbar besetzt, während Fehler/Bugs in die Kategorien negativ und sichtbar einzuordnen sind. Architekturverbesserungen oder -erweiterungen sind im Gegensatz dazu nicht wirklich sichtbar, aber trotzdem als gut einzustufen, weil sie dazu führen, dass neue Features teilweise überhaupt und teilweise leichter implementiert werden können. Letztendlich gibt es noch Technische Schulden – unsichtbar und negativ assoziiert.

Die Eine-Million-Dollar-Frage ist, ob man mit solch einer Darstellung die Geldgeber tatsächlich überzeugen kann. Die Antwort ist wenig überraschend "Nein". Der Grund ist, dass Technische Schulden eben zu den unsichtbaren Phänomenen gehören, womit es unheimlich schwer wird, über sie zu verhandeln. Hinzu kommt, dass wir mit den ganzen technischen Begriffen (rechts im Bild) hantieren müssen, die dem Management nicht vertraut und unverständlich sind. Diese Unsichtbarkeit und Techniklastigkeit ist nur ein Problem. Es gibt aber noch einen anderen Grund, warum die Metapher der Technischen Schulden nicht so gut funktioniert, wie man es sich eigentlich wünschen würde. 

Die Schulden-Metapher suggeriert, dass Technische Schulden ähnlich den finanziellen Schulden sind. Und weil das vermeintlich so sei, lasse sich damit zwischen der Welt der Techniker und der Welt der Manager quasi eine Brücke schlagen. Daher versuchen wir nun, die Metapher beim Wort zu nehmen und ein Mapping zwischen finanziellen und Technischen Schulden herzustellen. Dabei nehmen wir in Abb. 4 auf der linken Seite Bezug auf den "Technical Debt Quadrant” von Martin Fowler [4] mit der Gegenüberstellung von "Reckless" versus "Prudent" und "Deliberate" versus "Inadvertent". Im Folgenden verwenden wir der Einfachheit halber die entsprechenden deutschen Übersetzungen dieser Begriffe. Rechts daneben versuchen wir nun einen analogen "Financial Debt Quadrant" aufzubauen und dem "Technical Debt Quadrant" gegenüberzustellen.

Zunächst zur kurzen Erinnerung: Was sind finanzielle Schulden? Die Verschuldung ist eine vertragliche Vereinbarung, die es dem Kreditnehmer ermöglicht, den zukünftigen Konsum in die Gegenwart zu verlagern.

Wenn man Technische Schulden eingeht, dann nimmt man einen gewissen Kredit auf (d. h. es wird suboptimaler Code produziert), damit man zum gegenwärtigen Zeitpunkt Features ausliefern kann.

Die Zinsen, die auf diesen suboptimalen Code anfallen, können unterschiedlichen Ursprungs sein. Wird dieser suboptimale Code in der Zwischenzeit für die Implementierung weiterer Features "mitverwendet", so kann eine nachträgliche Ausbesserung zum Mehraufwand führen, weil es mehr Abhängigkeiten gibt. Oder man bekommt es mit dem kognitiven Aufwand zu tun, welcher automatisch beim Verlust des Kontextes entsteht: Kehrt man nach längerer Zeit zu einer gewissen Codestelle zurück, so braucht es unvermeidlich einen zusätzlichen Mehraufwand, um das Problem erneut zu erfassen. Womöglich ist das ursprüngliche Verständnis auch unwiederbringlich verloren und die Fehlerwahrscheinlichkeit steigt.

Kommen wir aber zurück auf die Quadranten zu sprechen und vergleichen die jeweiligen Quadranten der Technischen und finanziellen Schulden im Einzelnen. Nach den Ausführungen oben sind die jeweils zweiten Quadranten oben rechts die eingängisten: "We must ship now and deal with the consequences" und "We need the house now and pay back the loan later". Das kommt auch gelegentlich in der Software-Entwicklung vor, wenn z. B. das Fenster zur Neukunden- oder -projektgewinnung zeitlich begrenzt offen ist und dafür neue Features nötig sind, die dem aktuellen Design teilweise widersprechen. Die eingegangenen Schulden müss(t)en nachfolgend beglichen werden.

Die Situation im ersten Quadranten links oben ("rücksichtslos und bewusst") stellt den sich daraufhin eventuell einstellenden Fall dar, dass dies zur Regel wird und die Software bis an das besagte Wartungslimit über 40 Prozent getrieben wird und die Probleme nicht mehr zu übersehen sind. Also sehr ähnlich zum finanziellen Fall "We charge the parents’ credit card until they notice" des entsprechenden finanziellen Quadranten. Man handelt also fahrlässig.

Die Situation "What’s layering" im dritten Quadranten links unten ("rücksichtslos und versehentlich") kann man als inkompetente Vorgehensweise bezeichnen. Das gleiche gilt für das finanzielle Pendant "We did not know that mobile internet abroad was so expensive". Das mag mittlerweile nicht mehr so oft auftreten, aber es sind auch Fälle bekannt geworden, dass die Kündigung temporär angemieteter, sehr leistungsfähiger, aber auch recht teurer Rechner in der Cloud über Wochen oder Monate mit hohen Folgekosten vergessen wurde.

Was den vierten Quadranten von Martin Fowler angeht, so ist ein Beispiel für versehentliche Schulden trotz vorausschauenden und besonnenen Handelns in der Finanzwelt in der Tat schwer vorstellbar. Das ist auch der Grund, warum die ganze Analogie nicht wirklich funktioniert. Dabei stellen die unbeabsichtigten Technischen Schulden eigentlich den häufigsten (und schädlichsten) Fall dar. Genau sie sind so spezifisch für die Software-Entwicklung, dass insbesondere diese mit der Metapher erklärbar werden sollten. Manchmal braucht es ein Jahr Entwicklungsarbeit, bis man wirklich merkt, wie das Design hätte sein sollen bzw. was man anders und besser machen würde, wenn man erneut starten würde. Dabei handelt es sich bei diesen Erkenntnissen um die unbeabsichtigten Technischen Schulden. Das bedeutet: Genau an der Stelle, wo die Analogie zu den finanziellen Schulden tragen soll, führt sie zur größeren Verwirrung bei nichttechnischen Verantwortlichen.

Wenn wir den Begriff "Technische Schulden" gegenüber nichttechnischen Geschäftskollegen verwenden, gehen sie davon aus, dass Technische Schulden mit finanziellen Schulden vergleichbar sind. In einer Diskussion merken sie aber recht schnell , dass es sich nicht um ein wirkliches Geldproblem handelt. So kommen sie zu dem Schluss, dass die Entwickler entweder nicht wissen, wovon sie reden, oder dass sie die falschen Begriffe verwenden – oder beides. Denn wie schnell würde der Finanzvorstand gefeuert werden, wenn er behauptet, "Wir haben eine Menge Schulden.", aber keine Bilanz mit Kreditgebern, Beträgen, Zinssätzen und Laufzeiten vorlegen kann? Den Unternehmensleitern ist es egal, ob die Arbeit schwierig oder lästig ist oder länger dauert als sie "sollte". Daher muss die Botschaft in Geschäftsergebnisse übersetzt werden, die einem IT-Leiter wichtig sind.