Als Software-Architekten balancieren wir ständig auf dem Grat der Entscheidungen. Und nur allzu oft bewahrheitet sich, dass die Software-Architektur die Summe teurer Entscheidungen ist: Technische Schulden geißeln uns. An etlichen Stellen wird bereits der Ruf laut, dass der Begriff der technischen Schuld überholt ist – der von Anfang an falsch war. Die Suche nach einer neuen Metapher hat begonnen, wohin sie führt, wird sich zeigen. Diese Keynote geht genau in die andere Richtung und zeigt, warum der Begriff der technischen Schuld genau ins Schwarze trifft. Es wird deutlich, dass eine Diskussion über die Zukunft von Software-Systemen mit Menschen, die keinen IT-Hintergrund haben, eine Brücke benötigt, die die Welten der Ökonomie und der IT zusammenführt. Abgerundet wird der Beitrag mit einer Methode zum Management technischer Schulden, die sich bereits in vielen agilen Projekten bewährt hat.

1. Technische Schulden
Gerrit Beine
adesso AG
Es ist mir eine große Freude, heute über technische Schulden sprechen zu dürfen.
Als ich die Zusage für den Vortrag erhielt, war ich einigermaßen überrascht, dass er als Keynote ausgewählt wurde.
Damit hatte ich nicht gerechnet.

2. Vorstellung
‣ Managing Consultant bei adesso
‣ Software Philosoph, nimmermüder Verbesserer,
Informatik-Vagabund
‣ Themen
‣ Agilität
‣ Software Architektur
‣ Antifragilität & Schwarze Schwäne
‣ Technical Debt & Legacy Code
‣ Software Engineering Economics
‣ Interkulturelle Aspekte von Software Engineering
‣ iSAQB e.V. Board Member, openSUSE Member,
Agile Saxony Organisator

3. Immer, wenn Menschen sich über die Zukunft
Gedanken machen, fällt im Hintergrund das
Schicksal lachend vom Stuhl.
Gleich vorab eine Weisheit, die das Thema technische Schulden sehr gut widerspiegelt.
Egal, wie gut wir unser Projekt planen, es kommt anders.

4. Ich werde heute unter anderem über diese beiden Herren sprechen.
Kennt die jemand?
Das oben ist Friedrich Hayek und das unten ist John Maynard Keynes.
Die beiden hatten sehr unterschiedliche Ansichten zum Thema Schulden, die auch für das Thema der technischen Schulden sehr interessant sind.
Und ich werde ein bisschen über die Gesetzeslage sprechen, die eine Ursache dafür ist, dass technische Schulden so wirken, wie sie derzeit wirken.
In dem Zusammenhang spreche ich dann auch noch über diese Kollegen. Lehman Brothers.
Vielleicht erinnert sich noch jemand an die, für alle anderen: deren Pleite war der Ursprung der Finanzkrise vor einigen Jahren.
Achja. Über Geld spreche ich auch noch. Auch wenn wir in der IT nur äußerst ungern über Geld sprechen.
Ganz zum Schluss erkläre ich dann noch zwei praktische Tools, die ein Management technischer Schulden erlauben.

5. Technische Schulden
Brauchen wir wirklich eine andere Metapher?
Die erste Frage, über die ich mir im Zusammenhang dieses Vortrags Gedanken gemacht habe, stammt aus einem Artikel, den ich vor einiger Zeit gelesen habe.
Hier wurde die These aufgestellt, dass wir den Begriff „Technische Schuld“ durch einen anderen ersetzen sollten, weil er immer zur Diskussion führt, wer schuld sei.
Ich halte das für ziemlichen Käse. „Schulden haben“ und „schuld sein“ sind zwei völlig unterschiedliche Konstrukte.
Dazu machen wir mal einen Ausflug in die Etymologie.

