Berlin fand ich spitze, aber da das hier kein Blog über Städtereisen ist, schreibe ich heute „nur” eine kurze Zusammenfassung dessen, was ich mit Nico und Frank auf der International PHP Conference Spring Edition 2010 und der Webinale 2010 erlebt und gelernt habe.

Die Workshops

Begonnen hat die Konferenz für mich mit einem Workshop am Sonntag nachmittag (morgens hatten wir eine Stadtrundfahrt, aber dazu wollte ich ja hier nichts schreiben). Der Workshop „Softwarearchitektur vs PHP” von Johann-Peter Hartmann war sehr unterhaltsam und mit der Vorstellung von ATAM (Architecture Tradeoff Analysis Method) habe ich auch etwas neues gelernt. Ich hatte zwar mit etwas mehr Inhalten zum Thema Architektur gerechnet und hätte auf den interaktiven Teil auch verzichten können, aber alles in allem war es ein interessanter Vortrag.

Montag

Der Montag startet mit zwei eher durchwachsenen Keynotes: Während der Vortrag „Die Mensch-Maschine-Beziehung und ihre Folgen” von Ibrahim Evsan unterhaltsam war, obwohl er nichts Neues erzählt hatte, war die Google-Keynote „Die Zukunft liegt in der Cloud” einfach nur langweilig. Der Gipfel war, dass Petra Sonnenberg zeigen wollte, wie in Zukunft alle unsere Applikationen in der Cloud laufen, gleichzeitig aber eine Präsentation mit Google Docs erstellt hatte, die aussah wie die ersten Gehversuche mit Power Point. Geendet hat die Keynote mit einem Werbevideo von Google. Nicht gerade das, was ich mir von einem Unternehmen wie Google versprochen hatte.

Danach kam das Highlight des Tages: Julian Koschwitz hat in seiner Session zu „Augmented Editorial Design” gezeigt, wie man klassische Printmedien mit dem Web verbinden kann und Magazine um dynamischen Content wie Videos oder Sound anreichern kann. Eine Webcam und ein Browser ist ausreichend. Ähnlich gut war die erste Session der IPC, die ich danach besucht habe. David Soria Parra hat sehr anschaulich dargestellt, wie „Git für Fortgeschrittene” Probleme beseitigt, die viele von uns mittlerweile mit Subversion haben.

Nachmittags ging es mit einem Vortrag zu „Continuous Integration und Continuous Deployment” von Manuel Pichler weiter, von dem ich mir auch mehr erhofft hatte. Manuel hat die zwar Bewegründe für CI und wie man es schrittweise einführt schön zusammengefasst, der Teil über Deployment ist leider sehr kurz ausgefallen und war für mich leider nicht hilfreich, da wir täglich und nicht nur wöchentlich deployen.

Abgeschlossen habe ich den Tag mit der für mich langweiligsten Session der Webinale: „Positive User Experience durch User Centered Web Design”. Meine Experience war in diesem Vortrag nicht sehr positiv, was zum Teil auch an der fortgeschrittenen Uhrzeit gelegen haben mag.

Dienstag

Der Dienstag morgen begann mit einem Vortrag zu „Frontend Performance mit PHP” von Frank und Nico, der sehr gut besucht war und mir auch noch ein paar neue Impulse gegeben hat, obwohl ich natürlich wußte, was auf mich zu kommt.

Da sich Jung von Matt für die aktuelle 1&1 Kampagne verantwortlich zeigt, habe ich mir danach die Session „Künftig entscheidend für den Erfolg (fast) jeder Marke: Produktinfo und -inszenierung” von Michael Behrens angeschaut. Die Beispiele, die er gezeigt hat, waren interessant, jedoch weit weg von dem, was JvM für 1&1 macht. Deutlich cooler waren auch die Beispiele, die Michael Chaize in seiner Session „Ten Innovative Projects for the Flash Platform” gezeigt hat. Von 3D-Grafiken über Gesichtserkennung bis hin zur Emulation von Spielekonsolen war da für jeden was dabei. Flash scheint (leider) trotz HTML5 immer noch nicht tot zu sein.

