Agile / Software-Entwicklung / Veranstaltungen

Just another Global Day of Coderetreat 2014

Am Samstag, den 15. November, fand wieder der weltweit organisierte Global Day of Coderetreat (GDCR) statt. Dieses Jahr nahmen Entwickler aus der ganzen Welt an insgesamt 141 verschiedenen Orten teil  – von Auckland in Neuseeland bis nach Honolulu auf Hawaii. Auf der Landkarte sieht das fast aus wie zu Silvester, wenn von Ost nach West die Korken knallen, nur dass wir hier gemeinsam programmieren. Entwickler die gemeinsam 32 Stunden durch alle Zeitzonen den gleichen Spirit haben. Wahrscheinlich fragen sich einige, welche „Verrückte“ freiwillig ihr Wochenende mit Programmieren verbringen? Einer dieser „Verrückten“ war ich und dieser Blog erzählt von meinen Eindrücken und meiner Motivation.

Global Day of Coderetreat 2014

Der GDCR findet jährlich statt. Er wird von Enthusiasten organisiert und geleitet, unterstützt von globalen und lokalen Sponsoren. Diese Sponsoren ermöglichen, dass die Teilnahme gratis ist. Was jeder Teilnehmer mitbringen muss ist Motivation, Engagement, Offenheit um dazu zu lernen, Spaß am praktischen Arbeiten und Interesse sein Wissen und seine persönlichen Erfahrungen zu teilen. Für mich sind das auch die Eigenschaften, die einen engagierten Software-Entwickler ausmachen.

 

Was ist ein Coderetreat

Das Format des Coderetreats entstand 2009 auf der Codemash Conference (History of Coderetreat). Erst einige Jahre später wurde 2011 der erste Global Day of Coderetreat durchgeführt.

Ein Coderetreat ist eine Zusammenkunft von Entwicklern, um zu üben und zu lernen abseits der gewohnten Arbeitsumgebung. Alle Übungen werden immer mit wechselnden Partnern durchgeführt. Ich werde das Format in meinem nächsten Blog detaillierter beschreiben. Lernen fällt uns leichter wenn es Spaß macht und ein Coderetreat bietet diese Umgebung.

Der Hauptfokus ist für mich das Üben von Agilen Software-Entwicklungspraktiken, Prinzipien und Methoden. Das sind zum Beispiel Pair Programming, Test Driven Development oder 4 Rules of Simple Design und für das ist es wirklich perfekt geeignet. Pair-Programming und Coderetreat sind für mich beides  sehr effiziente Arten  des Lernens. Ich finde so immer wieder neue Impulse und Ideen, die ich in der täglichen Arbeit nicht so leicht bekomme. Coderetreat und Dojo sind beides Methoden, um zu schulen und zu lernen, und ich wende diese Methoden auch in meinen Trainings an.

 

GDCR Wien 2014

Der Global Day of Coderetreat dauert einen Tag von 8:30 Uhr bis 17:30 Uhr und das ist für jemanden wie mich, der am Wochenende gerne lang schläft, eine Herausforderung. Heuer waren zwei tolle Facilitatoren den ganzen Tag dabei: Alexandru Bolboaca und Peter ‚Code Cop‘ Kofler. Alex war einer der ersten Facilatoren weltweit, hat schon mehr als 30 Retreats geleitet und mit international anerkannten Persönlichkeiten wie JB Rainsberger and Corey Haines zusammen gearbeitet. Es gibt weltweit ganz wenige die so viel Erfahrung beim Facilitating haben wie er.

Alex begann mit einer Folie mit einem einzigen Satz:

Get out of your comfort zone!

Get out of your comfort zone

Wenn du am GDCR teilnimmst, dann musst du deine Komfortzone verlassen und das muss dir bewusst werden. Wenn du dich traust Neues zu probieren, dann wird ein GDCR spannend und eine großartige Erfahrung wo du viel lernst.

Ein Coderetreat braucht Themen, damit spezielle Fertigkeiten geübt werden können. Unsere Facilitatoren präsentierten eine Liste von Vorschlägen, die ihrer Erfahrung nach öfter bei Coderetreats ausgewählt werden. Alle Teilnehmer konnten durch die Vergabe von Punkten wählen.

  • Design
  • Programmier-Sprachen
  • Test Driven Development (TDD)
  • Pair Programming
  • Clean Code

Priorisieren mit Punkten, das kennen die meisten aus Workshops oder Retrospektiven. Im Nachhinein betrachtet war das schon einer der Erfolgsfaktoren, da wir alle sehr ähnliche Themen priorisiert hatten. Die drei Themen mit den meisten Punkten waren: Design, Pair Programming und TDD.

 

Thema – Design

Die zweite Runde hatte folgendes Thema:

Wählt ein Design, das bereit und offen für Veränderungen ist!

Die ungewöhnlichen Regeln für diese Sessions waren

  • Der entwickelte Code wird am Ende nicht gelöscht
  • In der  nächsten Session bekommt ihr neue Anforderungen
  • Die 2. Session wird mit dem selben Partner fortgesetzt
  • Versucht diese Anforderungen inkrementell weiter zu entwickeln

Die Aufgabe beim Coderetreat ist immer dieselbe: Conway’s Game of Life. In einer unendlichen orthogonalen zwei-dimensionalen Matrix leben Zellen, die je nach Rahmenbedingung sich fortpflanzen oder sterben.

Coderetreat_Conways Game of Life_1

By Bryan.burgers (Own work), via Wikimeia Commons

Die Vorgabe der zweiten Runde war, das Universum ist nicht mehr orthogonal sondern hexagonal. Daraus ergibt sich eine neue Anzahl an Nachbarn. Zusätzlich wurden die Regeln für das Überleben und Sterben der Zellen verändert.

