Motivation für Softwareteams V – FedEx Days

FexEx days wurden bei Atlassian erfunden. Viele unserer Produkte wie Team Calenders, Bonfire oder JIRA Mobile Connect entstammen einem FedEx Day. Wirklich alle profitieren davon: Das Unternehmen bekommt neue Ideen für Produkte geliefert, die Mitarbeiter einen Tag in dem sie ausprobieren können, was sie schon immer machen wollten. Aber fangen wir erst mal mit den Basics an:

Was ist ein FedEx Day?

An Atlassian’s “FedEx Day” nehmen sich Entwickler Zeit, sich mit irgend etwas zu beschäftigen, was (auch entfernt) mit unseren Produkten zu tun hat. Typerscherweise starten wir an einem Donnerstag Mittag, arbeiten bis 15:00 Uhr am Freitag und präsentieren dann das Ergebnis dem gesammten Unternhemen. Dies bedeutet also, dass man 24 Stunden Zeit hat, sein Ergebnis abzuliefern – daher auch der Name FedEx Day.

Die Ziele von FedEx sind:
– Kreativität fördern. Atlassian stellt eine Menge schlauer Köpfe ein. Es wäre dumm, diese nicht zu nutzen
– Jedem Entwickler stört etwas an unserem Produkten oder möchte sehen, dass es was bestimmtes tut
– Oft bekommen radikale Ideen nicht die notwendige Aufmerksamkeit, da viele den Nutzen daran nicht erkennen
– Spaß haben. Darf man ja auch mal auf der Arbeit 😉

Planung ist die halbe Arbeit

FedEx Days werden bei Atlassian gründlich vorbereitet. Auch wenn es sich danach anhört, dass man sich einfach nur eine Lösung überlegt und loscoded, hilft es, das ganze gut vorzubereiten. Im Vorfeld machen sich die Entwickler schon mal Gedanken, wie sie ein Problem lösen wollen, zeichnen MockUps und untersuchen Technologien. Zu jedem FedEx Day wird ein Organisator bestimmt, der 2-3 Meetings bei Pizza und Bier einberuft, um sich über Ideen für Projekte zu einigen.

Den Gewinner feiern

Am Ende jedes FedEx Days werden die Ergebnisse des 24 stündigen Hackathons den anderen Teilnehmener vorgestellt. Dann wird ein Gewinner gekührt, der eine Trophäe und ein T-Shirt erhält und bis zum nächsten FedEx Day mit dem Titel angeben darf. FedEx Days werden bei Atlassian in jeder Nierlassung auf der ganzen Welt abgehlaten. Letztes Jahr sind die Gewinner der letzten 4-5 FedEx Days dann zu einem FedEx Day World Cup angetreten.

Was passiert mit den tollen Ideen?

Einige Ergebnisse von FedEx Days haben es schon in unsere Produkte geschafft. Beipsielsweise die Plattform für unseren OnDemand Service oder die Vergleichsansicht in Fisheye. Natürlich ist es toll, wenn sich ein Projekt aus einem FedEx Day in einem unserer Produkte wiederfindet. Es geht aber vielmehr bei dem Ereignis darum, miteinander Spaß zu haben und seiner Leidenschaft nachzugehen.

Gut für Ihr Unternehmen?

Bei uns funktionieren FedEx Days super. Aber auch wir ändern ständig etwas am Konzept. Wir benutzen dazu eine Seite im unseren internen Confluence Wiki. Nachdem ich mir die Seite mit den Verbesserungsvorschlägen durchgelesen habe, konnte ich feststellen, dass sich die meisten Verbesserungen um die Pizzabestellung drehen – ein wichtiger Bestandteil von FedEx Days.

Andere Unternehmen wie Sonar6, Adobe, Yahoo und Xing haben so etwas wie FedEx Days durchgeführt. Dank Dan Pinks TED Talk sind FedEx Days bekannter geworden. Hier das Video mit Illustrationen dazu.

Mehr über FedEx Days gibt es auf unserer Webseite.

Noch immer nicht motiviert?

Hier gibt’s mehr:

Einführung
Teil 1: DogFooding
Teil 2: Unterbrechungen vermeiden
Teil 3: Anerkennung
Teil 4: Brown Bags

Teil 6: 20% Time
Teil 7: Spaß haben und Gutes tun

Motivation für Softwareteams IV – Brown Bags