Durch das ständige Vertauschen von Sessions habe ich leider mittags einige Sessions verpasst und die Zeit genutzt, was für’s Büro zu programmieren. Abgeschlossen habe ich den Tag mit einer spontanen Session zu YQL von Yahoo!, in der leider nur die Standard-Beispiele gezeigt wurden.

Mittwoch

Den Mittwoch habe ich nach dem Hotel-Checkout wieder mit zwei Keynotes auf der Webinale begonnen. David Carr hat in seiner Keynote „The Speed of Now” den Namen zum Programm gemacht und ist extrem schnell durch eine Masse an Slides gegangen, so dass man ihm kaum noch folgen konnte. Ossi Urchs Keynote „Social Web oder Die neue Macht der Nutzer” klang eher nach einer Keynote von 2008 als nach einer Keynote in der man Trends für 2011 erfahren hätte. Das allgegenwärtige „Twitter, Facebook und Smartphones beherrschen unser Leben!” wurde am dritten Tag der Webinale dann doch etwas alt.

Danach fand die Panel Diskussion „Holy Code, holy Shit! – Die Developer-Designer-Hölle” statt, an der ich auch beteiligt war. Leider war es organisatorisch nicht möglich, dass sich alle Teilnehmer vorher treffen, so dass hier keine wirkliche Diskussion entstand und es eher bei „Thema verfehlt” einzuordnen war. Sollte ich jemals wieder an einer Panel-Diskussion teilnehmen, dann nur, wenn es vorher auch möglich ist, sich mit den anderen Teilnehmern und vor allem dem Moderator abzustimmen.

Nach der Mittagspause war ich dann mit meinem Vortrag „23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten” dran.

Der Vortrag lief gut, ich habe mir auch meinen „Cowboy/Indianer”-Witz merken können und das Feedback war durchweg positiv. Abgeschlossen habe ich den Tag mit einem Vortrag von Frank zum Thema „A better Approach for File System dependent tests”, in dem Frank sein Projekt vfsStream vorgestellt hat.

Zusammenfassend hat sich der Besuch der Konferenzen für mich mehr gelohnt, als das in den letzten Jahren der Fall war. Tatsächlich habe ich während der Konferenz jedoch festgestellt, dass mich die Themen der Webinale mittlerweile mehr fesseln als die Sessions auf der PHP Conference.

Dann gibt es jetzt die Lösung: Verwenden Sie einfach „Planning Dice”. Mit „Planning Dice” können Sie jede Aufgabe innerhalb kurzer Zeit abschätzen, ohne dass Sie dafür wertvolle Entwickler-Ressourcen von der Software-Entwicklung abziehen.

Wie funktioniert „Planning Dice”?

Drucken Sie sich den „Planning Dice”-Bausatz aus und schneiden die Vorlage aus. Falten Sie den Bausatz an den vorgegebenen Linien und nutzen Sie die Klebeflächen, um den „Planning Dice”-Bausatz zu fixieren. Verwenden Sie dazu handelsüblichen Papierkleber oder bestellen Sie das Original-„Planning Dice”-Klebeset.

Nun sind Sie nur noch Sekunden davon entfernt, langwierigen Planungsmeetings Adieu zu sagen. Um den Aufwand einer Aufgabe zu schätzen, denken Sie einfach fest an die Aufgabe und lassen Sie den „Planning Dice” aus Ihrer Hand auf einen Tisch gleiten. Der „Planning Dice” wird Ihnen den Aufwand auf der zum Himmel gewandten Fläche anzeigen. „Planning Dice” paßt sich automatisch an die Größe Ihrer Aufgaben und das Know-How Ihrer Entwickler an, so dass die Werte als Stunden, Tage, Wochen oder Mannmonate zu interpretieren sind. Sollten Sie streng nach Scrum implementieren, so zeigt Ihnen „Planning Dice” natürlich Story Points an.