6. Ein kurzer Ausflug in die Etymologie
‣ Moralisches Konstrukt
‣ Verletzung der Interessen Anderer
‣ Verstoß gegen das Gewissen
‣ Pflicht, dem Recht zu folgen
‣ Zeitlich ungebunden
‣ Englisch: guilt
‣ Rechtliches Konstrukt
‣ Zeitlich gebunden
‣ Finanziell oder materiell verknüpft
‣ Pflicht zum Ausgleich
‣ Englisch: debt
Schuld Schulden
Im Deutschen benutzen wir den Begriff „Schuld“ für zwei völlig unterschiedliche Dinge.
Zum Einen ist da das moralische Konstrukt der Schuld, die aus einer Verletzung der Interessen Anderer oder ein Verstoß gegen das Gewissen resultiert.
Diese Schuld resultiert aus einer Pflicht dem Recht zu folgen und ist zeitlich ungebunden, es gibt aber keine Pflicht - und manchmal auch keine Möglichkeit - sie auszugleichen.
Im Englischen wird für diese Schuld der Begriff „guilt“ verwendet.
Zum Anderen haben wir die Schulden, die ein rechtliches Konstrukt darstellen.
Sie sind zeitlich gebunden und im Allgemeinen finanziell oder Material verknüpft.
Für sie besteht eine Pflicht zum Ausgleich.
Im Englischem wird für solche Schulden der Begriff „debt“ verwendet.
Beides sind zwei unterschiedliche Dinge, die nur durch einen etymologischen Unfall im Deutschen mit dem gleichen Begriff bezeichnet werden.

7. Zunächst ist festzuhalten:
Schulden sind nicht schlecht.
Halten wir zunächst etwas fest, dass den Schwaben unter uns schwer zu schaffen machen wird:
Schulden sind per se nicht schlecht.
Schulden sind einfach nur da.
Die Möglichkeit, Schulden zu machen, ist ein fundamentales Grundprinzip unseres Wirtschaftssystems.
Viele Dinge wären ohne das wirtschaftliche Konzept Schulden undenkbar.

8. Zwei Arten: Öffentliche Schulden…
Public debt is irrelevant.
— John Maynard Keynes
Aus makroökonomischer Sicht gibt es zwei Arten von Schulden:
Einerseits die öffentlichen Schulden, über die John Maynard Keynes sagte, dass sie egal seien.
Reinhard und Rogoff haben mit „This Time is Different“ ein sehr interessantes Buch über die Geschichte der öffentlichen Schulden geschrieben.
Aber alles, was wir heute in der Makroökonomie wissen, deutet darauf hin, dass Keynes nicht ganz falsch lag.
Zumindest sind sämtliche Modelle, die ihn zu widerlegen versuchten, gescheitert.

9. Zwei Arten: …und private Schulden
Anders schaut es mit privaten
Schulden aus…
Auf der anderen Seite stehen die privaten Schulden.
Diese sind für die Makroökonomie viel wichtiger als die öffentlichen Schulden.
Können die privaten Schulden in einer Volkswirtschaft nicht mehr bezahlt werden, bricht sie zusammen.
John Kenneth Galbraith hat mit „Eine kurze Geschichte der Spekulation“ eine sehr angenehm zu lesende Zusammenfassung der Resultate privater Schulden, die aus Spekulation resultierten, geschrieben.
Private Schulden sind also nicht egal.
Ganz im Gegenteil.

10. Wie passen technische Schulden da rein?
Die große Frage ist nun: Wie passen technische Schulden in dieses System?
Folgen sie dem Modell der öffentlichen Schulden oder dem der privaten Schulden?
Die Antwort ist: Weder - noch.
Technische Schulden folgen keinem der beiden Modelle, sondern funktionieren auf eine ganz andere Weise.
Machen wir einen kleinen Ausflug in die Gesetzgebung, um herauszufinden, warum das so ist…

