OOP 2013

Ich nehme dieses Jahr nur die letzten beiden Tage mit, heute also den Donnerstag der großen deutschen Software Engineering Konferenz, die dieses Jahr zum 21. Mal in München stattfindet. Ein paar Notizen zu den Vorträgen, die ich gehört habe:
Geplante Änderungen – die Basis einer agilen Architektur
Michael Kircher scheint ein aktives Kerlchen zu sein. Als Abteilungsleiter bei Siemens Health Care leitet er etwa 20 Software-Architekten, 10 System-Ingenieure und über 100 Software-Entwickler. Nebenbei veröffentlicht er Podcasts und entwickelt Apps für Fischer und Jäger zum Zählen ihrer Beute.
„Agil ist Lean, angewandt auf Software“, habe ich gelernt und dass der Value eines Software-Teams oft nur zwischen 4 und 12% liegt. Da greift Lean an mit seinem „Gegen Verschwendung“ und „Wertschöpfung optimieren“ und die Antwort in der Software-Entwicklung ist eben Agilität.
Embrace Change ist ein bekanntes Statement, Embrace Uncertainty wäre richtig, denn Unsicherheiten freudig entgegennehmen ist das, was agile Teams agil macht – und Disziplin.
Bezüglich Architektur schwört Kircher nach wie vor auf die guten CRC-Karten und malt uns mit seinem iPad ein paar auf die Leinwand. Erst die Verantwortlichkeiten klären, später die Technologien. Auf die Frage „Wie sieht Eure Architektur aus?“ will er nichts von Webservice, Enterprise Java Beans und Tomcat hören, recht hat er. Unterscheide Problem Space und Solution Space!
Kircher stellt uns den Feature Tree vor, eine nette Methode, um Features thematisch zu gliedern; die Blätter des Baumes bilden die funktionalen Anforderungen („The system shall…“); diese lassen sich dann den geplanten Technologien, Komponenten, Subsystemen zuordnen. Entliehen aus dem Product Line Engineering.
Ein Architekt braucht jahrelange Erfahrung, muss einige Projekte vorweisen können, sich durch mehrere Technologien gekämpft haben. Ist einfach so. Und seine Prinzipien können wie folgt aussehen: (1.) Communication, denn ohne Kommunikation mit den Stakeholdern, im Team läuft nix, (2.) Consistency, denn gute Architektur muss sich etablieren, (3.) Coaching, denn er schult ständig seine Entwickler und schließlich (4.) Coding, wenn alle zuvor abgedeckt sind, darf er auch mal selbst ran.
Pattern for Continuous Delivery
Patrick Kua von ThoughtWorks powert diverse Patterns durch, die Continuous Delivery möglich machen, also die Fähigkeit, Software auf Anforderung zur Produktion frei zu geben,. Recht interessant, manche aber eher nur anwendbar auf Web-Applikationen, etwa Zero Downtime Deploy.
Spannend auch die Aussage, für jede Feature-Entwicklung zu branchen, aber die Features so klein zu halten, dass man nach einem Tag wieder auf den Trunk mergen kann. Das kommt doch eigentlich dem Scrum-Ansatz zu gute, sich Aufgaben zu definieren, die in einem Tag bearbeitbar sind.
Keynote: Agile Redefines Economics
Michael Mah ist der Zahlen-Papst der OOP, so kommt es mir vor. Wenn er mit einem Vortrag kommt, geht es um Zahlen und Metriken. Er belegt in der Keynote anhand seiner von tausenden Projekten gefüllten Datenbank, dass Agilität sich lohnt – oder so.
Effektivität und Effizienz durch Unabhängigkeit im Testen
Frank Simon von SQS hat eine Studie mit Studenten durchgeführt und demonstriert uns auf illustre Art und Weise die Ergebnisse. Dieses belegen, dass unabhängige Testteams effektiver testen, also mehr Fehler finden, und dabei effizienter sind, also weniger Zeit pro Fehler-Finden brauchen.
Er ist fair und listet abschließend auf, wo die Studie Haken hat, aber der Grundtenor bleibt bestehen. Entwickler sollten nicht selbst testen; zumindest nicht nur, denn der Entwickler enteckt bestimmt andere Fehler (technischere Fehler) als es der unbedarfte Tester tut.
Keynote: Securing Facebook’s graph

Christopher Palow von Facebook, London, sitzt in dem Team, das Facebook vor Angriffen schützt. Und da gibt es so einige – wen wundert’s. Er wird klar, die Jungs machen ihre Sache gut. Fazit für uns? Benutzt Facebook Connect für Eure eigenen Webseiten, damit sich Eure User mit ihrem Facebook-Account einloggen können. Facebook hat den Account schon für uns gecheckt.
Software development at Google
Boris Bokowski war früher in Sachen Eclipse unterwegs, bevor er wieder nach Deutschland kam und jetzt bei Google in München sitzt. Wie wir erfahren, arbeiteten alle Google-Entwickler auf einem Repository. Ich kann’s immer noch nicht glauben. Das sind immerhin 15.000 Entwickler und alle arbeiten auf Head.
A propos Head: den leg ich jetzt mal aufs Kopfkissen. Morgen wird’s noch richtig Lean mit dem Ehepaar Poppendieck. Ich bin gespannt.