Talk with Jörg Nitzsche about the technical debt metaphor. Slides in German. Schulden machen ist leicht, zu leicht manchmal und ehe man sich versieht, hat man Mühe die Schuldenlast zurück zu zahlen. Ähnlich verhält es sich auch bei Softwarearchitektur. Ein "das fixen wir später" hier, "die Dokumentation ziehen wir nach der Abnahme nach" dort, ein kleiner Hack da, ein schnelles Feature dazu und schon sieht man sich einer degenerierten Software(architektur) gegenüber, die hohe Wartungskosten nach sich zieht und eine weitere Entwicklung nur bedingt zulässt. Damit es nicht so weit kommt muss man sich der Schulden bewusst sein, die man durch manche Entscheidungen aufnimmt und muss den Schuldenberg im Griff behalten. Das gilt für traditionelle Softwareprojekte gleichermaßen wie für SOA- und BPM-Projekte. In diesem Vortrag gehen wir auf verschiedene Arten technischer Schulden ein und zeigen Wege auf, wie man ihnen im Projektalltag begegnet.

1. Tammo van Lessen | InnoQ
Dr. Jörg Nitzsche | T-Systems
Vorsicht Schuldenfalle –
Was die IT aus der Finanzwelt lernen kann

2. Wer sind wir?
Tammo van Lessen
Senior Consultant bei innoQ
SOA / BPM / Architektur / Web
Apache Member und VP Apache ODE
Dr. Jörg Nitzsche
Senior Architect bei T-Systems
EAM / SOA / BPM / Architektur

3. Inhalt
• Metaphern
• Arten der Schulden
• Was ist mit den Zinsen?
• Wie verschulde ich mich?
• Was muss ich über Schulden wissen?
• Was tue ich bei drohender Insolvenz?

4. Metaphern
• Warum?
– Helfen Dinge deutlich zu machen
• Häufig verwendete Metaphern:
– Haus = Applikation
– Bebauungsplanung = Enterprise
Architektur Management
• Heute:
– Natürliche Person = Applikation

5. Natürliche Person
• Spätestens seit Peter Zwegat wissen wir:
– Personen verschulden sich,
können die Schulden nicht
tilgen und die Zinsen nicht
bezahlen
• Weitere Definition:
– Schuldenlast = Kosten zur Problemlösung
– Zinsen = Kosten mit der aktuellen Situation zu
leben

6. Technische Schulden
• Metapher geprägt von Ward
Cunningham '92
• Diskutiert von Martin Fowler &
Steve McConnell
• In der Praxis viel zu wenig
ernst genommen

7. Schulden
Was für Arten von
Schulden gibt es?

8. Design & Architektur
• Ungeeigneter
Architekturstil
• Falsche Wahl
der Werkzeuge
• Ignorieren von
Konzernstandards
• Zu viele Kompromisse und Workarounds
• Frameworks „vergewaltigt“

9. Code-Qualität
• Hohe Anzahl von Ausfällen / Fehlern
• Hohe Anzahl kritischer Bugs
• Code-Metriken
• Code-Duplizierung
• Kein „clean code“ / SOLID

10. Testen
• Fehlende Automatisierung
• Manuelle Regressionstests

11. Dokumentation
• Wissen wird nicht dokumentiert.
• Wissen wird nicht geteilt.
• Wissen wird nicht verteilt.
• „Bus factor“

12. Umgebung
• Wackelige Infrastruktur
• Unflexibler Betrieb
• Unangemessene Konzernstandards
• Fehlerhafte Komponenten
• Unzuverlässige Umsysteme

13. Zinsen
Was ist mit den Zinsen?

14. Wie hoch sind die Zinsen?
• Betrieb:
– Neustart des Servers jeden Tag wegen
Memory Leak
• Entwicklung:
– Aufgrund einer Vorgabe muss EJB 2.1 statt
3.0 verwendet werden und deswegen entsteht
viel mehr aufwand
– Aufgrund fehlender automatisierter
Regressionstests sind aufwändige manuelle
Tests notwendig

15. Was muss ich bzgl. der
Zinsen wissen?
• Generell muss man beim Schulden
machen wissen, wie hoch die
Folgekosten sind:
– Bsp.: USA Finanzkrise / Immobilienkrise
• Es wurden Darlehen mit variablen Zinsen
vergeben, d.h. die Schuldner kannten die
Kosten nicht
Gehen Sie nur kalkulierbare Schulden ein!

16. Schuldenaufnahme
Wie nehme ich Schulden
auf?

17. „Pech“
• Unvorhersehbar
• Unbeeinflussbar
• Applikation:
– „Die strategische Ausrichtung hat sich geändert und das
Framework XY darf nicht mehr verwendet werden“
– „Das Produkt wurde von einem anderen Anbieter
übernommen und wird nicht mehr supported / zu gänzlich
anderen Konditionen (höhere Zinsen).
• Natürliche Person:
– „Die Gesetzgebung hat sich geändert, und es darf nicht
mehr mit Gas geheizt werden. Die Heizung muss erneuert
werden“