11. Es begab sich am 29.5.2009…
Selbst geschaffene immaterielle
Vermögensgegenstände des Anlagevermögens
können als Aktivposten in die Bilanz
aufgenommen werden. Nicht aufgenommen
werden dürfen selbst geschaffene Marken,
Drucktitel, Verlagsrechte, Kundenlisten oder
vergleichbare immaterielle
Vermögensgegenstände des Anlagevermögens.
Es begab sich am 29.5.2009 als der §248 HGB eine fundamentale Änderung erfuhr.
Seit diesem Tag ist es möglich, „selbst geschaffene immaterielle Vermögensgegenstände“ in Unternehmensbilanzen zu aktivieren.
Software ist so ein „selbst geschaffener immaterieller Vermögensgegenstand“.

12. Das passt ganz hervorragend zu diesen Kollegen:
Warum das ein Problem ist?
Ganz einfach: diese Gesetzesänderung folgt dem Weg, der zur Pleite von Lehman Brothers geführt hat.
Kennt ihr noch die Geschichte dazu?
Ich beschreibe das hier mal ganz einfach, die Wirklichkeit ist natürlich viel komplizierter:
Die Kollegen von Lehman Brothers hatten Kredite - also Fremdkapital - die gebündelt waren, als Wertpapiere gekauft und diese als Vermögensgegenstände in die Unternehmensbilanz aufgenommen.
Als die Kredite ausfielen - private Schulden, die nicht zurückgezahlt werden konnten, Galbraith grüßt - gingen Vermögensgegenstände von Lehman Brothers plötzlich in nichts auf.
Die Bilanz ging kaputt und die Bank ging pleite.

13. Die Bilanz
Aktiva Passiva
Vermögens-
gegenstände
Eigenkapital
Fremdkapital
Software
steht hier!
Schauen wir uns mal so eine Bilanz an.
Auf der rechten Seite stehen die sogenannten Passiva.
Im Wesentlichen sind das Eigenkapital und Fremdkapital.
Auf der linken Seite stehen die Vermögensgegenstände.
Und eben auch der Wert der Software.
Nur wie entsteht dieser Wert?

14. Betriebswirtschaftliche Logik
‣ Software zu bewerten ist schwer.
‣ Also wird bewertet, was bewertet werden kann: der
Aufwand der Erstellung der Software.
‣ Technische Schulden sind ein Aufwandstreiber:
Je mehr technische Schulden, desto mehr Aufwand.
‣ Je höher der Aufwand, desto wertvoller die Software.
‣ Na, wer kennt das Ende…?
Der Wert von Software ist relativ schwer zu ermitteln.
Also versucht man, den Wert auf die einfachste mögliche Weise zu ermitteln.
Und das ist bei Software die Zeit, die für ihre Erstellung benötigt wurde.
Wir nennen das in der Regel den Aufwand.
Unser Problem mit den technischen Schulden ist, dass diese ein Aufwandstreiber sind.
Das bedeutet, mehr technische Schulden führen zu mehr Aufwand.
Und je höher der Aufwand für die Erstellung der Software, desto wertvoller ist sie.
Im Prinzip ist das der gleiche Mechanismus, der auch zur Pleite von Lehman Brothers geführt hat:
Etwas, das eigentlich negativ wirkt, wird als Vermögensgegenstand bewertet.
BWL ist halt keine exakte Wissenschaft.

15. Das ist der Grund, warum es in vielen
Unternehmen kein ökonomisches
Verständnis für technische Schulden gibt.
Dieser Bug in der wirtschaftlichen Betrachtung von Software ist der Grund, warum es kein ökonomisches Verständnis für die Entwicklung von Software gibt.
Und warum es keine validen Wertmodelle gibt, die Software korrekt erfassen können.

16. Ja, und nun…?
Was machen wir nun mit diesem Wissen?
Aufgeben?
Eine neue BWL erfinden?
Alle Softwareunternehmen auf den Pfad von Lehman Brothers schicken?
Einfach keine Schulden mehr machen?

17. Wir brauchen technische Schulden!
Der Punkt ist: Keine technischen Schulden zu machen, ist keine Option.
Wir benötigen technische Schulden ebenso wie wir die Möglichkeit finanzieller Schulden benötigen.

