Wir sind auf einer Konferenz. Viele Vorträge, von bodenständig bis abgehoben. Neue Technologien, neue Ansätze. Der Typ da vorn kündigt an, dass es ein Coding Dojo geben soll. Das ist in. Das gibt es jetzt immer auf Konferenzen. Bei all den trockenen Vorträgen tatsächlich Code schreiben. Zusammen. Gemeinsam. Im Team. Coding live erleben. Auf dem openspace hatte jemand ein Dojo als Session vorgeschlagen. Wurde begeistert angenommen. Natürlich wollen wir Dojos. Klar doch. Bei Dojos geht es darum, Spaß zu haben. Und einfache Aufgaben zusammen lösen, das ist doch Spaß.
Die Zeit ist ran. Heute ist es abends. Wir haben schon gegessen, das Catering war super. Bier gab es nicht zu viel. Wir werden den Geschehnissen also folgen können. Und wer auch immer sich nach vorn setzt, wird auch noch keine Ausfallerscheinungen zeigen.
Der Typ von heut früh ist der Dojo-Master. Zuerst schlüpft er in die Rolle des Kunden und stellt die Aufgabe. Nicht zu schwer soll sie sein, so dass sie in 90 Minuten auch geschafft ist. Dann ist er Master und erklärt die Regeln. Heute gibt es zwei ‘heiße Stühle’: Zwei Leute sitzen vorn und arbeiten gemeinsam an der Aufgabe. Wer meint, es besser zu können, darf nach vorn kommen und einen ablösen. So kommt jeder mal dran.
Natürlich ist die Aufgabe einfach genug, dass es jedem in den Fingern juckt.
Ein Projekt wird angelegt, ein Testprojekt dazu. Ein Interface und eine Klasse dazu.
Der Dojo-Master fragt dazwischen: ‘Brauchen wir das jetzt? Ist das wirklich das Einfachste?’.
Nein, ist es nicht. Das Einfachste ist eine statische Klasse. Mit einer statischen Methode. Wenn einer der beiden ‘heißen Stühle’ nicht drauf kommt, dann einer aus dem Publikum, und es wird gewechselt.
Das Interface wird weggeschmissen, ein ‘static’ vor das ‘class’ gesetzt und vor den Methodennamen. Wir sind beeinflussbar. So sehr, dass wir nicht mal merken, dass das static vor der Klasse eigentlich zu viel ist. Eine statische Methode braucht keine static class. Aber man hat es uns suggeriert, und wir tun es einfach.
Schlimmer noch, wir haben eine Klammer auf der Nase. Jeder, der auch nur ansatzweise mal den Begriff ‘Code Smell’ gehört hat, weiß eigentlich, dass ‘static’ müffelt. Zwar noch nicht bei Martin Fowler, auf den die Idee der Code Smells zurückgeht. Aber jeder weiß, dass ‘static’ ein Schlüsselwort ist, das sich im Code ausbreitet wie die Pest. ‘static’ müffelt nicht nur, es stinkt. Wir lassen es trotzdem durchgehen. Schließlich ist es ja das Einfachste. ‘The simplest thing that possibly could do the job’ fordert Kent Beck. Der Dojo-Master fordert es auch. Wirklich? Nein, er hat nur gefragt. Und der arme Kerl auf dem heißen Stuhl hat es gemacht. Wollte sich nicht anlegen. Mit jemandem, der auf einer Konferenz nach der anderen vorträgt. Und schon gar nicht öffentlich.
Erste triviale Testfälle werden formuliert. Was passiert, wenn ich ‘null’ übergebe? Was bei einen Leerstring? Und schon haben wir die ersten grünen Tests. Applaus. Warum? Das ist so trivial, das es selbstverständlich ist. Sollte man anders anfangen? Mit der ‘echten’ Funktionalität? Darüber kann man geteilter Meinung sein. Und jeder kann seine Meinung dazu sicher begründen. Egal. Die ersten Tests geben erst mal einen Rahmen vor. Und das ist gut.
Denn jetzt kommt sie, die eigentliche Funktionalität. Wir müssen überlegen, wir wir den Eingabestring zerlegen. Die Jungs auf den heißen Stühlen wenden sich von der Tastatur zum Whiteboard. Eine kleine Architekturphase also. Andere Ideen kommen aus dem Publikum. ‘Bitte nach vorn’ sagt der Dojo-Master. Recht hat er, es gibt Regeln für dieses Dojo. Deshalb habe ich mich zurückgehalten. Ich bin zum Beobachten hier. Deshalb hole ich auch nicht mein Notebook raus wie viele andere und beweise mir selbst, dass ich die komplette Aufgabe alleine in der halben Zeit schaffe. Mein Nachbar diskutiert trotzdem mit mir.
Es wird also die ersten Male gewechselt. Die Jungs da vorn wenden sich wieder der Tastatur zu. Und versuchen, den einfachen Zerlegungsansatz umzusetzen. Aber halt, da kommt wieder der Einwand vom Dojo-Master ‘Ist das wirklich das Einfachste?’. Natürlich nicht. Das Einfachste ist, wenn wir gar nichts machen müssen, und den String einfach direkt wieder zurückgeben können. Dritter grüner Test. Applaus. Denn irgendwann kommt der Kunde, der Auftraggeber. Und wir wollen grüne Tests präsentieren. Je mehr, um so besser.
Es folgen weitere Wechsel, man überlegt, ob der einfache Zerlegungsansatz ‘es tut’ oder nicht. Ja, er tut es. Ich weiß es schon. Aber um es wirklich rauszukriegen, gibt es nur zwei Ansätze. Entweder wir sind davon überzeugt, ziehen ihn durch, und sind fertig. Oder wir haben Zweifel. Dann müssen wir abwägen. Weiter suchen – oder einen der beiden Ansätze, die wir schon haben, durchziehen. Bei einer Situation wie in unserem Dojo sollte man erst mal den einfachen Ansatz durchziehen hinterher schlauer sein. The simplest thing that possibly could do the job. Hier auf jeden Fall. Schließlich kommt der Kunde irgendwann. Stattdessen wird diskutiert.
Endlich wird wieder Code geschrieben. Man fährt tatsächlich den einfacheren Zerlegungsansatz. Toter Code wird auskommentiert, was einen sofortigen Rüffel vom Dojo-Master zur Folge hat. Recht so.
Das Publikum fiebert mit: Wieso machen die Jungs das da vorne so? Geht doch anders viel besser. Nach vorne gehen? Mit der fremden Notebooktastatur kommen wir schon klar. Wieso die Jungs da vorne nicht? Naja, irgendwie ist ein fremdes Notebook immer eine Herausforderung. Aber wir schaffen das schon. Oder lieber doch nicht nach vorne gehen? Diese Gedanken hat jeder dabei. Ich diesmal nicht.
Jemand den ich flüchtig vom openspace kenne, gibt mir ein Zeichen: ‘Wieso gehst Du nicht auch mal vor?’. Ich winke ab. Ich bin nur zum Zuschauen hier. Hatte ich mir vorgenommen – das konnte er nicht wissen.
Es wird über das Verhalten bei Leerzeichen im Eingabestring geredet. ‘Brauchen wir Leerzeichen?’ fragt der Dojo-Master. ‘Nein’ ist die Antwort von heißen Stuhl. Sie ist falsch. Die Anforderungsliste war da ganz klar. Der Dojo-Master greift trotzdem nicht ein, weil wir überhaupt erst mal Funktionalität schaffen wollen.
Jetzt diskutiert man nur noch, wie man diese eine Schleife, die nach der Zelegung laufen muss, vernünftig hinschreibt. Ob man ein for oder ein foreach braucht. Mein Nachbar, ein offenbar gestandener Praktiker, geht nach vorne. Er hat den Zerlegungsansatz nie gemocht, und hatte Zweifel, dass er ‘es tut’. Er war die ganze Zeit der Meinung, dass der kompliziertere Parseransatz der bessere ist. Und dass auch der in der vorgegebenen Zeit schaffbar gewesen wäre.
Ich habe ihn beim Abendessen und einem Hefeweizen vorher kennengelernt, und während des Dojos viel über seine Auffassungen gelernt. Also habe ich keine Angst. Er wird den den Zerlegungsansatz nicht noch einmal in Frage stellen. Er ist zwar nicht 100% davon überzeugt, aber er wird ihn durchziehen. Bis zum Schluss. Macht er auch. Es funktioniert. Der erste nichttriviale Test wird grün. Kein Applaus. Wieso nicht? Jetzt ist wirklich etwas geschaffen worden, was funktioniert. Jetzt wäre Applaus am Platz gewesen. Der nächste Test ist auch sofort grün. Die Zeit ist um, für einen weiteren Test reicht es leider nicht.
Der Dojo-Master schlüpft in die Rolle des Kunden. Um dem Rollenwechsel Ausdruck zu verleihen, wird ein wenig dramatisiert. Musik, ein cooler Umhang. ‘Ich hab Euch einen Auftrag gegeben, zeigt mal was ihr habt’.
‘Habt ihr grüne Tests?’ – ‘Ja, haben wir.’
‘Welche Anforderungen könnt ihr denn?’ – es wird ein wenig lamentiert. Schließlich ist der letzte Blick auf die Anforderungsliste schon mehr als eine Stunde her. Der Kunde hilft und blättert das Whitebord zurück.
‘Könnt Ihr das hier?’ – ‘Ja’.
‘Könnt Ihr das hier?’ – ‘Ja’.
‘Könnt Ihr das hier mit den Leerzeichen?’ – ‘Ja’. Da gab es keinen Test dazu. Das war aus der Überzeugung heraus gesagt, aber nur gemutmaßt. Der Kunde schluckt es trotzdem.
Das Dojo ist zu Ende. Jeder darf seine Meinung sagen – der Saal ist groß, man überzieht die Zeit ein bisschen, aber das ist nicht wirklich schlimm. Es kommen Aspekte dabei hoch, an die man selbst nicht gedacht hat. Das ist gut, das ist erhellend.
Auf dem Heimweg frage ich mich, was die Faszination von Coding Dojos ausmacht. Macht es wirklich Spaß, öffentlich Code zu schreiben, der müffelt? Trotzdem will sie jeder, wir alle schauen zu und machen mit. Das Ding fasziniert uns. Das Ding glitzert. Wir sehen etwas darin. Ein Bild. Es bewegt sich. Ich glaube, die Dojos sind Splitter eines Spiegels. Wir beginnen, uns selbst darin zu erkennen. Wir erkennen darin nicht nur wir wir coden, sondern auch, wie wir kommunizieren, wie wir im Team zusammenarbeiten. Wenn es um reale Spiegel geht, können Delphine das schon lange. Menschen auch. Das macht Intelligenz aus. Bei Teams, großen wie kleinen, stabilen wie stetig wechselnden, oder einer ganzen Brache ist das ungleich komplexer.
Wir müssen das Ding erst einmal als Spiegel begreifen. Ich bin sogar der Meinung, dass wir noch größere und bessere Spiegel brauchen. Und auch, dass der Weg vom regelmäßigen Blick in den Spiegel bis zum guten Aussehen ein langer ist.
Lasst uns in den Spiegel schauen. Das, was wir dort sehen, hilft uns beim täglichen Reflektieren über unsere Arbeit. Und lasst uns noch bessere Spiegel finden. Nur Spiegelscherben aneinander zu setzen gibt noch keinen wirklich guten Spiegel.