18. Unachtsamkeit
• Verantwortungsloses / „Krankhaftes“ Verhalten
• Mangelnde Kompetenz
• Applikation:
– „Featuresucht“
– „Es gibt Logging-Frameworks? Das hätte uns 3 Monate
Entwicklungszeit gespart.“
– „Oh, das Framework das wir ausgesucht habe skaliert ja gar nicht
entsprechend unseres Mengengerüsts.“
• Natürliche Person:
– „Spielsucht“
– „Kaufrausch“
– „Ach, die Reisekosten muss ich selber bezahlen…“

19. Strategisch
• Geplant
• langfristig
• Applikation:
– „Wir wollen mit unserem Produkt die ersten auf
dem Mark sein, koste es was es wolle.“
• Natürliche Person:
– „Baudarlehen“

20. Taktisch
• Geplant
• kurzfristig
• Applikation:
– „Wir brauchen das Feature im nächsten Release,
können es aber bis dahin nicht sauber umsetzen. Wir
fixen das später.“
– „Die Applikation unterstützt eine Aktion und muss nur 6
Monate laufen, wie ist egal“
• Natürliche Person:
– „Kredit zur Weihnachtszeit, bis zur nächsten nächsten
Bonuszahlung“
– „Knockin‘ on heavens door“

21. Inkrementell
• Sammlung vieler kleiner Kompromisse
• mangelnde Übersicht
• „Ich weiß grad nicht wie viele
Ratenkredite ich schon habe, aber den
einen werd' ich schon noch verkraften.“
• „Kreditkartenschulden“

22. Kategorisierung in Quadranten
rücksichtslos besonnen
vorsätzlich
versehentlich
Baufinanzierung
„Das eingesetzte Produkt
wurde von einem anderen
Anbieter übernommen und
wird nicht mehr unterstützt.„Log4J? Nie gehört,
brauch ich nicht!“
„Was ist eine
Schichten-
Architektur?“
„Wir nehmen einfach
den Prototyp. Der
funktioniert doch!“
„Wir müssen dieses
Release morgen
veröffentlichen damit
wir den Zuschlag
bekommen. Die
Konsequenzen sind
kalkulierbar.“
Kredithai
Abofalle
„Wir haben keine Zeit
für einen Entwurf!“
Karstadtpleite
nach: M. Fowler

23. Prognose bei Verschuldung
• Rücksichtslose Verschuldung:
– Zinszahlungen werden so hoch, dass sie nicht mehr
zurückbezahlt werden können, bis hin zur Insolvenz
• Besonnene Verschuldung:
– In der Regel gut geplant und überlegt, d.h. in der Regel kann
der Kredit zurückbezahlt werden, nur nicht bei
unvorhersehbaren Ereignissen.
Treffen Sie bewusste Entscheidungen, versuchen
Sie unvorhergesehene Ereignisse zu antizipieren

24. Was muss ich noch über
Schulden wissen?

25. Ursachen für Schulden
• Mangelnde Erfahrung aller Beteiligten:
– Projektleiter / Applikationseigner
– Architekt
– Entwickler
– …
• Überlastung der Beteiligten:
– Entwickler in Helpdesk-Aufgaben eingebunden.
– Zu ambitionierte Planung
• Unklare und sich ändernde Anforderungen
• Oft auch Kulturprobleme:
– Gegeneinander statt miteinander
– Verschiedene Stakeholder mit unterschiedlichen Interessen

26. Wie erkenne ich meine Schulden?
Im realen Leben
• Kontoauszug
• Kreditkarte wird eingezogen
• Schreiben vom Gerichtsvollziehers
• Besuch des Gerichtsvollziehers
• Haus wird zwangsversteigert

27. Wie erkenne ich meine Schulden?
In der IT
• Sinkende Qualität
• Sinkende Produktivität
• Sinkende Testüberdeckung
• Steigende Anzahl Defects
• Steigende Testaufwände
• Steigende Anzahl Hacks
• Verspätete Releases
• Stress vor Deadlines
• Angst vor Code-Änderungen
• Verwendung veralteter Bibliotheken
Code-
Metriken
Issue
Tracker
Project
ManagementKPIs
Social
Events

28. Was mache ich mit meinen
Schulden?
• Schulden so belassen und einfach nur
die Zinsen zahlen
• Schulden abzahlen
– Ansätze:
• 10% der Teamzeit für refactorings und
Aufräumarbeiten reservieren.
• Aufräum-Releases planen.
• Einen Schulden-Backlog pflegen
– Mit Schuldenlast und Zinssatz