Sollte „Planning Dice” ein „?” anzeigen, so hat „Planning Dice” noch nicht all benötigten Informationen für eine verläßliche Schätzung. Fokussieren Sie sich erneut auf die zu schätzende Aufgabe und wenden Sie danach den Planning Dice erneut an.

Der Bausatz

Probieren Sie „Planning Dice” noch heute aus und überzeugen Sie sich von den beeindruckenden Ergebnissen. Laden Sie dazu „Planning Dice” hier herunter.

„Planning Dice” und große Projekte

Wir erhalten oft Anfragen von Projektmanagern, die die Vorteile von „Planning Dice” auch in großen Projekten einsetzen möchten und Planungen auf Vorstandsniveau in Sekunden erstellen wollen. Auch dies ist natürlich mit „Planning Dice” möglich.

Laden Sie sich dazu einfach einen zweiten „Planning Dice” herunter und befragen Sie gleichzeitig beide „Planning Dice”. Die angezeigten Werte müssen dabei einfach miteinander multipliziert werden und Sie erhalten die korrekte Schätzung für Ihr Projekt.

Natürlich skaliert „Planning Dice” noch weiter und Sie können die komplette Ressourcenplanung für das nächste Jahr mit Hilfe von zehn „Planning Dice” innerhalb weniger Sekunden erledigen. Vorbei ist die Zeit, in der Sie mühsam die Roadmap durcharbeiten mussten, um die Grobschätzung der benötigen Projektpersonentage für das nächste Jahr zu ermitteln.

Vielen Dank an Sebastian Lorenz, der diese nette Idee mit mir gesponnen hat.

Dieser Satz ist ein bequemer Weg, um eine Entscheidung zu begründen. So unwahr dieser Satz in der Politik ist, genauso unwahr ist es, wenn es um Software-Entwicklung oder das Management von Entwicklungs-Teams geht. Wenn jemand Ihnen glauben machen will, dass Sie unbedingt eine Rules Engine/Scala/PHP/einen Application Server einsetzen müssen, um ein Problem zu lösen und das damit begründet, dass das der einzige Weg ist, das Problem zu lösen, dann schauen Sie besser genauer hin.

Statt des einzigen Wegs ist es meistens eher der einzige Weg, den die entsprechende Person kennt, oder der, bei dem er nichts neues lernen muss oder sogar der, der einem Consultant das meiste Geld bringt.

Die Gründe für die scheinbare Alternativlosigkeit werden Ihnen natürlich nicht mitgeteilt. Mit dem Satz „Es gibt keine Alternative.” wird nur versucht, eine Diskussion über mögliche Wege von Anfang an zu unterbinden.

Der französische Soziologe Pierre Bourdieu hat für dieses Muster den Begriff „TINA-Prinzip” geprägt, in Anlehnung an die Anfangsbuchstaben von „There Is No Alternative.” Passend dazu hat die Politikwissenschaftlerin und ehemalige Greenpeace-Vorstandsmitglied Susan George dem TINA-Prinzip den Aufruf „TATA!” entgegengestellt:

There Are Thousands of Alternatives!

Ob Sie dem TINA- oder dem TATA-Prinzip folgen, liegt bei Ihnen, Sie haben die Alternative.

Entdeckt in „Zack and Miri Make a Porno” von Kevin Smith. Unbedingt beim Text zuhören, oder einfach die Lyrics lesen.

Das wollte ich mal zum Anlass nehmen, eine Liste von Wörtern und Redewendungen aufzustellen, die ich (zumindest im Berufsleben) nicht mehr hören möchte, besonders wenn es um Aufwand, Lösungen oder Termine geht.