Kontinuierliches Lernen sollte bei jedem Softwareentwickler zur Arbeit dazugehören. Jetzt weiß ich auch, dass dies bei der täglichen Projektarbeit schnell mal vergessen wird. Auch liegen die Prioritäten meist eher beim Tagesgeschäft als bei der perspektivischen Weiterentwicklung. Selbst wenn der Chef nichts gegen Weiterbildung hat, gibt es immer wichtigere Aufgaben, Deadlines und Präsentationen für Vorstandsmeetings. Dazu kommt dann noch, dass mancher Mitarbeiter einfach nicht aus seinem Saft rauskommt und freiwillig kein Fachbuch in die Hand nimmt. Man sollte sich dann natürlich erst mal fragen, ob das der richtige Job für ihn ist, aber das ist ein anderes Thema. Brown Bags kann diese Mitarbeiter motivieren, mal etwas Neues auszuprobieren und wer weiß, vielleicht platzt ja bei einigen Kollegen der Knoten sich doch beispielsweise einmal mit dem Play-Framework zu beschäftigen.

Präsentationen zum Mittag

Brown Bags sind eine tolle Form von Wissenstransfer im Team und im Unternehmen. Man trifft sich zum Mittag gemeinsam in einem Meetingraum und ein Mitarbeiter hält eine Präsentation über eine neue Technologie, Programmiersprache oder neue Arbeitsmethode. Dabei nimmt man sein Essen mit – in einer braunen Tüte, daher der Name Brown Bag. Es wird also keine Arbeitszeit verbraten. Man kann sich eventuell auch einen solchen Lunch mit Brötchen oder Pizza vom Unternehmen sponsern lassen. Allerdings gehört dazu immer ein Präsentator, der ein Thema vorbereitet. Auch das kostet Arbeitszeit. Brown Bags haben gegenüber Expertenpräsentationen den Vorteil, dass die Hemmschwelle Fragen an den direkten Kollegen zu stellen natürlich geringer ist. Man sieht nicht gleich wie ein Idiot aus, wenn man die grundlegende Idee nicht ganz verstanden hat. Die Diskussion wird dadurch gefördert und das ist der beste Weg etwas Neues zu lernen.

Synergien nutzen

Oft bietet es sich auch an, mit anderen Unternehmen gemeinsam Brown Bags, Coding Dojos oder Open Spaces zu veranstalten. Man schmort somit nicht in seinem eigenen Saft. Man kann mit einem solchen Zusammentreffen viel von dem anderen Partner lernen.

Keine Idee/Zeit für Präsentationen

Manchmal fehlt einfach die Zeit oder eine gute Idee für eine Brown Bag-Präsentation. Hier kann man sich Konferenz-Talks anschauen. Ich habe mein Team alle 14 Tage 3 Talks zum Abstimmen gegeben. Den Talk mit den meisten Stimmen haben wir uns freitags nachmittags gemeinsam angeschaut und danach darüber diskutiert.

Gar keine Vorbereitungszeit braucht ein Unternehmens-Open Space. Hier schlägt man einfach Themen vor, über die diskutiert und gemeinsam recherchiert werden kann. Meist kostet diese Art des Treffens ein wenig mehr Zeit, da es keinen „Experten“ gibt. Ein solches Vorgehen hat aber den Vorteil, dass man sich das Ergebnis selbst erarbeitet hat, anstatt es nur präsentiert zu bekommen.

Eine Coding-Session ist das Gleiche für Software. Man trifft sich meist abends bei Pizza und Bier, um ein paar Zeilen Code zu hacken. Dabei kann man neue Technologien oder Programmiersprachen ausprobieren. Das macht richtig Spaß. Man sollte sich allerdings ein kleines Projekt aussuchen, damit man einen reellen Bezug bekommt.

Auf alle Fälle sind selbst organisierte Treffen eine tolle Möglichkeit, der täglichen Projektarbeit zu entkommen und sich mit neuen Ideen zu beschäftigen. Dies motiviert unheimlich für die tägliche Arbeit. Ich habe mich immer sehr darauf gefreut, mal ein paar Zeilen abends in JavaFX zu hacken, ohne dass dies eine Relevanz für meine tägliche Arbeit hatte.

Noch immer nicht motiviert?

Hier gibt’s mehr:

Einführung
Teil 1: DogFooding
Teil 2: Unterbrechungen vermeiden
Teil 3: Anerkennung
Teil 5: FedEx Days
Teil 6: 20% Time
Teil 7: Spaß haben und Gutes tun

Motivation für Softwareteams III – Anerkennung

Wie motiviert man Programmierer? Mit einer besseren Bezahlung? Mit einem Bonus? Wie lange hält eine solche Motivation an? Bei mir ca. ein Monat. Dann habe ich entweder mit dem Bonus gerechnet oder mich an die höhere Bezahlung gewöhnt. Es hat in meinem Arbeitsleben dann keine Rolle mehr gespielt. Auch habe ich mich eher mit Zielen beschäftigt, die mich und mein Team vorangebracht haben, obwohl diese nicht in meiner Zielvereinbarung standen. Es kommt noch dazu, dass Ziele meist nur einmal pro Jahr festgelegt werden. Somit verliert man das Ziel schnell aus den Augen. Ich habe am Ende des Jahres immer meine Zielvereinbarung rausgeholt und über die alten Ziele geschmunzelt, die nicht erreicht wurden, allerdings auch nicht mehr wichtig für das Unternehmen waren.