29. Wer hält mich davon ab
Schulden zu machen?
• Natürliche Person:
– Erziehungsberechtigter / Ich selber
– Gläubiger: Banken
– Schufa
• Und meine Applikation?
– Applikationseigner / Projektleiter?
– Budgetverantwortliche / Fachbereich?
– Enterprise Architekt bei QG Architecture
– Architekt

30. Wie vermeiden Architekt und
Entwickler Schulden?
• Kontinuierliches Refactoring
• Automatisierung (Testen, Deployment,…)
• Geteiltes und verteiltes Wissen
• Clean Code / SOLID
• Früh scheitern
• Auf hohes, einheitliches Niveau achten
• Pfadfinderregel

31. Wie können Sie unterstützt
werden?
• Management (Projektleiter /
Applikationseigner)
– Technische Schulden erfassen und ernst
nehmen (Schuldenmonitor)
– Indizien und Kennzahlen nicht den Entwicklern
zur Last legen (Unternehmenskultur
verbessern)
• Budgetverantwortliche / Fachbereich
– Technische Schulden ernst nehmen
– Raum für Schuldenabbau geben
– Requirements klar definieren

32. Was passiert, wenn mich
meine Schulden erdrücken?

33. Was passiert bei Insolvenz?
• Natürliche Person:
– Privatinsolvenz anmelden:
• Verhandlung mit Gläubigern über Schuldenerlass
• Wenn Verhandlung nicht erfolgreich: Mehrere Jahre am
Existenzminimum
• Applikation:
– Vor der Insolvenz: Versuchen sich mit dem Gläubiger zu
einigen
• Schulden eliminieren / Vorgaben ändern lassen:
– z.B. DB2 ist strategisch einzusetzen, Oracle wird aber verwendet
– z.B. Hibernate darf nicht eingesetzt werden, wird aber eingesetzt
• Höheres Budget für Zinszahlungen (Run-Budget oder
Development-Budget)
– Wenn Verhandlung nicht erfolgreich: Es werden keine neuen
fachlichen Anforderungen umgesetzt, bis die neue
Applikation schuldenfrei aufgebaut wurde

34. Wann melde ich Insolvenz
an?
• Natürliche Person:
– Alle Schulden müssen auf den Tisch
– Danach dürfen keine neuen Schulden bekannt
werden
– Erst wenn man nach Ablauf der Frist auf eigenen
Beinen stehen kann

35. Was bedeutet das für meine
Applikation?
• Wenn die Applikation am Ende ist, dann bringt es nichts,
Insolvenz der Applikation anzumelden, und eine neue
Applikation zu bauen.
• Man muss wie im echten Leben danach wieder auf die Beine
kommen können.
• Man muss also sicher sein, dass es beim nächsten Mal besser
wird. Also:
– Keine unkontrollierten unerfahrenen Entwickler, die versehentlich
Schulden machen
– Architektur basierend auf den richtigen Prinzipien
– Die fachlichen funktionalen und nicht-funktionalen Anforderungen
müssen bekannt und sinnvoll sein
Nehmen Sie im Fall der „technischen“ Insolvenz
keine fachlichen Schulden mit !

36. Was tue ich (Entwickler/Architekt) im
Projektalltag zur Vermeidung der Insolvenz?
• Ich identifiziere technische Schulden.
• Ich muss meinem Projektmanager und den Stakeholdern
klar machen, dass wenn wir die nicht abbauen, das Ding
den Bach runter geht.
• Ich bekomme von ihm einen Tag pro Woche oder
vollständige Releases für Refactorings (Schuldenabbau)
• Ich muss überwachen, ob das auch wirklich die Schulden
verringert
• Wenn ich merke, dass ich die Schulden nicht aus eigener
Kraft abbauen kann, dann: haben wir zwei Möglichkeiten:
– 1) Insolvenz: Applikation durch Neuentwicklung ablösen
– 2) Irgendwoher billig Geld leihen: höheres Budgets für Run
und Development bekommen

37. Zusammenfassung

38. Zusammenfassung
• Die Metapher „Technische Schulden“ macht
das Problem für Entscheider anschaulich und
sensibilisiert das Team
• Das hilft ein Umfeld zu schaffen in dem
Schulden ernst genommen werden
• Dadurch werden weniger Schulden
aufgenommen und ggf. Schulden abgebaut.
• Technische Schulden können guten Gewissens
aufgenommen werden.
– So lange man sie zurückzahlen kann!

39. • Offene Sammlung von Mustern zur
– Analyse
– Evaluierung
– Verbesserung
von existierender Software
• Initiiert von Gernot Starke
• Lesen, profitieren, mitmachen.
• http://www.aim42.org/

40. Vielen Dank für Ihre
Aufmerksamkeit

41. Backup

42. Bildreferenzen
• Hammer & Schraube:
https://www.flickr.com/photos/justinbaed
er/5317820857/