„sollten”, „müssten”, etc.

Der Konjunktiv ist der Feind einer jeden Projektplanung. Meistens verrät er einem nicht, unter welchen Bedingungen ein Arbeitspaket rechtzeitig fertig wird, oder unter welchen Bedingungen der Code wie erwartet funktioniert. Wenn Sie den Konjunktiv im Berufsleben hören, dann nehmen Sie so schnell wie möglich Reißaus.

„sollen”

„Sollen” ist der kleine Bruder von „sollten” aber fast genau so schlimm. Was machen Sie, wenn Sie in einem Anforderungsdokument einen Satz wie „Die Antwortzeit des Service soll unter 200 Millisekunden liegen.” vorfinden? Ist das eine freundliche Bitte oder eine zwingende Anforderung? Was passiert, wenn diese Anforderung nicht erfüllt wird? Beim Einsatz des Verbs „sollen” bewegen Sie sich in einer Grauzone.

„einfach”, „nur”, etc.

In der Software-Entwicklung gilt nicht „Weil einfach einfach einfach ist.”. Zwei Situationen sind fast nie identisch, das heißt, wenn heute etwas funktioniert hat, haben Sie keine Gewißheit, dass es morgen genau so funktioniert. Die Vokabeln „einfach” oder „nur” werden meistens eingesetzt, um einen Sachverhalt zu verharmlosen oder die Komplexität zu verstecken. Wenn Sie diese Wörter hören, dann schauen Sie besser genau so hin. Aber vielleicht sehe ich das einfach nur zu eng.

„prinzipiell”, „eigentlich”, „normalerweise”

Ist der aktuelle Fall der Normalfall, oder wird jetzt gerade gegen das Prinzip verstoßen? Ich möchte nicht wissen, wann ein Arbeitspaket unter anderen Umständen eigentlich fertig wird, sondern wann genau in diesem konkreten Fall mit der Fertigstellung des Arbeitspaketes zu rechnen ist. Vor Jahren habe ich mit einem guten Freund gearbeitet, dessen Shop-Projekt monatelang „normalerweise nächste Woche fertig werden sollte”.

Was ist daran schlecht?

Warum möchte ich diese Wörter nicht hören? Sie machen es mir schwer, zu reagieren. Wenn das Projekt normalerweise pünktlich fertig gestellt werden sollte, dann sagt mir das das selbe, als würde das Projekt wahrscheinlich nicht rechtzeitig fertig und damit bin ich wieder genau so schlau wie vorher.

Ein „Wir hatten Probleme mit den Unit-Tests und werden nicht zum geplanten Termin fertig. Es dauert eine Woche länger.” zeigt mir klar, woran ich bin und ermöglicht mir (und dem Team) Maßnahmen zu ergreifen. Es geht hier um Verbindlichkeit, die nötig ist, um entsprechend reagieren zu können. Ob dies bedeutet, einfach Funktionalitäten außen vor zu lassen, um den Termin zu halten, oder stattdessen den Termin zu verschieben, hängt vom Projekt ab.

Aber warum hört man diese Wörter trotzdem so oft, wenn es darum geht, einen Termin zu bestätigen oder frühzeitig abzusagen? Meistens möchte man damit schlechte Nachrichten vermeiden und hofft, den Termin doch noch irgendwie zu halten. Damit wird die schlechte Nachricht in den meisten Fällen jedoch nur verschleppt, wenn der Termin nicht doch noch, wie durch ein Wunder, gehalten werden kann.

Wie kann man es verhindern?

Erschießen Sie nicht den Überbringer der schlechten Nachricht und schaffen Sie eine Kultur, in der man eigene Fehler zugeben und schlechte Nachrichten überbringen kann, ohne mit Sanktionen rechnen zu müssen. Belohnen Sie Verbindlichkeit und signalisieren Sie so, dass es Ihnen lieber ist, früh die schmerzhafte Wahrheit zu erfahren, anstatt sich lange in trügerischer Sicherheit zu wiegen.