Aber genug über Motivation durch Bezahlung und Zielvereinbarungen. In diesen Teil meiner Blog-Serie geht es um Anerkennung. Meiner Meinung nach, der beste Motivator. Dabei unterscheide ich zwischen Anerkennung durch Kollegen und dem Gefühl in einem selbst, eine Aufgabe gemeistert zu haben.

Das Risiko eingehen

Ich habe schon oft erlebt, dass ich den Mund sehr voll genommen habe, um eine neue Technologie oder eine andere Idee in die Realität umsetzen zu dürfen. Wenn ich also bei meinem Chef war und ihm von einer meiner Ideen überzeugt habe, bin ich danach wieder an meinem Schreibtisch zurückgekehrt und habe gedacht: „Ach du meine Güte… jetzt musst du das tatsächlich abliefern…“ Auch wenn ich von der Idee überzeugt war.  Dann habe ich mich natürlich ziemlich reingehängt, um auch das tatsächlich versprochene Produkt abzuliefern. Wenn ich es tatsächlich geschafft habe, war das Gefühl überwältigend. Wenn ich es nicht geschafft habe (und das war viel seltener der Fall), habe ich mir zwar eine blutige Nase geholt, aber ich habe  immer daraus gelernt und trotzdem meinen Job behalten. Diese innere Anerkennung nach einem Erfolg ist der größte Motivator immer wieder mal, etwas Neues auszuprobieren.

Anerkennung durch andere

Wir bei Atlassian verteilen regelmäßig Kudos. Das ist eine Anerkennung, wenn ein Kollege etwas besonderes gemacht hat. Man kann Mitarbeiter bei uns über JIRA für Kudos eintragen. Jeder Mitarbeiter hat die Möglichkeit 2 mal im Jahr einen Kollegen für Besonderes zu nominieren. Dabei handelt es sich nicht immer über besonders gute Arbeitsleistungen. Hier ein paar Beispiele, wofür Atlassianer Kodus bekommen haben:

Die Mitarbeiter, die Kudos erhalten haben, werden im Atlassian Intranet veröffentlicht und bekommen eine kleinen Preis – beispielsweise eine Flasche Wein oder Karten fürs Kino. Der Unterschied zum Mitarbeiter des Monats (den ich sehr demotivierend finde), ist der, dass jeder Kollege was besonderes machen kann. Nicht nur die Rock Star Programmierer! Zusätzlich ist es von Vorteil, dass das Management nicht beteiligt wird (Obwohl man einen Manager auch Kudos geben kann :-)). Dies funktioniert natürlich nur in einer freundlichen Arbeitsumgebung, bei der jeder jeden respektiert und sich auch über den Erfolg anderer freuen kann.

Ein System im Unternehmen zu schaffen, das besondere Leistung hervorhebt und diese publik macht ist ein guter Motivator. Dabei sollten nicht die großen Unternehmensziele im Vordergrund stehen, sondern vielmehr die kleinen Dinge. Diese machen die tägliche Arbeit besonders. Unerwartete Anerkennung von anderen zu bekommen, ist ein tolles Gefühl und motiviert für mehr. Also, sagen Sie öfter: Kudods dafür!

Noch immer nicht motiviert?

Hier gibt’s mehr:

Einführung
Teil 1: DogFooding
Teil 2: Unterbrechungen vermeiden
Teil 4: Brown Bags
Teil 5: FedEx Days
Teil 6: 20% Time
Teil 7: Spaß haben und Gutes tun

Motivation für Softwareteams II – Unterbrechungen

Nichts demotiviert einen Softwareentwickler mehr, wenn man nicht zum Programmieren kommt. Wir sind Programmierer und wollen nicht ständig unterbrochen werden oder unsere Zeit in nicht relevanten Meetings verbringen. Dieser Teil meiner Blog-Serie handelt also darum, dass Entwickler wieder mehr Zeit bekommen, sich um den Code zu kümmern. Mich hat es als Team Leiter mit Entwicklungsanteil immer wieder motiviert, sich wirklich einen Tag lang um den Code zu kümmern. Das macht Spaß!

It is Coding Time!

Hiermit schließt man einfach die gesamte Softwareentwicklung gegen Störungen für ein paar Stunden am Tag. Während dieser Zeit kann man sich dann ausschließlich ums hacken kümmern. Telefongespräche sollten während dieser Zeit vermieden und die Telefone auf Stumm geschaltet werden. Ein Schild an der Tür weist darauf hin, dass Störungen nur im Notfall gestattet sind. Auch kann ich empfehlen, während dieser Zeit das Emailprogramm zu schließen. Kann eine Diskussion mit einem Kollegen nicht bis nach der Codezeit warten, sollte man sich außerhalb der Coding-Area unterhalten, um andere Mitarbeiter bei Ihrer Konzentration nicht zu stören.

