Gedanken zu Dojos
Nachdem in den Blogs von Steffen und Ilker bereits über verschiedene Aspekte von Dojos diskutiert wurde habe ich den Eindruck, dass ein Aspekt der mir persönlich wichtig ist, bei diesen Diskussionen noch nicht beleuchtet wurde oder sogar misverstanden ist. Es geht mir dabei um den dargestellten Konflikt zwischen den “Codern” und den “Knoblern”. Dabei beziehe ich mich konkret auf das Dojo im Rahmen der dotnetpro powerdays in München. Ich und andere aus der “letzten Reihe” haben in diesem Dojo den Einwand gebracht, wir mögen doch vor dem ersten Test ein klein wenig planen. Leider konnte ich mich mit diesem Vorschlag nicht durchsetzen. Dabei sehe ich folgende Probleme:
- Die Beschlüsse wurden per Abstimmung herbeigeführt. Das halte ich für suboptimal. Zum einen, weil die Alternativen nicht inhaltlich diskutiert wurden. Dadurch konnten diejenigen, die den Vorschlag ablehnten, nicht wirklich deutlich machen, aus welchem Grund sie ihn ablehnen. So wurde ich am Lernen gehindert. Denn selbstverständlich kann ich ja auf dem falschen Dampfer sein. So musste ich mich auf das Experiment, direkt mit einem Test zu beginnen einlassen. Das Ergebnis ist bekannt. Ich war nicht damit zufrieden. Und ich bin immer noch überzeugt, dass wir mit etwas mehr Planung weiter gekommen wären. Dazu später mehr. Zum anderen halte ich Abstimmungen in Dojos für suboptimal, weil es neben dem Konsens noch den Konsent gibt. Eine Grundidee dabei: so lange niemand etwas wirklich gewichtiges gegen einen Vorschlag einzuwenden hat, wird er angenommen. Damit wird erreicht, dass Minderheiten nicht per Abstimmung ohne Argumente abgebügelt werden. Vielleicht gab es ja inhaltlich gewichtige Einwände gegen etwas mehr Planung. Ich habe sie bislang leider nicht erfahren.
- Ich war nicht konsequent genug, hätte versuchen sollen besser darzulegen worum es mir geht. Einen Schuh muss ich mir selber anziehen: ich habe vielleicht nicht wirklich deutlich gemacht, was ich mit “Planung” genau gemeint habe. Es wäre einfach gewesen, denn ich selbst habe mir eine Skizze angefertigt. Diese hätte ich auch an die Flipchart malen können. Vielleicht wäre dann klar geworden, dass es mir nicht um Big Design Upfront geht.
Was ich hier mit “Planung” meine, möchte ich deutlich abgrenzen vom Begriff der “Knobler”. Bei der Kata BankOCR gab es nichts zu knobeln. An den wenigen Diskussionen die sich inhaltlich mit der Lösung der Aufgabe befassten, konnte man erkennen, dass ganz
offensichtlich alle Beteiligten eine Vorstellung ihres Lösungswegs im Kopf hatten. Mir geht es darum, diese diffuse Vorstellung explizit zu Papier zu bringen. Zum einen, um mir Klarheit darüber zu verschaffen und darüber nachzudenken, ob der gewählte Weg zum Ziel führt. Zum anderen, um in der Gruppe eine gemeinsame Diskussionsbasis zu schaffen. Meine SKizze war in wenigen Minuten angefertigt. Das nebenstehende Bild zeigt meine Skizze vom Dojo in München. Ich glaube nicht, dass eine solche Skizze der Gruppe schwer gefallen wäre oder sie lange aufgehalten hätte. Durch eine solche Skizze wäre aber jedem klar gewesen, wo wir stehen, wovon wir sprechen. Und wir hätten anhand der Skizze überlegen können, wo wir mit dem ersten Test beginnen. Stattdessen wurde munter drauf los gecoded und irgendwann erkannt, dass wir offensichtlich von “innen nach außen” entwickelt haben.
Ich möchte betonen, dass ich keinen Konflikt sehe, zwischen der testgetriebenen Entwicklung und einer Planung vorab. Und ich spreche im Kontext dieser Kata nicht von Architektur. Es geht um das Design der Lösung, um die Zerlegung des Problems in Teilprobleme. Meinen Code entwickle ich ausschließlich testgetrieben. Völlig egal, ob es sich dabei um Produktionscode oder Beispiele für Artikel oder Vorträge handelt. Der einzige Unterschied zur Vorgehensweise beim Dojo ist, dass ich vorher eine Skizze mache. Immer! Denn in Zeiten, in denen ich das nicht gemacht habe, hatte ich am Ende ein Ergebnis, mit dem ich nicht ganz zufrieden war. Seit ich vorher plane, hat sich meine Codestruktur deutlich verbessert. Ferner kann ich dann viel entspannter loslegen, weil ich stehts weiß, wo ich stehe. Ferner ist die Qualität der Tests besser, da Teilaspekte isolierter getestet werden. Da ich mir nicht sicher war, ob meine Beobachtung richtig war und das bessere Ergebnis an der Vorplanung lag, habe ich zeitweise die Planung wieder weggelassen. Heute bin ich mir sehr sicher, dass ich mit Planung besser entwickle als ohne.
Damit möchte ich nun nicht behaupten, dass dies der einzig richtige Weg sei. Ich möchte lediglich darauf hinweisen, dass meiner Einschätzung nach in der einschlägigen Literatur zu TDD die Planung zu kurz kommt. Und die von mir besuchten bzw. durchgeführten Dojos haben mir ebenfalls gezeigt, dass es ohne Planung schwieriger ist, zum Ziel zu kommen. Einen weiteren Hinweis geben mir die Seminare und Workshops die ich in den letzten Monaten, meist gemeinsam mit Ralf Westphal, gehalten habe. Auch dort hat sich die Planung als vorteilhaft gezeigt.
Die Planung auf einem Stück Papier hat gegenüber dem “sofort loscoden” meiner Einschätzung nach den Vorteil, dass es ein nicht-linearer Prozess ist. Auf dem Papier kann ich wild springen, meinen Ideen freien Lauf lassen, Dinge verbinden, schnell etwas ergänzen oder auch wieder wegstreichen. Ganz anders ist die Arbeit an einem Test. Dies ist ein linearer Prozess. Ich bin gezwungen, den Code in einer bestimmten Reihenfolge einzugeben. Bevor ich überhaupt eine Zeile tippen kann, muss mindestens ein Projekt aufgesetzt werden. Das mag in trivialen Beispielen ebenso trivial sein, oft ergibt sich die Projektstruktur aber erst aus der Planung. Die Vorgehensweise beim TDD ist linear. Ohne dass ich vorher in einem kreativen nicht-linearen Prozess Ideen gesammelt und sortiert habe befinde ich mich in diesem linearen Prozess gefangen. Denn ich habe ständig die Sorge, dass ich eigentlich nicht genug von der möglichen Lösung weiß. Und oft genug kommen Probleme um die Ecke, die einen zur Umkehr zwingen. So war es auch beim Dojo in München. Wir haben irgendwann gemerkt, dass etwas nicht stimmt. Diese Erkenntnis hat mir meine Skizze bereits viel früher gebracht.
Nun will ich aber nicht nur Behauptungen aufstellen und von Alternativen schreiben, sondern auch anbieten, es mal anders zu versuchen. Der genaue Rahmen ist mir noch nicht klar, aber es wird Gelegenheit dazu geben, mal ein Dojo mit Planung durchzuführen. Ich werde rechtzeitig darauf hinweisen.
June 26th, 2010 at 16:57
Adäquate Planung – eine unschätzbare, hochproduktive Erkenntnis die ich aus CCD-Camp mit seinen Tages-CodingDojos durch Übungen in einer Timebox in seiner gelebten Form mitgenommen habe. Ein gutes Ziel für viele, viele Übungen!
Siehe meine Kommentare
http://www.gmbsg.com/lerne-lehre-ilker-net-coding-dojo-latifa-stil/
PS: Da wär ich doch gern dabei gewesen und freue mich auf das CodingDojo mit adäquater Design/Architektur.
June 26th, 2010 at 19:39
Ich gehe auf zwei Aspekte Deines Posts ein. Der erste Aspekt ist der inhaltliche. Ich denke, es ist für KataBankOcr keine “Planung” im sinne der Lösungsanalyse notwendig. Und noch weiter: TDD lebt von kurzem Feedbacking und heftigen Refactorings. Ich weiss nicht wie Du Deinen Produktinscode per TDD schreibst. Aber ich ändere pausenlos etwas an meinem Code. Mein Code lebt. Das kann ich mir bei Deiner Vorgehensweise sehr schwer vorstellen.
Überdies ist es meine Überzeugung, dass man Nachdenken sollte, bevor man in die Tasten greift. Das habe ich hoffentlich klar genug transportiert. Ich störe mich nur daran, dass man für solche trivialen Problemstellungen (meistens ist es nur ein einziger Algorithmus, und dann auch noch ein einfacher) irgendwelche “Planungen” bräuchte. Man muss sich nur richtig Gedanken machen, was man wie testet. Das ist alles. Das gemeinsame Verständnis entsteht – aus meiner Erfahrung mit Teams, Dojo’s und einigem mehr – viel besser über den gemeinsamen Code als über Papier. Ich habe im Alltag, in Projekten und unter Freunden vielerlei Beweise dafür erlebt und bin daruch in meiner Überzeugung gestärkt.
Doch wenn die Problemstellung eine größere wäre (z.B. sowetwas wie ein Sprachinterpreter oder eine kontextabhängige, clientseitige, konfigurierbare Webformularvalidierung), dann braucht man sicherlich mehr. Aber in Coding Dojo’s wird eben nicht mehr gemacht. That’s it.
So, und jetzt noch der zweite Aspekt: die Art und Weise. In dem von Dir besagten Dojo warst Du in der letzten Reihe. Du hättest zuschauen können. Das hast Du aber nicht getan. Sondern Du hast für Dich mitgedacht. Aber eben nur für Dich. Nicht für uns. Du warst für mein Empfinden alles andere als aufrichtig und aktiv an der Sache beteiligt. Wärst Du das gewesen, hätte die Diskussion um Deinen Vorschlag sicherlich stattgefunden.
Ich nenne Dir hier nur als Beispiel Golo. Golo saß in der ersten Reihe. Golo hat aktiv mitgewirkt. Golo hat Vorschläge gemacht, im Übrigen aus Überzeugung. Er hat Gegenargumente hinnehmen müssen. Ja, sein Argument wurde durch die Gemeinschaft überstimmt. Trotzdem hat er weiter seine Überzeugung transportiert – ab er gleichzeitig den Gemeinschaftsentscheid respektiert. Keiner hat nach dem Dojo über seine Auffassung lamentiert. Er hat auch nicht über das Dojo lamentiert. Er hat am Ende nur angemerkt, dass Refaktorisierung wichtig gewesen wäre. Und ich denke, viele in diesem Dojo haben genau in dieser Minute wieder einige Erkenntnisse mitgenommen. Diese Erkenntnisse wären aber nicht dadurch entstanden, dass man gesagt hätte “So und so geht das.”. Darüber soillte man nachdenken.
Also Stefan: Aufrichtig, Gleichgestellt, Aktiv, Respektvoll, Optimistisch, Zwanglos. Ist das für Dich ok?
http://www.gmbsg.com/lerne-lehre-ilker-net-coding-dojo-latifa-stil/
June 26th, 2010 at 20:19
Hallo Ilker,
zum inhaltlichen: ich höre aus deinen Zeilen nicht heraus, dass du so einfache Aufgaben wie BankOCR schon mal _mit_ Planung probiert hast. Ich möchte dich einladen, das einmal zu versuchen. Nur dann kannst du meiner Ansicht nach fundiert sagen, dass Planung nicht notwendig ist, bzw. die Ergebnisse von Planung vs. ohne Planung gleichwertig sind.
Zum Ablauf in München: jep, ich habe mich zu wenig eingebracht, das habe ich bereits angedeutet. Das bedeutet aber nicht, dass ich deine Dojo Werte nicht anerkenne. Ich erkenne sie vollumfänglich an. Sollte im Dojo ein anderer Eindruck entstanden sein, bitte ich das zu entschuldigen.
Und ich lamentiere auch nicht über das Dojo, da solltest du bitte auch mir gegenüber Respekt aufbringen. Ich sage, dass mir etwas gefehlt hat. Inhaltlich, einerseits. Aber eben auch bei der Offenheit. Ich vermisse die Bereitschaft, es mal mit etwas mehr Planung zu versuchen. Aber hey, es ist dein Dojo. Das respektiere ich.
Herzliche Grüße
Stefan
June 26th, 2010 at 20:39
@Ilker: Zum Ablauf in Muc: Da möchte ich Stefan in Schutz nehmen. Er hat in der letzten Reihe gesessen und sich auch eingebracht. Aber er hat nicht alles eingebracht, was er gedacht hat. Warum? Weil die Stimmung, die du vorne gemacht hast, das nicht unbedingt motiviert hat. Das sage ich mit Bedauern, aber es hilft nichts.
Die letzte Reihe, “die Rebellen”
haben mehrmals versucht, den anderen Dojo-Teilnehmer eine andere Sichtweise anzubieten – aber du hast das nicht wirklich aufgenommen. An dir wäre es aber gewesen als Moderator. Zwar hast du uns drangenommen, wenn wir uns gemeldet haben. Aber dann… hast du abstimmen lassen oder das Thema fallen lassen.
Beispiel Signatur. Mein Eindruck war, dass dir das Stichwort eigentl gut gefallen hat – aber es gab dann einen Gegenkommentar aus der Gruppe und schon war es vergessen. Ist das motivierende Moderation? Ich kann verstehen, dass Stefan sich mit seinem Lösungsansatz da nicht nach vorn gedrängt hat. Die Stimmung war ganz eindeutig “anti Nachdenken”.
Zu “Überdies ist es meine Überzeugung, dass man Nachdenken sollte, bevor man in die Tasten greift. Das habe ich hoffentlich klar genug transportiert.”: Nein, sorry, du hast für mich außer in Worten noch nicht klar genug demonstriert (!), dass für dich Nachdenken wichtig ist. Ich kann mich an kein Dojo von dir erinnern, in dem du zum Innehalten und Nachdenken angeregt hast.
Nun sagst du, die Dojo-Aufgaben gäben zum Nachdenken kein Anlass… Aber dann frage ich mich, warum denn dann überhaupt so ein Aufwand getrieben wird. Wenn kein Nachdenken nötig ist, dann ist schon gar kein TDD nötig. Dann sei so konsequent und lass auch diesen Anspruch raus.
Zu “TDD lebt von kurzem Feedbacking und heftigen Refactorings. Ich weiss nicht wie Du Deinen Produktinscode per TDD schreibst. Aber ich ändere pausenlos etwas an meinem Code. Mein Code lebt. Das kann ich mir bei Deiner Vorgehensweise sehr schwer vorstellen.”: Ich schließe mich Stefan an und bezweifle, dass du es je probiert hast, eine Kata zuerst mit etwas Nachdenken anzugehen. Das ist schade. Denn so kannst du nicht wirklich vergleichen. Du glaubst nur, dass Nachdenken bei BankOCR nicht hülfe.
Vielleicht bist du aber auch schon der Meister. Dann erkennst du nicht, dass du nachdenkst oder es geht einfach so schnell. Du “fliegst” quasi zur richtigen Lösung. Das ist toll – hilft aber armen Sterblichen im Dojo nicht. Die müssen das erst mühselig lernen. Dafür müsstest du dich dann auf ihr mieseliges Niveau hinablassen. Entweder zeigst du ihnen dann zumindest deinen schnellen Flug zum Ziel (à la Bob Martin mit Musik) oder du leitest sie an. Tust du beides nicht, dann sehen wir ja, was herauskommt. Beim letzten Dojo wird keiner, der TDD vorher nicht kannte, TDD wirklich verstanden haben.
Und dass Code, der aus Nachdenken entsteht, nicht refaktorisiert wird, ist natürlich quatsch. Nachdenken ist kein Codieren. Nachdenken soll auch nicht alles vorwegnehmen. Nachdenken spannt nur einen Modellraum auf. In dem ist dann noch genug an TDD nach deiner Manier zu machen. Keine Sorge. Probier es mal aus.
-Ralf
June 26th, 2010 at 22:32
So jetzt ist aber Schluss, bin schon ganz müde
. Soviel noch: Schade, dass das letzte MUC Coding Dojo nach den bisherigen Meinungen so mies gelaufen ist. Waren doch so viele “Senseis” im Raum 
. Mhh, beim letzten Online Coding Dojo haben wie eine kleine Planung mit One-Note – Bubbles, Pfeile und grobe Benennung gemacht. Danach schön TDD-mäßig implementiert. Antiplanungsgedankendauerzustand? Einzelfall oder Dauerzustand? Ist das Kind ab jetzt in den Brunnen gefallen? Nein, ich glaube nicht. Adäquate Planung ist gut und von seinen Ergebnissen so überzeugend wie TDD. Eine gute Weiterentwicklung des Coding Dojo hin zu 2.0 
. @Ilker Hier passt am besten Aktivität und Optimismus und der wirklcih gute Spruch … Nicht lang schnacken, Kopf in Nacken!
June 27th, 2010 at 11:18
@Stefan: Meinen Respekt hast Du – denn Du hast es eräwhnt und Dich entschuldigt. Ich glaube Dir auch, dass Du die “Latifa”-Werte beim Dojo verfolgen möchtest. Das finde ich gut.
Zu der Kritik der Offenheit. Aufeinander zugehen ist der erste Schritt zur Öffnung des Geistes. Damit möchte ich Dir sagen: Ich versuche verschiedensten Strömungen im Dojo Gewicht und Wort zu geben, sei es so ein erfahrener Programmierer wie Du – oder aber auch ein Frischling. Bei diesem “Geben” gibt es auch ein “zurückgeben” – in Form von Aufmerksamkeit und aufrichtigem Willen zum Beitrag. Es wäre schön gewesen, wenn Du und die anderen der Aufforderung ***der Gemeinschaft***, näher zusammenzurücken, gefolgt wärst. Dann hätte es auch von der Gemeinschaft (in den ersten Reihen) mehr Beachtung gegeben.
Dennoch nehme ich Deine Kritik “offener auf Alternativen” einzugehen gerne an und werde das auch beachten.
Zum Inhaltlichen´: Mit mache Software mit Planung. Und ich mache Software ohne Planung. Ich mache Webanwendungen, ich mache Enterprise-Software, ich mache ESB-Backends und so Kram halt. Beides geht erfolgreich mit und ohne “Plan” (oder besser: WF vs. XP).
Aber es kommt auf den Grad und Rahmen der Planung an, das ist ein wichtiger Erkenntnisgewinn der modernen Entwicklung denke ich. Ich habe BankOCR mehrfach gelöst. Das erste Mal habe ich es komplett “ohne Skizze” und “Minimalplanung” gemacht. In einer halben Stunde war ich fertig. Danach habe ich noch “verschönert” – z.B. Verantwortlichkeiten aufgebrochen und etwas refaktorisiert.
Die weiteren Mal habe ich natürlich mich von der ersten Lösung immer etwas “beeinflussen lassen” – aber auch nach Alternativen gesucht. Dafür – also nach der ersten Lösung – habe ich auch “geplant” (um es mit Deinen Worten zu sagen). In meinen Worten ist das eher eine Lösungsanalyse und ein wenig klassisches CRC. Also kánn ich behaupten: Ja, ich habe es auch einmal “mit Planung” gemacht.
Das Ergebnis siehst Du an meinem Standpunkt. Ich hoffe, Du bringst nun auch die von dir erwähnte “Offenheit” auf und gehst auf meine alternativen Sichtweisen ein.
Übrigens, es ist nicht mein Dojo. Nur mal so am Rande. Alles Gute!
June 27th, 2010 at 12:24
Stefan,
ich bin ganz bei dir, wenn dir “Planung” fehlt. Sie fehlt nicht nur beim schreiben von Quelltext, sie fehlt meist auf vielen (allen?) ebenen oder ihr wird zu wenig Zeit gewidmet. Ich denke das Planung ein nötiger Schritt hin zu einem pragmatischen TDD ist (wie zB bei Freeman&Pryce). TDD war lange genug dogmatisch – und musste es auch sein. Nun scheint es mir aber sowohl gebrandmarkt als auch misverstanden. TDD schließt für mich niemals Planung aus. Ebenso wie evolutionäres Design eine erste Planung & Architektur nicht ausschließt.
Beides scheinen wir noch nicht gut oder weit genug zu transportieren. Das mag daran liegen, das wir zwei Fronten haben: Den einen müssen wir TDD & evolutionäres Design zeigen, den anderen begreifbar machen das es auch Planung & Entwurf braucht.
Grüße
Sebastian
June 28th, 2010 at 11:47
[...] Gedanken zu Dojos [...]