Vorsicht Schuldenfalle – Was die IT aus der Finanzwelt lernen kann

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.

Transcript

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 Management KPIs 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/