Nachdem Christian Speckner und ich gestern den Tag auf der OOP 2013 in München verbracht haben, wollen wir hier einfach mal unsere Eindrücke aus drei recht unterschiedlichen Vorträgen teilen.
Ob sich der Besuch der Konferenz aus unserer Sicht gelohnt hat? Finden wir es heraus …
Unser erster Vortrag war „Requirements Engineering in Safety Critical Engineering“ von Colin Hood. Der Vortrag hat sich sehr allgemein mit der Definition und Planung von Sicherheitsaspekten in der Architektur großer Projekte beschäftigt, hatte also leider nicht allzu viel mit unserer täglichen Arbeit zu tun. Das Endergebnis war die nicht völlig überraschende (aber trotzdem interessante) Erkenntnis, dass es essentiell ist, dass alle Ebenen des Projekts miteinander Dialog führen und nicht nur Requirements weitergereicht werden. Außerdem sollten Sicherheitsaspekte von Anfang an eingeplant und nicht erst nachträglich dazugeschustert werden.
Sehr interessant war auch die erste Keynote des Tages „Agile Redefines Economics: What Data Reveals from Recent Agile Benchmark Research“ von Michael Mah. Ziel des Vortrags war es, agile und traditionelle Softwareentwicklung anhand quantitativer Daten gegenüberzustellen. Unter anderem wurden für einzelne agil arbeitende Unternehmen Metriken wie Projektkosten, Zeitaufwand, Zahl der Bugs und Mitarbeiterzahl dem Industriemittel gegenübergestellt. Alle gezeigten Zahlen zeichnen die agilen Projekte deutlich positiver als das Industriemittel, aber andererseits sagen die nackten Zahlen natürlich nichts über die Streuung über verschiedene Unternehmen aus.
Andere Grafiken waren in dieser Hinsicht aufschlussreicher – in Plots wurden für verschiedene Projekte aus dem agilen und aus dem „traditionellen“ Umfeld beispielsweise die Zahl der Codezeilen der Zahl an Bugs gegenübergestellt, zusammen mit dem Industriemittel und der entsprechenden Standardabweichung. Auch dieser Vergleich hat die agilen Projekte immer als mindestens genauso gut und oft besser als traditionelle Softwareentwicklung dargestellt. Allerdings war die Streuung groß und man hätte manche der Grafiken auch so lesen können, daß beide Projektmodelle vergleichbar sind. Allerdings hat Michael Mah am Ende auch eine eindrucksvolle Vergleichsstudie aus Columbus, Ohio gezeigt, bei der alle agilen Projekte eindeutig unter das Industriemittel gestreut haben.
Alles in allem ein sehr interessanter Vortrag, und auch wenn Statistik halt oft mehrere Interpretationen zulässt, scheinen die Zahlen zu belegen, dass agile Techniken deutlich leistungsfähiger als traditionelle Modelle sind. Wäre interessant, die ganzen Studien zu lesen. Auch das nächste Jahr könnte spannend werden: Michael Mah hat Interesse an einer Vergleichsstudie, die Deutschland einschließt — die gezeigten Zahlen haben sich alle auf die USA und Kanada bezogen. Übrigens, ein interessantes Detail: alle gezeigten agilen Projekte haben Pair Programming eingesetzt :)
Als letztes wollen wir ein paar Worte zu „Länger schlafen mit NodeJS“ von Christian Heger sagen. In dem sehr interessanten Vortrag wurden Node.js und typische Programmierpattern in diesem Umfeld anhand eines Sandkastenprojekts vorgestellt. Innerhalb von sechs Mannwochen hat dabei ein drei-Mann-Team (nur einer mit etwas JavaScript-Erfahrung) eine Applikation geschrieben, die alle paar Sekunden mehrere tausend Echtzeitdatensätze mit Flugzeugpositionsdaten verarbeitet.
Neben einer kleinen Einführung in die Grundlagen von Node.js hat sich der Vortrag weniger auf Implementierungsdetails und mehr auf das „Big Picture“ und die Softwarearchitektur konzentriert. Insbesondere wurde die zugrundeliegende ereignisgetriebene Programmarchitektur hervorgehoben sowie die Abarbeitung von JavaScript in einem einzelnen Thread — Multithreading ist in Node.js transparent in die in C geschriebenen Bindings ausgelagert. Die interessante Konsequenz ist, dass in Node geschriebene Webanwendungen zum Skalieren auf mehrere Node.js-Instanzen verteilt werden müssen.
Obwohl das Resultat dieses Experiments sehr zufriedenstellend ausgefallen ist, sind im Verlauf auch Probleme aufgetaucht, von denen das größte wohl Speicherlecks sind, sowohl innerhalb der Anwendung (durch nicht gelöschte Objektreferenzen) als auch in Node.js selbst. Das lässt sich zwar „beheben„, indem die Node.js-Instanz gelegentlich neu gestartet wird, aber sowohl für langlaufende Services als auch Embedded-Systeme stellt das ein ernsthaftes Problem dar.
Gesamteindruck der OOP? Positiv, die Vorträge waren eigentlich durch die Bank interessant bis unterhaltsam, und auch wenn der tatsächliche Mehrwert für die tägliche Arbeit überschaubar ausgefallen ist, hat sich der Besuch der OOP gelohnt.
