Die Mitarbeiter von Prof. Dr. Lutz Prechelt an der FU Berlin haben über ein halbes Jahr die Daten, die während des Wettbewerbes aufgenommen wurden (Source-Code, Tätigkeits-Protokolle etc.), ausgewertet und zu aussagekräftigen Thesen verdichtet.

In den Abbildungen 1 bis 3 kann man sehen, wie viele der Anforderungen umgesetzt wurden. Anhand dieser Balken wurden ja pro Plattform (also Ruby, PHP, Java, Perl) die Sieger gekürt.

Aus der ersten Abbildung kann man den Schluss ziehen, dass es weniger auf die Programmiersprache als vielmehr auf das verwendete Framework ankommt. Die Ruby-Teams haben ausnahmslos Rails eingesetzt. Wir (Team PHP M) haben auf symfony 1.4.x gesetzt, welches stark an Ruby on Rails angelehnt ist (insbesondere was den Ansatz der automatischen Code-Generierung angeht). Die anderen PHP-Teams haben Zend-Framework 1.x oder Flow3 (welches zu dem Zeitpunkt noch in der Alpha-Phase war) eingesetzt. Das sehr gute Java-Team setzte allerdings auf seine in 13 Jahren im Eigenbau gewachsene Werkzeug-Bibliothek und war damit sehr erfolgreich.

Anhand von Abbildung 2 sollte gezeigt werden, ob sich Teams zuerst an den Webservice gemacht haben und Ihr Web-Frontend darauf aufgebaut haben. Wir haben den Webservice nach gelagert umgesetzt (und haben seinen Umfang deutlich unterschätzt). Ruby P, Ruby H und Java A scheinen den Webservice mit höherer Priorität umgesetzt zu haben.

Aus Abbildung 3 kann man ableiten, dass die Teams, die sich auf das Vollenden von kompletten Features konzentriert haben, anstatt viele Features nur anzufangen, im Schnitt erfolgreicher waren. Einzige Ausnahme ist auch hier Team Java A, das erfolgreich war, obwohl es relativ viele unfertige Features hat.

Die einzelnen Plattformen waren von ihrer Performance ähnlich stark wie im Vorgänger-Wettbewerb 2007. Allerdings wurden sie von Ruby rechts überholt (siehe Abb. 4).

Aus den Abbildungen 5 und 6 wird im Vergleich zu Platt_Forms 2007 klar, dass die Plattformen insgesamt robuster geworden sind.

Was es aussagt, dass die Ruby-Teams im Schnitt mehr fachliche Fragen hatten (Abb. 7), kann ich nicht sagen.

Der eigentliche Augenöffner beim Plat_Forms-Wettbewerb 2011 ist in Abbildung 8 dargestellt. “Obwohl” die Ruby-Teams 3 mal so viele automatische Tests wie die Perl-Teams und sogar 6 mal so viele wie die Java- und PHP-Teams geschrieben haben, haben sie im Schnitt die meisten Features umgesetzt. Das heißt für mich, dass das Schreiben von automatischen Tests, die Entwicklungsgeschwindigkeit zumindest nicht beeinträchtigt, wenn nicht sogar verbessert (wenn man geübt im Schreiben von automatischen Tests ist). Und das gilt sogar schon bei einer Projektlaufzeit von 75 Personenstunden. Das bedeutet für mich: Nie wieder ein Projekt (und mag es auch noch so klein sein) ohne Unit-Tests.

Die Erkenntnisse, die man aus Abbildung 9 gewinnen kann, halte ich für nicht so essentiell.

Es ging den Veranstaltern – der Freien Universität Berlin und der Open Source Business Foundation – primär darum, herauszufinden, welche spezifischen Vor- und Nachteile bestimmte Plattformen für die Webentwicklung mitbringen. Aber dass auch ein Gewinnerteam je ausgewählter Plattform gekürt werden sollte, war sicherlich ein zusätzlicher Anreiz für uns. Nun erfüllt uns der Sieg unserer mindworks-Gesandten nicht nur mit Freude, sondern auch mit der Gewissheit: Die Entscheidung, auf symfony 1.4 zu setzen, war genau die richtige. Und dass wir mit aktuellen PHP-Frameworks strukturiert arbeiten und zügig an unser Ziel kommen, zeigt ja nicht nur der Wettbewerb sondern unser täglich Brot. Unsere ersten Erfahrungen mit Symfony 2 übrigens sind vielversprechend; hierzu ein anderes Mal mehr.

Aber zurück zu Plat_Forms 2011: Sobald die Veranstalter die Ergebnisse öffentlich zur Verfügung stellen, möchten wir an dieser Stelle unseren Senf dazugeben und ein paar Aspekte beleuchten. Jedenfalls hat der Wettbewerb Spaß gemacht und war lehrreich. Wir werden uns auf jeden Fall wieder bewerben.

Unsere Pressemitteilung dazu.