Wie denkt das Management oder andere Abteilungen darüber, wenn spontane Ideen nicht mehr sofort an die Programmierer rangetragen werden können, oder dass eine Anfrage maximal 3 Stunden liegenbleibt? Ich habe die Erfahrung gemacht, dass darauf positiv reagiert wird. Andere Abteilungen oder auch der Chef selber würden auch gerne eine Zeit einführen, in der sie ungestört arbeiten können. In der Anfangsphase braucht es ein wenig dicke Haut, um Kollegen auf die Codingzeit hinzuweisen. Aber nach ein bis zwei Wochen hat jeder diese Zeit am Tag für sich abgespeichert. Man weiß, dass man die Softwareentwicklung während dieser nicht ansprechen kann.

Was die beste Zeit am Tag ist und wie lang diese Zeit sein sollte ist natürlich sehr individuell. Bei uns hat sich die Zeit nach dem Mittag bis 16:00 als sehr praktikabel erwiesen,  da man schon alle wichtigen Emails beantwortet hat und  das Stand Up schon gelaufen ist.

Und dann? Programmieren, in den Flow kommen und mal richtig was schaffen!

Der, der den Hut auf hat!

Eine andere Möglichkeit, Unterbrechungen zu vermeiden, ist die Rolle des Ansprechpartners. Hier wird ein Mitarbeiter ausgewählt, das Team zu repräsentieren. Alle Anfragen gehen an ihn. Um den Kollegen für andere Abteilungen als Ansprechpartner sichtbar zu machen, kann dieser einen bestimmten Hut aufsetzen. Er hat dann für den Tag für Supportfragen den HUT auf,  oder man stellt eine Figur oder Trophäe auf den Schreibtisch, die ihn eindeutig als Ansprechpartner ausweist. Am nächsten Tag übernimmt dann ein anderer Mitarbeiter diese Rolle. Das setzt allerdings voraus, dass es im Team keine ultimativen Spezialisten gibt sondern jeder theoretisch den Job des anderen übernehmen kann.

Manchmal kann man nicht alle Fragen selbst beantworten und man braucht den Rat eines Team-Kollegen. Hier kann man dann Anfragen in einem Ticketsystem wie JIRA festhalten und dem Mitarbeiter zuordnen. Dieser kann dann die Anfrage bearbeiten, wann es ihm zeitlich passt.

Nach meiner Meinung können 90% aller Anfragen durch Kollegen warten. Es gibt nur sehr wenige Ausnahmen, bei dem eine Antwort oder Aktion sofort benötigt wird. Nur weil jemand eine gute Idee hat und somit aus seiner Konzentration  gerissen wurde, heißt es nicht, dass er andere stören kann. Wir arbeiten nicht alle an Software für Kernreaktoren, deren Super Gau gerade bevorsteht, wenn wir nicht einen boolschen Ausdruck sofort umdrehen. Endlich Zeit zu haben, sich um den Code zu kümmern, ist für Programmierer ein Supermotivator!

Noch immer nicht motiviert?

Hier gibt’s mehr:

Einführung
Teil 1: DogFooding
Teil 3: Anerkennung
Teil 4: Brown Bags
Teil 5: FedEx Days
Teil 6: 20% Time
Teil 7: Spaß haben und Gutes tun

Motivation für Softwareteams I – Dogfooding

In der Softwareentwicklung bedeutet Dogfooding, dass Programmierer ihre eigenen Softwareprodukte benutzen sollen. Populär wurde das ganze 1988 durch Microsoft gemacht. Seit dem gibt es diverse Erfolgsstories für Dogfooding.

Selber damit arbeiten

Das Konzept ist einleuchtend: Wenn Programmierer mit den Tools arbeiten, die sie auch entwickeln, sind diese viel schneller genervt von Programmfehlern und diese werden so auch viel schneller gefixt. Zusätzlich weiß man, dass die Software von Kollegen benutzt wird und nicht von einem anonymen Kunden. Dies führt dazu, dass ich mir beim Erstellen und bei der Usibility mehr Mühe gebe. Eine Kritik, die direkt vom Kollegen gegenüber kommt, fühlt sich um einiges realistischer an, als eine Email oder ein Eintrag im Bug-Tracking System. Dogfooding motiviert also Softwareentwickler, ein besseres Produkt zu bauen.

Programmierer als QA?