18. ‣ Technische Schulden helfen uns, Software schnell
auf den Markt zu bekommen.
‣ Technische Schulden helfen uns, Entscheidungen auf
den letztmöglichen Zeitpunkt zu verschieben.
‣ Technische Schulden helfen uns, Projekte zu
realisieren, die wir sonst nicht geschafft hätten.
‣ Je mehr wir uns in der Softwareentwicklung
bemühen, technische Schulden zu vermeiden, desto
mehr technische Schulden produzieren wir.
Technische Schulden erlauben uns, Software ökonomisch zu entwickeln.
Wir können unter Umständen mit einer Software früher auf dem Markt sein, wenn wir technische Schulden in Kauf nehmen.
Für Softwareentwickler ist das nicht so angenehm, für ein Unternehmen kann das sehr wichtig sein.
Wir können technische Schulden nutzen, um Entscheidungen in die Zukunft zu verschieben.
Heute keine perfekte Lösung zu bauen, sondern mit der unperfekten Lösung Zeit erkaufen um Neues zu lernen und mehr über die wirklich perfekte Lösung zu erfahren ist nur möglich, wenn wir technische Schulden in Kauf nehmen.
Technische Schulden können uns auch helfen, Projekte überhaupt zu realisieren, die unter anderen Umständen unmöglich gewesen wären.
Zeitlich, finanziell - oder auch nur, weil wir einen Prototypen bauen wollen.
Das waren allen Beispiele für das bewusste Aufnehmen technischer Schulden.
Ein Kuriosum, das mir in vielen Projekten begegnet ist, ist die Tatsache, dass technische Schulden eine selbsterfüllende Prophezeiung sind.
Je mehr wir uns bemühen, sie zu vermeiden, desto mehr von ihnen entstehen.
Wir können uns nicht bewusst gegen sie entscheiden.

19. Tools für technische Schulden
Ich hatte ja ganz am Anfang versprochen, dass ich noch zwei Tools vorstelle, um mit technischen Schulden umzugehen.
Hier kommen sie nun.

20. Technische Schulden ökonomisieren
Story Points
Do
Nothing
Cost
Das erste ist relativ einfach.
Wir benutzen ein XY-Diagramm bei dem wir auf der X-Achse die Aufwände darstellen, die bei der Beseitigung einer technischen Schuld entstehen.
Auf der Y-Achse tragen wir das ab, was ich als die Kosten des Nicht-Handelns bezeichne.
Die X-Achse können die meisten Teams recht gut schätzen, Das Prinzip ist das gleiche wie beim Schätzen von User Storys.
Das Schätzen der Y-Achse ist etwas schwieriger. Hier benötigen Teams in der Regel etwas Übung.
Die Frage, die ich ihnen üblicherweise stelle ist: Um wie viel kleiner wird das Backlog, wenn wir diese technische Schuld begleichen?
Nach drei, vier Sprints klappt das dann in der Regel mit dem Schätzen der „Do Nothing Costs“.

21. Technische Schulden ökonomisieren
Story Points
A
B
C
D
E
Do
Nothing
Cost
Die technischen Schulden positionieren sich dann im Diagramm auf verschiedenen Stellen.
Alles oberhalb der diagonalen Linie ist interessant, weil hier Nichtstun teurer ist, als die Beseitigung der technischen Schuld.
Wichtig ist, dass man diese Betrachtung regelmäßig wiederholt.
Ich mache das mit meinen Teams in jedem Sprint, und es entwickeln sich recht interessante Bewegungsmuster.
Einige technische Schulden werden immer teurer, andere werden günstiger.
Manchmal verschwinden sie sogar komplett, ohne dass irgend etwas getan werden muss.
Leider führt das nicht dazu, dass man sie - wie Keynes die öffentlichen Schulden - als irrelevant betrachten kann.

22. Technische Schulden bilanzieren
A
BV: 100
8 SP
B
BV: 150
5 SP
C
BV: 50
8 SP
D
BV: 208
13 SP
E
BV: 80
3 SP
Ein zweites Werkzeug ist eine Bilanzierung technischer Schulden.
Dazu benötigen wir eine Schätzung für den Business Value und den Aufwand für alle Backlog Items, die in einem Projekt bearbeitet werden.

