Coding Dojo – der Trainingsraum für Entwickler

Definition: A Coding Dojo is a meeting where a bunch of coders get together to work on a programming challenge (the Code Kata). They are there to have fun and to engage in deliberate practice in order to improve their skills.

(Quelle: http://codingdojo.org/)

The Principles of a Coding Dojo
(extracted from the Laurent Bossavit’s Blog: bossavit.com/dojo/archives/2005_02.html)

  1. The First Rule
    One important rule about the Dojo is : At the Dojo one can’t discuss a form without code, and one can’t show code without tests. It is a design training place, where it is acknowledged that “the code is the design” and that code without tests simply doesn’t exist.
  2. Finding a Master
    The master can’t be a master of every forms. I feel quite at ease with recursive functions and list processing e.g. but I think I don’t know how to create even a simple web app. Fortunately, while it’s the first time they really deal with “tail-recursion” some practionners here have done professional web apps for years!
  3. Come Without Your Relics
    Of course, you know how to do it. You know how and why this code is better than that one. You’ve done it already. The point is to do it right now, explain it to us, and share what you learned.
  4. Learning Again
    In order to learn again something, we just have to forget it. But it’s not easy to forget something when you’re alone. It’s easier when we give our full attention to someone who just tries to learn it for the first time. We can learn from others mistakes as well as from ours if we listen carefully.
  5. Slow Down
    Learning something should force you to slow down. You can go faster because you learned some tricks, but you cannot go faster and learn at the same time. It’s OK, we’re not in a hurry. We could do that for years. Some of us certainly will. What kind of deadline will we miss if we spend four more weeks on this subject rather than on four different subjects? More precisely, when we reach the next plateau, is it because we went through the previous one, or is it just because we were flying over it?
  6. Throwing Yourself In
    At some time someone begins to master a subject and wants to approach another one. Those threatened by boredom should throw themselves first into a presentation. The goal is to get back to a good motivation level, ie. an acceptable level of difficulty.
  7. Subjecting To A Master
    If it seems difficult to you, look for other practitionners who can judge your code and could easily show something new about it to you. Ask again until the matter contains absolutely no more difficulty to you.
  8. Mastering A Subject
    If it seems easy to you, to explain it to other who find it difficult. Explain it again as long as they find it difficult.

(Quelle: http://codingdojo.org/)

Seit mehreren Monaten experimentieren wir mit Coding Dojos in der Firma. Nach jedem bisherigen Dojo haben wir etwas gelernt und diese Erkentnisse bei dem nächsten Session gleich angewendet: Wir haben sozusagen die Dojo-Finding-Kata gelöst und eine gute Lösung dafür gefunden, wie wir dabei das meiste lernen können.

Es gibt 2 Levels: für Anfänger und für weniger Anfänger, mit einem gemeinsamem Punkt: alle sind Softwareentwickler. Anfänger bedeutet: neu in der Welt der Tests und/oder neu in C#. Dadurch, dass wir sowohl C# als auch JavaScript-Dojos machen, werden wir uns mal den einen mal den anderen Schuch anziehen müssen ;). Durch diese Aufteilung sind wir in der Lage, eine passende Übung durchzuführen. Die Einladung geht an alle und es bleibt jedem selbst überlassen, zu entscheiden, bei welchem Level er/sie mitmachen möchte. Diese Selbst-Verpflichtung führt automatisch dazu, dass man es ernst.

Was die Form betrifft, haben wir mehrere Varianten ausprobiert:

  • Mit oder ohne Moderator: Erkenntnis: es muss einen Moderator geben, wenn man nicht will, dass der Abend in Frust und Streit endet 😉
  • mit Coder und Driver (Randori Modus): Erkenntnis: der Coder war gleichzeitig der Driver, der andere saß nur da und wartete auf seine ReiheThumbs-down-icon
  • mit Wechsel der Paare nach einer bestimmten Zeit: Erkenntnis: das mentale Ticken einer Uhr hat teilweise zu einer kompletten Blockade geführt. Warum soll man überhaupt einen Stopper verwenden? Niemand sagt einem bei der Arbeit: du hast 5 Minuten für diese Aufgabe sonst müssen wir die Firma schließen!!Thumbs-down-icon
  • ein Dojo für alle, unabhängig von Kenntnissstand: Erkenntnis: ein guter Entwickler, der in C# noch noch nicht so bewandert ist, hat genauso gute oder gar bessere Ideen, als die anderen bzw. braucht länger um den Syntax des Lösungsweges zu verstehen. Das kann dazu führen, dass man sich unterschätztThumbs-down-icon

Nach verschiedenen Diskussionen mit anderen Entwickler, die Dojos in Unternehmen erfolgreich etabliert haben (danke nochmal Ralf und Uli) und nach diesen eigenen Erfahrungen, haben wir uns für die folgende Variante entschieden:

  • die Tastatur geht herum, und nicht der Entwickler (das hat auch immer wieder zu Störungen geführt).
  • Jeder, der dran ist, muss entweder den allerersten Test schreiben oder den vorherigen lösen: das bedeutet, er muss den Code schreiben, wodurch der Test grün wird – nicht mehr und nicht weniger. Danach muss er noch den nächsten Test schreiben, und zwar so, dass er rot ist. (Es gab Fälle, wo die nächste Anforderung – also der nächste Test – gleich mit implementiert wurde.)
  • Es gibt keine zeitliche Begrenzung und niemand muss alleine grübeln. Wenn Fragen oder Mißverständnisse im Raum stehen, sie werden sofort geklärt. Die Fragen müssen trotzdem vom Entwickler formuliert werden: der Lernprozess ist immer da.
  • Der Weg ist das Ziel: wird eine Aufgabe nicht in der Zeit erfüllt, die uns zur Verfügung steht, dann ist das auch ein Erkenntniss, aus dem man lernen kann.

Thumbs-up-icon

Wir verfolgen durch diese Trainingsstunden verschiedene Ziele:
– lernen, wie man Tests schreibt, um eine nachhaltige Qualität abzusichern,
– lernen, wie man Features gegen Code-Veränderungen schützt.
– lernen, wie man eine Anforderung interpretiert,
– lernen, wie man eine Anforderung definiert,
– lernen, wie man eine konstruktive Diskussion führt um sich auf eine Lösung zu einigen,
– lernen, wie man SOLIDen Code schreibt, Abhängigkeiten erkennt und trennt, wie man für Menschen lesbaren Code schreibt.

Die Liste der Lerneffekten solcher Übungen ist sicher viel länger, aber vorerst reicht es, wenn wir das hier schaffen :). Diese Prozesse werden sich sicherlich ändern – genauso wie wir Entwickler. Die Grundlagen aber bleiben bestehen: alles, was wir hier lernen, soll sich – wird sich –  in der täglichen Arbeit wiederspiegeln und uns zu besseren Softwareentwickler und gleichzeitig zu besseren Teamplayer machen.

Dojo as You Go

Gestern war Dojo-Time in München. Kurz nach 6 haben wir uns – ich glaube wir waren 18 – bei Avanade getroffen. Ilker hat sich schon wieder übertroffen, er und Yasmine haben uns regelrecht verwöhnt.
Avanade Buffet
Die Location war perfekt, das Dojo das Beste an dem ich seit langem war, das Team hervorragend: begeistert und erwartungsvoll und zum Glück gemischt. Es waren alte Hasen und “Jünglinge” da und wir haben richtig viel Spaß gehabt. So “nebenbei” haben wir alle ganz schön viel gelernt 😉 Wir haben diskutiert, geplant, gecodet. Und dann wieder diskutiert, geplant, gecodet. Und wieder, und wieder, bis um 9 Uhr.

DiskussionPlanungCode
Es war ein sehr kurzer Abend obwohl ich erst um halb eins zu hause war. Es war ein schöner Abend. Für mich war dieses vielleicht das letzte Dojo in München, ab Oktober werde ich den Yellow-Brick Road in Köln bestreiten. Aber das bedeutet nur einen Neuanfang, oder?

Also danke nochmal ihr Münchner Dojoisten für die letzten 10 Monate, danke Ilker für die geopferten Stunden, ich weiß, es hat dir riesen Spaß gemacht. Mir auch 🙂

Coding Dojo – aber wie?

Wir haben in der Abteilung vor ein paar Wochen eingeführt, am letzten Tag von jedem Sprint einen kleinen Firmeninternen Dojo abzuhalten. Da wir vom Anfang an zu den Münchener Coding Dojos gehen, haben dadurch ziemlich viel Erfahrung gesammelt, wie so ein Dojo durchgeführt wird.

Wie laufen üblicherweise diese Veranstaltungen ab? Der Organisator beschreibt die zur Auswahl stehenden Aufgaben, die Teilnehmer besprechen es kurz, und nachdem die Wahl getroffen wurde, wird fast sofort losgelegt. An der Tastatur. Der erste Test entsteht dann allerdings erst nach 30-40 Minuten. Geplant wird mit einem zuckenden Finger über die Tastatur, der Test entsteht oft nach einem frustrierten Ruf “schreib endlich was, egal was!”. Am Ende jedes Dojos hatten wir dann die Anforderungen erfüllt, aber zur Refactoring kamen wir nie.

Aber wir sind Entwickler, wir entwickeln uns ständig weiter. Seit längerer Zeit spürten wir, dass wir so einen Prozess anders steuern sollten, dass etwas fehlt.

An diesem Freitag haben wir also etwas anderes ausprobiert, sozusagen à la Clean Code: zuerst Anforderungen aufschreiben (das war ja nichts neues), dann nachdenken. Ohne Tastatur, nur am Flipchart. Das war neu. Wir haben die ganze Planung inklusive Funktionseinheiten, Methodennamen, Abhängigkeiten aufgezeichnet.
Danach ging erst das Entwickeln mit TDD los. Nach ca. 90 Minuten waren wir fast fertig und wir haben keine Refactoring mehr gebraucht.

Auf die Frage nach der Meinung den Kollegen, ob das jetzt besser gelaufen war, waren die Antworten geteilt: manche meinten, wir wären auch auf dem anderen Weg zum selben Ergebnis gekommen. Die Wahrheit ist, das Beispiel war recht einfach, es gab nicht sehr viele trennbare Verantwortlichkeiten, aber ich bin sicher, dass man auf dieser Art viel mehr lernen kann. Es reicht ja nicht, eine Sprache zu kennen, ein guter Entwickler muss auch Abstraktionsebenen erkennen und definieren können. Ich finde diese Art zu Arbeiten: zuerst alle Möglichkeiten auf einem Stück Papier zu bewerten und dann sich auf die einzelne Methoden zu konzentrieren, viel effektiver, ich glaube fest daran, dass es zu besserem Code führt.

Also die Frage ist: wie soll eine mit TDD entwickelte Anwendung entstehen? Vom Anfang mit der Tastatur unter den Fingern oder darf es etwas Planung in den Köpfen und auf Papier stattfinden? Haben wir die Regeln von TDD verletzt oder verbessert?