Selbstverständlich löst Dogfooding nicht die QA ab. Entwickler haben manchmal nicht den gleichen Blickwinkel, wie die tatsächlichen Nutzer der Software. Auch übersieht man gerne Unzulänglichkeiten in der Software, da man das dahinter liegende Framework / Design im Auge hat und weiß wie schwer es ist, die Funktionalität anders umzusetzen. Aber als Ergänzung zur QA ist dies eine tolle Praxis.

Internes Continuous Delivery

Wenn die Software ständig released wird, also die aktuelle Version aus dem Repository häufig auf die internen Produktivserver deployed wird (mindestens wöchentlich, besser häufiger), lernt man frühzeitig die Fallstricke beim Deployment. Man findet ziemlich schnell heraus, wenn ein Datenbankskript nicht funktioniert, oder man eine Konfigurationsdatei vergessen hat. Gleiches gilt natürlich auch für die Funktionalität der Software. Auch wenn man kein externes Continuous Delivery machen kann, erhält man zumindest durch Dogfooding viele Vorteile dieser Methode. Die Feedback-Zyklen verkürzen sich und Probleme können somit schnell behoben werden. Dies geschieht dann meist sehr zeitnah mit der Implementierung der Funktionalität, so dass Entwickler noch genau wissen, wo und wie sie den Code fixen können, ohne lange suchen zu müssen.

Dogfooding bei Atlassian

Wir bei Atlassian arbeiten mit unserer eigene Software, bevor diese unsere Kunden benutzen. Wir steuern (fast) alle Workflows intern über JIRA. Und glaubt mir: Wir sind die härtesten Kritiker! Man findet ziemlich schnell heraus, wenn etwas nicht funktioniert und unser Workflow dadurch gestört ist. Die Entwickler reagieren ziemlich schnell mit einem Fix, da sie natürlich nicht die Arbeit anderer Kollegen stören wollen. Momentan testen wir JIRA 5 auf Herz und Nieren! Da wir Confluence natürlich als unsere Intranet-Software einsetzen, ist das ganze Unternehmen vom Marketing über Human Resource bis hin zur Dokumentation am Dogfooding beteiligt. So also auch bei der Einführung von Confluence 4. Hätten wir die Version nicht selber für 8 Monate getestet, hätten beispielsweise die neuen Autovervollständigungs-Funktionen auf einer deutschen Tastatur nicht funktioniert.

Motivation? Häh?

Klar! Dogfooding motiviert, bessere Software zu bauen und wer will heutzutage kein Continuous Delivery machen und beim Hype dabei sein?

Noch immer nicht motiviert?

Hier gibt’s mehr:

Einführung
Teil 2: Unterbrechungen vermeiden
Teil 3: Anerkennung
Teil 4: Brown Bags
Teil 5: FedEx Days
Teil 6: 20% Time
Teil 7: Spaß haben und Gutes tun

Motivation für Softwareteams

Am Anfang eines Softwareprojektes ist die Motivation des Teams hoch. Jeder Entwickler ist heiß darauf, ein tolles innovatives Produkt zu entwickeln. In dieser Phase hat man sehr viel Spaß und arbeitet eventuell Tag und Nacht, damit das Produkt rechtzeitig auf den Markt kommt. Auch ist der Fortschritt der Softwareentwicklung, also die Produktivität der Programmierer, in dieser Zeit rasant. Neue Ideen und Innovationen können sofort umgesetzt werden und das Team wächst zusammen.

Meist stellt sich dann aber (nach einiger Zeit der Euphorie) der Alltag ein. Wie aber erhält man die Innovation im Team und den Willen ein perfektes Produkt zu bauen, welches Benutzer auch nach Jahren noch mit neuen Features fasziniert?

Motivation 1.0 = fail

Einige Manager glauben immer noch, Mitarbeiter könnten über Bonuszahlungen motivieren werden. Verschiedene Wissenschaftler haben das aber  bereits wiederlegt. Durch Bonuszahlungen werden meist keine Innovationen gesteuert und laut Daniel H. Pink sogar die intrinsische Motivation zerstört. Noch letzte Woche habe ich eine Umfrage gelesen, die eingefahrene Modelle, wie einen Dienstwagen oder ein Handy vom Arbeitgeber als mögliche Maßnahme die Motivation zu steigern, vorgeschlagen haben. Ich finde, dass dies wahrscheinlich einfach für das Unternehmen ist, aber den Mitarbeiter längerfristig nicht innovativer und glücklicher in seiner täglichen Arbeit macht.

Motivation 2.0 = Nicht mehr demotiviert