Coderetreat_Conways Game of Life_2

 Wenn man die Bilder betrachtet dann wirkt diese Änderung sehr gravierend. Die Auswirkungen in unserem Code waren es aber nicht. Wir haben unser Design der Klassen so gewählt, dass wir Struktur des Universums und die Regel für das Überleben einer Zelle strikt in kleine kohäsive Einheiten getrennt hatten. Dies entspricht dem Design Prinzip „Single Responsibility“. Natürlich mussten wir neue Klassen implementieren, aber der Code, der diese zusammen gebunden hat, musste nicht verändert werden. Wichtig war auch zu wissen, welche Entscheidungen wir in der ersten Runde getroffen haben. Diese Entscheidungen sollten klar dokumentiert sein und dürfen die Komplexität nicht erhöhen, weil sie Annahmen über die zu erwartende Zukunft treffen. Unser erstes Design war sehr einfach und dadurch robuster als erwartet.

 

Thema – Pair Programming

Ich glaube jeder kennt solche Gespräche.

A: Wir sollten hier dieses und jenes tun.

B (denkt sich): Na ja ist okay, aber besser wäre es anders

B (zu A): Ja, ich finde deinen Vorschlag gar nicht so schlecht, aber was hältst du von …

Wir sagen JA aber wir meinen NEIN. Um nach außen freundlich zu wirken und den Partner nicht komplett zu enttäuschen, verwenden wir diesen sprachlichen Trick. Beim Pair-Programming gibt es eine ähnliche Situation wenn die Partner nach dem Wechsel nicht auf den bisher entstanden Code weiterbauen sondern große Teile ersetzen, um ihre eigenen Lösungen aufzudrängen. Um sich dieser Situation bewusst zu werden, spielten wir in unserer nächsten Session

„Yes, And …“ statt „Yes, But …“.

Die Regeln sind einfach: anstatt zu wiedersprechen ist es nur erlaubt zu akzeptieren. Die Konsequenz ist, dass beim Wechsel der Rollen Navigator und Driver, auf dem bisher entwickelten Code aufgebaut werden muss. Das Löschen von Code ist nicht erlaubt – nur wenn der Code nicht mehr verwendet wird und nur wenn beide Programmierer zustimmen.

Die Übung war lustig und vor allem aufschlussreich. Im Nachhinein betrachtet waren mein Partner und ich immer noch zu ruhig. Um auf etwas aufbauen zu können, muss man sich mehr mit dem Verstehen auseinander setzten als mit Kritik. Das war für mich doch ungewöhnlich. Es ist ein Übergang vom Zuhören zum Verstehen. Verstehen bedeutet fragen und noch mehr fragen, damit ich so viel weiß, dass ich den Code erweitern kann.

Überraschend war das Ergebnis. Einerseits mehr verstehen und lernen, anderseits  nicht besonders toller Code. Gar nicht im Sinne von Clean Code. Refactoring benötigt Veränderung und das Löschen war bei dieser Übung verboten. Eine Frage, die ich mir stelle: Führen Konsens und Dialog zu mehr Code Smells?

 

Am Ende des Tages der „Closing Circle“

Eigentlich hatte ich in der Früh Bedenken, ob es noch spannend sein kann, wenn man bereits viermal am GDCR teilgenommen hat. Umso größer war die Überraschung, wie schnell die Übungen und der Tag vergingen.

Besonders aufgefallen ist mir durch unsere Übungen, dass Design immer eine Entscheidung darüber ist, welche Einschränkungen ich treffe und wie offen mein Design für Erweiterungen und Änderungen ist. Man kann diese Änderungen nie vorher sagen und man muss unbedingt vermeiden, Anforderungen zu entwickeln von denen man annimmt, dass sie in Zukunft benötigt werden könnten (You Ain’t Gonna Need It). Die Essenz an gutem Design ist, dass ich weiß und erkennen kann welche einschränkenden Entscheidungen getroffen wurden, um bei Änderungen entsprechend reagieren zu können.

Mein zweites Learning bezog sich auf die Praktik des Pair-Programming. Durch meine Erfahrungen neige ich dazu ein starker Partner zu sein und mein Pair zu überfordern, eine bestimmte Richtung vorzugeben und in diese Richtung zu drängen. Ich nehme mir daher regelmäßig vor mehr zu zuhören. Es ist aber mehr notwendig, ich muss Entstandenes akzeptieren und darauf aufbauen. Das erhöht das Gefühl gemeinsam etwas geschaffen zu haben und auch die Motivation beim Pair-Programming. Anderseits habe ich erfahren, dass zu viel an Zurückhaltung auch negative Aspekte hat. Ich muss zugeben dass unser Code am Ende der Übung alles andere als sauber war, obwohl mein Partner beim GDCR sowie auch ich Anhänger von Clean Code sind.

Zum Abschluss eine Einladung an alle, die jetzt Geschmack auf Abwechslung und Auszeit vom täglichen Umfeld bekommen haben. Probiert den nächsten Global Day of Coderetreat 2015! Ich freue mich schon euch außerhalb eurer Komfortzone kennen zu lernen.

 

 

Passende Artikel

Ein Kommentar

  1. Vielen Dank für den super Post. Da ich der Veranstaltung des Global Day of Coderetreat in Bern involviert bin, bin ich immer auf der Suche nach spannenden Constraints. Deshalb habe ich eine kleine Umfrage gestartet, welche Constraints am besten ankomen. Ich würde mich freuen, wenn du hier http://drieschmanns.wordpress.com deinen Lieblingsconstraint voten würdest.
    Ansonsten würde mich interessieren, für welche Constraints hier euch entschieden habt.