Probieren Sie einfach, dann sollte das eigentlich auch in Ihrem Team funktionieren.

Unterstützt wird John Rambo dabei von der Vietnamesin Co Bao, in die er sich während seines Einsatzes verliebt und von Captain Vinh getötet wird. Rambo schwört Rache und befreit die Kriegsgefangenen unter Einsatz seines eigenen Lebens aus den Klauen des Vietcong.

Vor ihrem Tod führen Rambo und Co Bao die folgende Unterhaltung.

Rambo: „Ach weißt Du, ich bin entbehrlich.”
Co Bao: „Was bedeutet entbehrlich?”
Rambo: „Das ist so, als wenn man zu einer Party eingeladen wird, und dann nicht hingeht. Es spielt einfach keine Rolle.”
Co Bao: „Rambo, Du bist nicht entbehrlich.”

John Rambo ist also nicht entbehrlich. Doch was hat er davon? Immer wieder, wenn es Probleme gibt, muss Rambo sein Leben einsetzen, um diese Probleme zu lösen. Was das aus ihm gemacht hat, sieht man sehr gut im ersten Film der Rambo Reihe: In First Blood kommt Rambo aus dem Krieg zurück in eine Kleinstadt und ist so traumatisiert, dass er sich vom Sheriff provozieren läßt und einen Kleinkrieg anfängt. Am Ende des Films wird er von der Armee eingesperrt und erst wieder auf freien Fuß gesetzt, als man ihn bei einem Todeskommando braucht. Ähnlich ergeht es Rambo in den Jahren danach, statt Vietnam muss er in Rambo III nach Afghanistan. Selbst als er sich in „John Rambo” einen Altersruhesitz in Thailand aufbauen möchte, und wirklich keinen Ärger mehr sucht, kommt er nicht zur Ruhe. Stattdessen muss er eine Gruppe Missionare aus Burma retten, die nicht auf ihn hören wollten. Sein Leben wiederholt sich immer wieder.

Viele Software-Entwickler wollen so sein, wie John Rambo: unentbehrlich. Sie sind glücklich, wenn sie die einzigen sind, die wissen, wie man mit einer bestimmten Datenbank oder einer Legacy-Applikation umgeht. Wenn es Probleme mit dieser Datenbank oder dieser Anwendung gibt, dann muss man beim einzigen Entwickler vorsprechen, der sich damit auskennt und ihn bitten, diese Probleme zu lösen. Wenn man so manchen „unentbehrlichen” Entwickler reden hört, dann lassen sich diese Probleme auch nur, wie von John Rambo, unter „Einsatz des eigenen Lebens” lösen.

Auch wenn es anfänglich schmeichelt, immer dann gerufen zu werden, wenn es Probleme gibt, bringt diese Unentbehrlichkeit auch negative Seiten mit sich. Einem solchen Entwickler wird die Möglichkeit genommen, sich weiter zu entwickeln. Er bleibt auf der aktuellen Position sitzen, weil er ab und zu an dieser Stelle dringend gebraucht wird. So wie Rambo in Friedenseiten langsam zu einem Relikt aus alten Zeiten wird, geht es auch diesen Entwicklern. Und wenn die Systeme des Entwicklers sterben, so stirbt auch der Entwickler mit ihnen. Und wie John Rambo in Thailand, möchte ein Entwickler sich später einmal neu orientieren. So lange er in seinem alten Job nicht entbehrlich geworden ist, wird er dort immer zu jeder Tages- und Nachtzeit gerufen werden.

Falls Sie also ein „unentbehrlicher” Entwickler sind, lauet mein Rat an Sie: „Seien Sie nicht John Rambo, machen Sie sich entbehrlich.”

Entdeckt in Kailua-Kona auf Big Island. In Deutschland zu beziehen über HawaiianSun.de.