In den letzten Jahren haben wir durch die Einführung agile Methoden sicherlich schon viel dazu beigetragen, dass Softwareprodukte besser werden und Entwickler zufriedener. Wir haben den Product Owner eingeführt und damit den Anforderer mit ins Boot geholt, um genau das zuerst zu entwickeln, was dem Kunden am schnellsten hilft. Der Entwickler ist motivierter, da er sofort Feedback vom Kunden erhält. Er sieht also schnell, dass seine Arbeit einen Nutzen hat. Durch Iterationen haben wir eine gewisse Planungssicherheit eingeführt und einen Prozess, wie Anforderungen in das Projekt eingekippt werden und man Prioritäten der einzelnen Features schnell ändern kann. Für mich bedeutet Agilität aber noch viel mehr: Sich ständig selbst zu hinterfragen, ob es nicht doch noch besser geht.

Motivation 3.0 = Erfolg

Wir bei Atlassian haben hierzu verschiedene Ansätze ausprobiert, sind auf die Nase gefallen, wieder aufgestanden, haben neue Sachen getestet und auch mal Erfolg gehabt. In einer Blogserie werde ich die Dinge vorstellen, die unsere Entwicklung über Jahre hinweg mit Innovationen bereichert haben.  Unter anderem haben diese Motivations- und Innovationstechniken uns dabei geholfen, einer der erfolgreichsten Hersteller für Entwicklertools der Welt zu werden.

In den nächsten Wochen werde über Methoden schreiben wie

  • FedEx Days
  • 20-Prozent-Zeit
  • Dogfooding
  • Ablenkungen minimieren
  • Brown Bags
  • und noch einiges mehr…

Ich bin kein Motivationscoach, sondern nur ein Softwareentwickler, der gespannt darauf ist, wie man langfristig Programmierer an einem Projekt mit Spaß arbeiten lassen kann und dabei den Drive und die Qualität des Produktes beibehält.

Bereit, motiviert zu werden?

Teil 1: DogFooding
Teil 2: Unterbrechungen vermeiden
Teil 3: Anerkennung
Teil 4: Brown Bags
Teil 5: FedEx Days
Teil 6: 20% Time
Teil 7: Spaß haben und Gutes tun

5 Trends der Softwareentwicklung auf der Devoxx 2011

Die Devoxx dieses Jahr war mal wieder Wochen vorher ausverkauft. Es wird vermutet, dass die Konferenz mit ca. 3200 Teilnehmern die größte Java-Konferenz der Welt ist (Oracle rückt ja leider nicht mit den absoluten Zahlen zur Java One raus), obwohl es schon lange nicht mehr nur um Java geht. Solche Konferenzen zeigen meist die Trends in der Softwareentwicklung auf. Dies bedeutet aber auch, dass die Themen nicht immer eine Relevanz für die tägliche Arbeit haben, aber durchaus Denkanstöße geben können. Unterhaltend war wie immer auch die Session der Java Posse:

Hier aber jetzt meine Top 5 Trends dieser Devoxx:

1. Software Craftsmanship ist auch nur Buzz

Oh ja! Die Stimmen auf dieser Devoxx vermehrten sich, dass wir uns doch lieber mehr ums programmieren kümmern sollten, als nur darüber zu reden. Wir sind halt keine Ärzte und bei unserer Software geht es (meist) nicht um Menschenleben. Dick Wall stellte sich deutlich gegen den Begriff “Bewegung”. Man sollte viel mehr auf seine eigenen Erfahrungen bauen anstatt immer Best Practices zu befolgen. Am meisten lernt man aus Misserfolgen. In dem nicht immer ernst gemeinten Diabolic Developer Vortrag stellte Martijn Verburg akzeptierte Practices wie DRY auf den Kopf, indem er genau das Gegenteil behauptete. Seine Grundaussage war: “Wir sollten nur noch hacken und uns um nichts anderes mehr scheren, Tests sind was für Angsthasen!” Dennoch hat der Vortrag zum Denken angeregt, ob  wir wirklich den ganzen Firlefanz um die Softwareentwicklung herum brauchen.

2. HTML 5 (nicht nur) für hübsches UI

Ja, Web Apps sind wohl die Zukunft und HTML 5 ist ein heißer Kandidat, um diese umzusetzen. Deshalb waren wohl auch Talks so beliebt, die sich um diesen Noch-Nicht-Standard rankten. Erstaunliche UIs, unglaubliche Funktionalität im Browser und Offline-Apps waren heiße Themen auf der Devoxx.  Kein Platz war mehr frei beim Google Dart und HTML 5 Talk von David Chandler. Ich glaube aber, dass das noch der Google Bonus dieser Sprache und kein wirklicher Trend ist.

3. Android

Vielleicht lag es daran, dass Google das erste mal Hauptsponsor der Devoxx war, aber an Android kam man auf der Konferenz nicht vorbei (vielleicht auch weil Google leckeres Ice Cream Sandwich zur Mittagspause verteilt hat). Tools, UI-Design, App-Design, die Android-Themen waren unzählig. Ich habe mich ein wenig über den Hype gewundert. Wahrscheinlich haben sich alle JavaEE Entwickler mindestens einen Android Talk angeschaut, da die Entwicklung eines TouchUI mit Java so viel cooler ist als das aktuelle Spring Framework.

