Bericht von der OOP 2014 (Teil 1)
Jedes Jahr findet in München die OOP statt, eine Messe, auf der viel über Software-Architektur, Agilität und Management gesprochen wird. Dieses Jahr waren mehr als 150 Referenten vor Ort und haben über 1800 Konferenz-Teilnehmer unterhalten. Mich am Mittwoch und Donnerstag ebenfalls.
Eingang zur Messe.
Mittwoch, 05.02.2014
OOA, IOC, ROI, SQL - Was passt nicht?
Der erste Vortrag war „OOA, IOC, ROI, SQL - Was passt nicht? Eine Erzählung von Betriebswirtschaft und Software-Entwicklung“. Hier ging es speziell um den Return of Invest (ROI), für den sich das Management in einer Firma meist interessiert.
Anhand eines Beispiel, bei dem es darum ging, ob man ein Stück Code mit einer Factory und DIP refaktorisiert, wollte Michael Mahlberg zeigen, ob es sich lohnt, dies so umzusetzen. Wichtig für ihn war, nicht die absoluten Zahlen zu sehen, sondern immer die Investierung betrachtet über die Zeit (also inkl. Zinssatz). Ich gebe zu, dass ich das nicht alles verstanden habe.
In kleinen Gruppenarbeiten sollten dann andere Fälle wie „Make or Buy“, „Serviceaustausch“ oder „Flat-File vs. Datenbank” besprochen werden. Da wir viel zu viele Teilnehmer waren (ca. 50) teilten sich diese also auf drei Gruppen auf, in der aber nur wenige etwas zum Ergebnis beitrugen. Heraus kam auf alle Fälle, dass es wesentlich leichter ist, die Kostenseite für eine Software-Änderung aufzuschreiben als die Nutzenseite.
Architectural Refactoring
Der zweite Vortrag war „Architectural Refactoring - agile Umsetzung von Modernisierungsentscheidungen“. Unter Architectural Refactoring versteht Referent Olaf Zimmermann, dass man eine zuvor getroffene architekturelle Entscheidung ändert.
In der Regel ist dies nicht einfach, da es mit einer Strukturänderung im Design, Neuimplementierung und Dokumentation verbunden ist. Oftmals liegen vorher getroffenen Entscheidungen nicht einmal vor, was die Sache noch mehr erschwert.
Als Beispiel hat er ein Y-Template vorgestellt, mit dem man festhalten kann, welcher Anwendungsfall unter bestimmten nicht-funktionalen Anforderungen zu einer Entscheidung führt und andere Entscheidungen weglässt, sodass ein bestimmtes Ziel erreicht wird unter Beachtung ggf. negativer Konsequenzen. Festgehalten werden soll das Ganz durch das „ARC Metamodel“, was aber derzeit noch entwickelt wird.
Keynote: Agile Skalierung – Prinzipien statt Blaupause
Die Keynote „Agile Skalierung – Prinzipien statt Blaupause“ von Stefan Roock und Hennig Wolf war sehr interessant.
Die beiden Trainer von it-agile zeigten als Beispiel, dass ein agiles Pilotprojekt auf eine ganze Firma ausgewälzt werden soll. Hier hilft dann keine generische Blaupause, nach der alles umgestellt wird. Ein Überstülpen eines neuen agilen Entwicklungsprozesses von oben bringt nichts, sondern der Kulturwandel muss von unten, von den Mitarbeitern kommen. Verschiedene Prinzipien wie direkte Kommunikation, kein Zielzustand vorgeben sowie beobachten und anpassen sind dabei ganz wichtig, damit so eine Änderung ein Erfolg wird.
Imposing Rule-Based Architecture on Legacy Systems
Der Vortrag „Imposing Rule-Based Architecture on Legacy Systems“ von Michael Feathers sollte den Umgang mit Legacy-Systemen zeigen.
Neben der Darstellung einer einfachen Struktur stellte er einige Mittel vor, wie man Verletzungen der Architekturregeln darstellen kann. Zusätzlich war es wichtig, den Fortschritt wie auch immer zu messen.
Ein schönes Zitat von Kent Beck im Vortrag war: „Wenn du dein System nicht mit vier Objekten oder weniger beschreiben kannst, hast Du keine Architektur.” Das kann man als übertrieben ansehen, aber es soll klar machen, dass jede Art von Architektur zumindest als grobes Konzept leicht verständlich sein muss. (Als Beispiel hat Michael Feathers im Übrigen das Testframework JUnit mit nur zwei Klassen beschrieben.)
Die Vortragsfolien sind leider nicht so gut, da diese oft nur die Überschrift enthalten und der Rest auf der Tonspur kam, was die Zusammenfassung auch etwas erschwert.
Keynote: Mastering the Internet
Überrascht hat mich die Keynote „Mastering the Internet“ von Constanze Kurz. Die Sprecherin des Chaos Computer Club ist vielen sicher bekannt, man würde sie aber nicht auf OOP erwarten.
Das Thema ihres Vortrags war recht aktuell, da es um die Enthüllung von Edward Snowden ging, vor allem eben Prism und die anderen Überwachungsaktivitäten des us-amerikanischen und britischen Geheimdienstes.
Als Open-Source-Aktivist (und Mitglied bei der EFF und FSFE) bin ich dem Thema sehr verbunden und habe mich gefreut, dass Constanze Kurz das den OOP-Teilnehmern noch einmal klar gemacht hat. Interessanterweise blieb sie nicht die einzige …
CCC-Sprecherin Constanze Kurz.
Modernisierung von zentralen Frameworks
Anatole Tresch von der Schweizer Bank Credit Suisse zeigte im Vortrag „Modernisierung von zentralen Frameworks - ein Erfahrungsbereicht“, wie einen Java-Framework, was in der Bank benutzt wird, in mehreren Jahren modernisiert wurde.
Grund für die Modernisierung (Refactoring) waren die üblichen Probleme wie erhöhte Wartungszeit und eine zu komplexe API. Das mittelgroße System mit 17.000 Codezeilen hatte Zyklen, eine hohe Kopplung und zahlreiche große Klassen. Als Ziele gab man sich vor robust zu sein, die Wartbarkeit und Laufzeit sollte verbessert werden, daneben wollte man aber auch kompatibel bleiben.
Hier sollte jedem klar sein, dass das eigentlich nicht alles machbar ist. Angeblich wurde aber eine Performancesteigerung von Faktor 100 herausgeholt. Gleichzeitig wurde das System entkoppelt und vereinfacht, was ich mir nicht so richtig vorstellen kann. Kompatibel ist man aber nicht geblieben, was aber kein Problem war, da die Kunden ja wiederum in der Bank saßen und man so direkten Kontakt zu ihnen halten konnte.
What If? - An Exploration of What's Possible, What's Not and Why?
In der Abendschule von 18:30 Uhr bis 20 Uhr gab es dann den letzten Vortrag „What If? - An Exploration of What's Possible, What's Not and Why?“ von David Hussmann. Einige Vorträge gibt es auch auf seiner Firmen-Webseite Devjam.
Sehr unterhaltsam hat David Hussmann erklärt, dass die Leitsprüche „certification over education“ und „process over product“ eher schaden als nützen. Die Änderungen müssen aus dem Team heraus kommen und von ihm angenommen werden. Zusätzlich muss Platz für Anpassungen und Veränderungen sein.
Das heißt, wenn der Prozess nicht passt, egal ob Scrum, Kanban oder was anderes, dann muss man ihn anpassen. Und wenn man dann eben eben nicht mehr nach Lehrbuch arbeitet, dann ist das einfach so. Wenn es dem Team und dem Projekt hilft, ist das in Ordnung.
Mir hat an dem Vortrag gefallen, dass eben nicht so sehr auf Regeln gepocht wird. An vielen Stellen hört man immer wieder: „Was, ihr macht Scrum und habt kein ordentliches Backlog? Wie könnt ihr nur?“ Ich hoffe, dass sich dieses Denken der Freiheit und Anpassbarkeit noch weiter herumspricht.
Etwas enttäuscht war ich nur von dem Begriff Abendschule (Night school). Ich hatte mir darunter eine lockerere Atmosphäre und Gespräche vorgestellt. Effektiv war es aber wie die normalen Vorträge – nur eben spät abends … und recht teuer.