23. Technische Schulden bilanzieren
C
BV: 50
8 SP
D
BV: 208
13 SP
Business Value Project Value
C
BV: 50
8 SP
D
BV: 80
5 SP
D
BV: 128
8 SP
Summe = 258 Summe = 258
Eigen
kapital
Fremd-
kapital
Für die realisierten Features trägt man nun den Business Value auf der linken Seite der Bilanz und einen Project Value (mir fiel bisher kein besserer Begriff dafür ein) auf der rechten Seite ein.
Hat man bei der Realisierung eines Features technische Schulden in Kauf genommen, wird das Feature auf der linken Seite mit seinem kompletten Business Value bilanziert.
Auf der rechten Seite wird aber der Business Value entsprechend des investierten Teilaufwands gewichtet.
Den Teilaufwand können Teams recht gut benennen, das Verhältnis für den Business Value ergibt sich dann automatisch.
Diese Bilanz hilft uns dann, zu erkennen wie viel unseres Business Value tatsächlich geschaffen wurde und wie viel davon mit Schulden belastet ist.
Da diese Schulden irgendwann einmal zurückgezahlt werden müssen, sollte auch die Bilanz kontinuierlich gepflegt werden.

24. Fazit

25. Keynes, Hayek & Lehman Brothers
‣ Technische Schulden werden nur in Ausnahmefällen
irrelevant!
‣ Technische Schulden erledigt man nicht durch noch
mehr technische Schulden!
‣ Technische Schulden sind ökonomische, keine
technischen Entscheidungen!
‣ Technische Schulden zurückzahlen lohnt nur dann,
wenn sie auch Zinsen kosten.
Fassen wir zusammen:
Technische Schulden sind alles andere als irrelevant, die üblichen ökonomischen Modelle erfassen sie aber nicht korrekt.
Es ist nicht möglich, technische Schulden durch andere oder mehr technische Schulden zu erledigen, wie das bei öffentlichen Schulden möglich ist.
Fundamental ist die Erkenntnis, dass technische Schulden keine technische Entscheidung sind, sondern eine betriebswirtschaftliche.
Das irritiert viele Softwareentwickler und noch mehr irritiert es Nicht-ITler.
Was bei der gesamten Debatte auch bedacht werden sollte ist, dass es sich nur lohnt, technische Schulden abzutragen, wenn sie tatsächlich Geld kosten.
Die oftmals geführte State of the Art-Debatte ist dabei weder hilfreich noch zielführend.

26. Noch ein paar Tipps zum Schluss…
‣ Macht technische Schulden im Backlog sichtbar!
‣ Quantifiziert den Business Value technischer
Schulden!
‣ Bewertet technische Schulden realistisch, um
Vertrauen zu schaffen.
‣ Schaut nicht zu weit und nicht zu kurz voraus, um
unabsichtliche technische Schulden zu vermeiden.
‣ Und: Müll im Code ist keine technische Schuld!
Ein paar Tipps habe ich noch für euch:
Macht eure technischen Schulden sichtbar.
Beispielsweise als Backlog Items im Product Backlog.
Beschäftigt euch mit dem Business Value der technischen Schulden und bewertet sie realistisch.
Wenn ihr über Business Value sprecht, könnt ihr auch Nicht-ITler erreichen.
Eine realistische Bewertung schafft Vertrauen und zeigt Kompetenz über die Software hinaus.
Es nützt nichts, zur Vermeidung technischer Schulden in die Zukunft schauen zu wollen.
Solve today’s problems today and tomorrow’s problems tomorrow.
Und: Nicht alles, was wie Müll ausschaut ist eine technische Schuld.
Seid ehrlich zu euch selbst und macht eure Hausaufgaben beim Coden.

27. Vielen Dank!
Gerrit Beine
adesso AG