4. Java

Java ist immer noch unaufhaltsam auf dem Vormarsch. Sei es die JVM mit ihren täglich mehr werdenden Sprachen oder auch die Sprache selbst. Die JVM ist eine tolle Plattform für erfolgreiche Sprachen wie Scala, Groovy oder Clojure. Hierzu gab es unzählige Talks auf der Devoxx, wobei die Scala Vorträge immer noch die meist besuchten waren. Scheinbar ist aber auch Java als Programmiersprache noch immer beliebt. Gibt aber nichts neues zu berichten, so dass Joshua Bloch auch einen Vortrag über Java 1.1 gehalten hat.

5. JavaFX

Hier hat sich der Trend der JavaOne fortgesetzt. Oracle pusht JavaFX! Ob sich dieser Trend dann auch in der realen Entwicklerwelt fortsetzen kann, wird die Zukunft zeigen. Ich bin noch nicht so ganz überzeugt, ob Desktop Apps weiterhin in großer Stückzahl entwickelt werden. Schaun wir mal!

Zusätzlich zu den 5 Trends fand ich die Aufmerksamkeit auf ALM-Tools beachtlich. Continuos Delivery, DVCS, Code Reviews und Code Monitoring waren weitere heiße Themen dieser Devoxx. Scheinbar ist die Atlassian ToolSuite damit ziemlich trendy. Aber wo waren die Big Data Talks? Hab ich wohl verpasst 😦

Es ist Movember

Die Blätter fallen von den Bäumen, und die Bärte fangen an zu sprießen. Es muss Movember sein. Bei Atlassian nehmen dieses Jahr 84 Herren der Schöpfung an diesem Event teil.

Aber was macht man eigentlich im Movember?

Eigentlich gar nicht viel. Man hört nur auf, sich für einen Monat über der Oberlippe zu rasieren und läßt sich einen ordentlichen Schnäuzer wachsen. Eine Atlassian Jury, die nur aus Frauen besteht, kürt am Ende des Monats den besten Atlassian Oliba. Dabei ist jeder Atlassian Mitarbeiter aufgefordert, so viel Geld wie möglich zu sammeln (Spender zu akquirieren). Dieses Geld wird für die “männliche Gesundheit”, wie Prostata Krebs Bekämpfung, usw. gespendet. 

3, 2, 1 wachsen!

Auch ich lass mir (das erste Mal in meinem Leben) einen Bart stehen. Das ist diesen Monat besonders schwer, da ich auf 2 Konferenzen Vorträge halten werde, die auch noch auf Video aufgezeichnet werden. Da bin ich dann schön für die Ewigkeit mit einem Bart festgehalten. Super.

Spenden Sie jetzt

Da es sich um eine öffentliche Initiative  handelt, können auch Sie für meinen Bart spenden:
http://mobro.co/svenpet

Atlassian OnDemand – Die Zukunft sieht wolkig aus

Letzte Woche hat Atlassian Ihr neues Software as a Service (SaaS) Konzept vorgestellt: OnDemand heißt das Produkt und bietet die Möglichkeit, Atlassian Produkte durch Atlassian hosten zu lassen. Man kann einzelne Produkte an- und abwählen und bezahlt nur für Produkte, die man auch braucht. Atlassian nennt das “A la Carte”. Hierzu wurde eine komplett neue Plattform entwickelt. Wer sich wundert, warum im Promo-Video Einhörner über den Bildschirm reiten sie gesagt, dass der interne Name der Plattform “Unicorn” ist. Im internen Wiki wurden wir auch tagelang mit dem “Pink Fluffy Unicorns Dancing on Rainbow”- Video bombardiert.

Warum dieser Schritt meiner Meinung nach wichtig war:

JIRA Studio on Steroids

Die bisherige Host-Lösung von Atlassian hieß “JIRA Studio”. Hat Atlassian eine neue Version von Confluence veröffentlicht, hat es Wochen gedauert, bis diese auf der JIRA Studio Plattform veröffentlicht wurde. Updates wurden immer wieder verschoben und somit gab es immer neue Ankündigungen von Downtimes, die auch viel zu lange gedauert haben. Auf OnDemand veröffentlicht Atlassian Updates zeitgleich mit der Download Version. Mit JIRA Studio war es nicht möglich, nur bestimmte Produkte freizuschalten. Man musste sich für die gesamte Suite entscheiden und diese auch dann bezahlen. Die Reaktionszeit für Bugfixes ist bei OnDemand auch viel schneller, da man sich intern bei Atlassian intensiv über Continuous Delivery Gedanken gemacht hat. OnDemnad Updates und Bugfixes können mit nur einem Knopfdruck innerhalb von Minuten deployed werden. Auch die Bereitstellung der Tools geht binnen Sekunden, im Gegensatz zu JIRA Studio wo es auch mal 3 Wochen dauern konnte, bis die Instanz dem Kunden übergeben wurde.

Eating or own doogfood

Kunden berichten immer wieder, dass sie Probleme mit einigen Plugins beim Update haben. Das sorgt oft dafür, dass man Angst vor Updates auf neue Versionen hat, da man befürchtet, dass das System danach nicht mehr 100%ig läuft. Wir bei Atlassian haben diese Schmerzen nicht am eigenen Leib erfahren. Das ist jetzt anders. Beim Update merken wir selbst, dass die Kompatibilität zu von OnDemand supporteten Plug-ins nicht mehr besteht. Diese Updateschmerzen selbst zu spüren ist der beste Weg zu großartiger Software. Mit JIRA 5 werden wir endlich eine stabile Plattform zur Verfügung stellen, die auf Abwärtskompatibilität ausgerichtet ist.

Ideal für kleine Teams und StartUps

Für kleine Unternehmen bedeutet der Einsatz eines Tools einen zusätzlichen admistrativen Aufwand. Tools müssen installiert, gepatcht und upgedatet werden. Alles das macht Atlassian… mit einem Einstiegspreis von $10/Monat! Alles was nicht zur Kernkompetenz eines kleines Unternehmen gehört, sollte outgesourced werden. Das gilt auch für die Installation und den Betrieb von Entwicklungstools.  Atlassian OnDemand ist ideal für solche Unternehmen. Aber auch ist die neue Atlassian Cloud interessant für Softwareentwicklungsteams in Unternehmen, die von Atlassian Tools überzeugt sind, deren IT aber überlastet ist. Man hat die Möglichkeit, später die Daten auf die eigenen Server zu kopieren und Atlassian Produkte selbst hosten. Wenn man nicht auf spezielle Plugins oder Erweiterungen angewiesen ist, ist OnDemand eine tolle Lösung.

Die Zukunft sieht “cloudy” aus

Mehr und mehr Tools gehen in die Cloud. Erst waren es nur Email Dienste, die man im Browser benutzt hat. Heutzutage laufen sogar schon Musicplayer wie Simfy oder Spotify als Cloud-Service. Ganz zu schweigen von Apples iCloud. Es ist nur eine logische Konsequenz, auch seine Entwicklungstools in die Cloud zu verlegen. GitHub macht es schon. Allerdings sehe ich den Vorteil, dass man auch einfach mit den Atlassian Tools auf seine privaten Server umziehen kann (oder umgekehrt) und somit viel flexibler ist.

JavaOne 2011

Ich war vom 2. bis 6. Oktober auf der JavaOne in San Francisco. Auch dieses Jahr fand diese zusammen mit der Oracle Open World statt. 45.000 Teilnehmer! Während die Oracle World im Kongresscenter Moscone abgehalten wurde, hat man die JavaOne auf drei Hotels verteilt und die Strasse zwischen den Hotels gesperrt und zur Lounge umfunktioniert.

Video

Neues

Eine Menge Talks wurden angeboten und es wurden auch Neuigkeiten verkündet. Hier, die aus meiner Sicht wichtigsten:

  • JDK 8
    • Lambda Expressions mit “Default” methods
    • Modularität der JVM (Jigsaw); kleinstes Bundle soll 10MB betragen
    • verzögert sich noch bis Sommer 2013 😦
  • Project Nashorn: Javascript auf der JVM
  • Twitter wird OpenJDK und JCP Mitglied
  • Project Avatar: HTML 5 mit/und Java… Details wurden ausgelassen
  • JavaFX 2.0 wurde released
  • JavaFX wird in das OpenJDK Projekt integriert

Fazit

Leider ist die Lösung mit den 3 Hotels nicht optimal. Die Wege im Hilton Hotel sind zudem so kompliziert und verwirrend, dass ich 3 mal in irgendwelchen Treppenhäusern gelandet bin und mich dann auf der Hauptstrasse wiedergefunden habe. Zudem gibt es keinen gemeinsamen Treffpunkt, auf dem man Speaker oder alte Freunde  zufällig wiedertreffen kann. Eventuell lag es auch an dem Wetter, so dass man die Lounge auf der Mason Street nicht so gut nutzen konnte. Zudem fand ich, dass die Vortragsräume in den Hotels etwas von einem Zahnarztkongress ausstrahlten.

Inhaltlich ist es immer noch die wichtigste Java-Konferenz der Welt. So eine Dichte an bekannten Sprechern und Talks bietet wohl nur die JavaOne!