Das letzte Münchener Coding-Dojo war schon ein ganz besonderes. Wir, die Münchener Dojo-Crew waren zu Gast beim dotnetpro.powerday und waren überrascht, dass uns der Veranstalter vor dem Coding Dojo sogar noch Snacks & Getränke gestellt hat. Einfach nur Toll! Meinen herzlichen Dank an Florian Bender und den dotnetpro.powerday!

Doch nicht nur die Location war ganz besonders, sondern auch das “Line-up” der Teilnehmer. Es hatten sich mehr als 20 Teilnehmer für das Dojo auf der Xing-Gruppe angemeldet – und es gab „on top“ noch ein gutes Dutzend Interessierter, die nach einem ganzen Tag geballter C#-Wissensvermittlung noch „Power“ genug hatten, beim Dojo dabei zu sein.

19:00 Uhr – es geht los, das Dojo wurde von mir mit einleitenden Worten eröffnet. Ich habe für die Neulinge in der Runde noch kurz die „Rahmenbedingungen“ abgesteckt: Lösen eines Code Kata per TDD, aktiv und gemeinsam. Alle coden, einer tippt (wir waren wieder im Prepari-Modus). Es gibt kein Falsch und kein Richtig, es gibt keine dummen Fragen und keine dummen Antworten. So einfach ist das.

Ich habe dann auf Grund der großen Teilnehmerzahl den Vorschlag der Gruppenbildung unterbreitet und zur Abstimmung vorgelegt. Wir haben uns gemeinsam für eine große Gruppe statt zwei kleiner Gruppen entschieden.

Danach ging es auch schon zur Vorstellung der Kata’s: Ich hatte mit Pete gemeinsam eine Vorschlagsliste erarbeitet: KataTennis, KataRomanCalculator und KataBankOCR. Ein seltenes, aber schönes Erlebnis waren diesmal die Alternativ-Vorschläge der Teilnehmer, darunter Sudoku oder FizzBuzz. Nach einer kurzen Abstimmungsrunde war es soweit: KataBankOCR wurde gewählt.

Wie wird morgen das Wetter?

Die übliche „Anforderungsrunde“ wurde damit eingeleutet. Ich habe das Kata näher vorgestellt und nach offenen Fragen abgefragt. In dieser Phase haben wir uns auf besondere Dinge wie z.B. Zeilenhöhe und Ziffernabstand geeinigt und die Anforderungen klarer umrissen. Nach ca. 15 Minuten war es dann soweit, auf meine Frage „Noch offene Fragen?“ gab es nur noch die Gegenfrage „Wie wird morgen das Wetter?“. Damit war die Anforderungsrunde abgeschlossen.

Es konnte also losgehen. Aber wie legt man jetzt denn los? Das war die nächste Frage. Pete hatte Visual Studio schon offen, das Projekt war angelegt, das Test-Framework eingebunden. Die Tools waren bereit. Doch waren es die Teilnehmer auch? Eine geteilte Stimmung machte sich breit. Während die einen am Grübeln über den ersten Test waren, waren die anderen mit der Vorgehensweise nicht einverstanden und wollten erst mal „generell eine Architektur herausarbeiten“. Auch hier half die Abstimmung weiter. Mit äußerst knapper Mehrheit ließ man sich auf die Erarbeitung des ersten Tests ein, ohne eine „Lösungsanalyse“ im klassischen Sinne gemacht zu haben.

Test schreiben heisst nachdenken

Das herausarbeiten des ersten Tests war garnicht so einfach wie es viele vielleicht vermutet hatten. Es gab Diskussionen über die Datenstruktur (string vs. List<string> vs. IEnumerable<string>) und wir taten uns schwer, einen richtigen Namen für unseren Test zu finden. Doch nach knapp 10 Min. hatten wir endlich den ersten Test, der das „Digit 0“ testet, rot. Und schon ging es an die Implementierung: „return 0;“! Ach, wie schön, das erste Erfolgserlebnis ist da!

Das motiviert schon gleich zum nächsten Test, der Erkennung von „Digit 1“. Schnell wurde der Test geschrieben und dann ging es wieder an die Implementierung. Diesmal war es natürlich schon schwerer, denn schließlich musste jetzt erkannt werden. Aber jetzt fingen auch die Neulinge an, aktiv an der Lösung zu arbeiten und brachten Vorschläge und Kommandos in die Runde ein. Es dauerte nicht lange, und man hatte mit einem einfachen String-Vergleich die Implementierung fertig.

Red-Green-Maybe<Refactor> ?

Doch irgendwie war man nicht ganz mit dem Ergebnis zufrieden, denn der Ruf nach Refactoring wurde lauter. Golo mahnte an: „Es heisst Red-Green-Refactor und nicht Red-Green-Vielleicht-Refactor“. Sein Standpunkt: wenn man Refactoring nicht „im Kleinen“ und von Anfang an betreiben würde, dann würde der Aufschub noch mehr Probleme schaffen.

Andere wiederum sahen das nicht „so steif“, sondern beriefen sich auf den berühmten „Smell“. D.h. wenn eine Implementierung offensichtlich „Bereinigung verlangt“ um die Funktionalität weiter vorantreiben zu können, dann werde refaktorisiert. Auch hier die Abstimmung. Auch hier ein ganz knappes Ergebnis für den Aufschub des Refactorings.

Gibt es ein ABS beim TDD ?

Also ging es weiter zum nächsten Test, der im Übrigen wieder von einem Neuling angeregt wurde. Was tun mit „Leerstellen“? Also wie kann man überprüfen, dass *keine* Ziffer an einer Stelle des „virtuellen Displays“ dargestellt wird. Raunen machte sich breit beim erarbeiten des Tests. Einige Stimmen waren für „einfach 0 zurückliefern“ („Vollgas“ weiter machen), andere wiederum wollten den Test nicht machen stellten den derzeitigen Lösungsansatz in Frage („Vollbremsung“).

Eine kleine Randgruppe wollte den Test durchführen, aber den Target (also die zu testende Methode) wechseln ( „Ausweichen“). An dieser Stelle gingen die Meinungen und Ansichten wieder auseinander. Eine etwas heftigere Diskussion wurde entfacht, doch leider konnte Sie nicht weitergeführt werden, denn unsere „Dojo-Zeit“, die wir uns als Timebox festgelegt hatten, war abgelaufen. Doch die Frage war im Raum und verlangt natürlich auch nach einer Antwort: Gibt es ein “ABS” (Anti-Blockier-System) beim TDD?

Die Moral von der Geschichte…

Die abschließende Retrospektive war wie immer sehr aufschlußreich und gab einen bunten Mix an Feedback zurück. Unter anderem wurde die TDD Vorgehensweise gelobt und kritisiert, die Gruppengröße bemängelt, das Ergebnis sowohl als „sehr gut“ und „sehr schlecht“ attributisiert, die „Planlosigkeit“ kritisch betrachtet, das vernachlässigte Refactoring angemahnt. Alles in allem jedoch, war es für jeden erkenntnisreich, denke ich.

Doch ganz besonders war dieses Dojo eine Lehre für mich. Ich konnte in diesem Dojo wieder vieles Lernen. Ich lernte z.B. dass „Neulinge“ sehr wertvoll für eine Gemeinschaft sein können, weil sie unvoreingenommen, ja man mag fast sogar sagen „positiv naiv“ auf Dinge blicken. Das ist nicht nur frisch, sondern auch konstruktiv. Dazu gab es noch eine Reihe weiterer Erkenntnisse, die mich zum Nachdenken gebracht haben. Ich will hier auch auf diese Erkenntnisse und die Konsequenzen daraus eingehen.

Die einfachste Lösung gewinnt

Da wäre zum Beispiel die immer wieder aufkeimende Diskussion in Coding Dojo’s, ob man nun nach der Anforderungsanalyse über einen generellen Lösungsweg nachdenken sollte (Knobler) oder „einfach“ sich auf den Code stürzen sollte (Coder). Ich habe zu diesem Thema einen besonderen persönlichen Standpunkt, den ich noch in einem gesonderten Artikel im Detail niederschreiben werde – hier würde solch ein Exkurs den Rahmen deutlich sprengen.

Fakt ist, dass wenn eine solche Diskussion im Dojo auftaucht, diese Diskussion auch geführt werden muss. Hier zählt der Erfahrungsaustausch, hier zählt der Lernwille, der das führen der Diskussion bedingend macht. Generell ist es natürlich so, dass beim Coding Dojo „Test-First“ entwickelt wird. Ob das per TDD, BDD oder ATDD geschieht, sei erstmal dahingestellt. „Test-First“ ist im Sinne der agilen Methoden, besonders aber im engeren Sinne XP wörtlich zu verstehen. Um den TDD-Neulingen oder TDD-Zweiflern das etwas näher zu bringen, zitiere ich Uncle Bob:

“The act of writing a unit test is more an act of design than of verification. It is also more an act of documentation than of verification. The act of writing a unit test closes a remarkable number of feedback loops, the least of which is the one pertaining to verification of function.”

Also ganz klar: Nein, es soll beim Coding Dojo keine „gesamte Lösung“ erarbeitet werden, bevor man das programmieren anfängt. Sondern: Ja, beim Coding Dojo wird nach klarer Anforderungsanalyse sofort der erste Test in Angriff genommen. Dazu muss man natürlich auch nachdenken. Keiner wird daran gehindert, sich für diesen Test (und manchmal sogar den nächsten) eine Strategie zu überlegen. Es ist eher so, dass man sich gegenseitig zu einer klaren Testdefinition motiviert.

Chief Operating Development Engineer Lead Executive Senior Sensei

Darüber hinaus gab es in diesem (sowie auch in den vorangegangenen) Dojo vermehrt Stimmen, die eine “Führungsrolle”, eine “bewertende und entscheidende Instanz“, einen „Chefentwickler“ oder ähnliches eingefordert haben. Auch hierzu gibt es für das Coding Dojo eine klare Vorgabe. So gibt es beim Coding Dojo z.B. verschiedene Formate, wie das Prepari oder Randori oder andere. Ich möchte hier nur kurz anmerken, dass ich in einem separaten Artikel auch auf diese verschiedenen Verfahren und Modi in Dojo’s eingehen werde. Für’s erste soll es reichen, dass es verschiedene Arten gibt.

Je nach Format gibt es auch verschiedene Rollen. In den Münchener Dojo’s haben wir oft – wie auch dieses Mal – das einfachste Format gewählt: Prepari. In diesem Format gibt es 3 Rollen: den „Hacker“ (von mir öfter flapsig als „CodeMonkey“ bezeichnet), den „Operator“ (der Organisator und Moderator, manchmal etwas irreführend auch „Leiter“ des Dojo’s) und natürlich die „Contributor“, die aktiven Teilnehmer des Dojo’s.

Im Prepari-Format (sowie auch in allen anderen) gibt es keine CODELESS-Rolle. Es gibt also beim Coding-Dojo niemanden, der die Rolle des „CODELESS“ einnimmt. Das Gegenteil ist der Fall: es wird explizit beim Coding Dojo eine CODELESS-Rolle vermieden. Und für diejenigen, die die Rolle nicht kennen:

Definition:
CODELESS = “Chief Operating Development Engineer Lead Executive Senior Sensei”

Im Coding-Dojo die “Anti-Rolle” der führenden, leitenden, entscheidenen Person(en). Kann von einer oder mehreren Personen erfüllt werden. Sobald die Gefahr für so eine Rolleneinnahme besteht (ein „Smell“ sozusagen), darf (und soll) jeder zur Vermeidung der Rolle folgenden Satz sagen:

„We don’t want (to) CODELESS, we want (to) code more !“

Sobald also die Rolle eingenommen wird, sind alle anderen dazu verpflichtet, die Rolle der oder den Personen wieder zu entziehen. Im Coding Dojo gilt das Prinzip der Gleichstellung. Alle Meinungen haben per se den gleichen Wert. Die Auswertung der Meinungen geschieht gemeinsam. Entscheidungen werden gemeinsam getroffen. Diskussionen werden gemeinsam gestartet und gemeinsam beendet. Keiner darf sich besser stellen, keiner soll sich schlechter stellen.

Rei

Jeder ist in dieser „Coding Dojo“-Gemeinschaft nun gleichgestellt – ein schönes Recht. Doch gibt es auch Pflichten für die Teilnehmer? Oft werde ich nach „Voraussetzungen“ für die Teilnahme des Dojo’s gefragt. Ich antwortete auf diese Frage meist mit folgenden Sätzen:

„Nicht viel. Interesse, Wissbegierde, Neugier für .NET und moderne, professionelle Software-Entwicklungs-Methoden. Aktive Teilnahme & Beitrag zur Lösung der gestellten Programmieraufgabe.“

Das hat den meisten Fragestellern ausgereicht, um sich ein Bild machen zu können. Aber dennoch haben wir immer wieder Probleme mit dem Selbstverständnis der Teilnahme am Dojo. Ich denke, dass es dafür mehrere Gründe gibt. Manche denken, ein Dojo sei so „informell“, dass es keine Regeln gäbe. Andere wiederum vergleichen es mit anderen Formaten, wie z.B. einem Workshop, Vortrag oder Fishbowl. Um diesen „Interpretationen“ etwas mehr Linie und Substanz zu geben, stelle ich die Teilnahme-Voraussetzungen auf eine etwas formalere Ebene. Die folgenden Regeln sind Grundregeln (Rei bzw. Reishiki), die für die Teilnahme an einem Coding Dojo bedingend sind:

§1 – Aktivität
Der ehrliche Wille, einen aktiven, fokussierten Beitrag zum „Lernen & Lehren“ zu leisten.

Es gibt beim Coding Dojo niemanden, der sich nicht einbringen darf. Das hört sich ein wenig nach „zur Aktivität gezwungen sein“ an. Und ganz offen: Ja, so ist es auch. Mitdenken, Mitwirken, Mitreden – das ist eine Pflicht für den Teilnehmer im Coding Dojo. Dennoch gibt es natürlich „Interessierte“, die sich „das Mal anschauen“ möchten. Das war bisher immer möglich und das wird es auch weiterhin. Aber: es darf nicht zur Gewohnheit werden. Deswegen folgende Regelzusätze:

§2 – Respekt
Der ehrliche Wille, sein Gegenüber anzunehmen wie er ist.

Sie oder ihn, seine Haltung, seine Meinung und sein Wissen zu würdigen um damit das „Lernen & Lehren“ zu stärken. Einher geht dabei auch Höflichkeit bei Kommunikation und Kollaboration. Adequate Wortwahl, konstruktive Beiträge und kultivierte Gemeinsamkeit sind die Pflicht jedes Dojo-Teilnehmers. Um dies zu Gewährleisten, gelten folgende Regelzusätze:

§3 – Optimismus
Der ehrliche Wille, mit Freude und positiver Einstellung zum „Lernen & Lehren“ beizutragen.

Die positive, offene Grundhaltung eines jeden Teilnehmers ist bedingend für eine gute Unterstützung des „Lernen & Lehren“. So ist es für jeden Dojo-Teilnehmer eine Freude, dabei zu sein und die anderen bei sich zu haben. Sollte „mal einer einen schlechten Tag haben“ ist es nicht so schlimm. Aber man sollte auch im Sinne des Dojo’s offen zu sich selbst sein. Ist die Laune im Keller, so macht es für einen selbst nicht viel Sinn – und damit für die Gemeinschaft auch nicht. Niemand im Dojo nimmt es Übel, wenn man mal „keine Lust“ hat, dabei zu sein. Um die positive Einstellung im Dojo zu unterstützen, gelten folgende Regelzusätze:

§4 – Zwanglos
Der ehrliche Wille, freiwillig, ohne Druck, Wettbewerb oder Leistungsziel das „Lernen & Lehren“ zu verfolgen.

Diese Regel ist besonders wichtig, denn sie nimmt jeglichen Druck von allen. Keiner ist dazu verpflichtet, eine Sache „richtig“ oder „fertig“ zu machen. Niemand zwingt die Teilnehmer, sich an eine bestimmte Technologie, Meinung oder Vorgehensweise zu richten. Wenn überhaupt, dann sind es die Teilnehmer, die selbstbestimmt, freiwillig und gemeinsam sich selbst Verbindlichkeiten zusprechen. Um dies im adequaten Rahmen zu gewährleisten, gelten folgende Regelzusätze:

Diese oben genannten vier Grundregeln sind für mich essentielle Voraussetzungen für die Teilnahme an einem Dojo. Oftmals ist es garnicht so schwer, diesen Bedingungen gerecht zu werden, doch wir durften in der Vergangenheit auch erleben, wie sich der eine oder andere Teilnehmer mit diesen Werten schwer tat.

Make it simple

Es gibt noch vieles mehr, das ich über das Coding Dojo, die Regeln und Werte des Coding Dojo und auch die Dynamik und Magie des Coding Dojo schreiben könnte, und ich werde es wohl nach und nach auch tun. Doch bei all diesen Hintergrundinformationen und den eben etwas formaler beschriebenen Regeln gilt es den Grundsatz der Einfachheit zu wahren. Solange es nicht wirklich notwendig ist, wird es keinen weiteren „Ballast“ oder „Verkomplizierung“ der Sache geben. Weder mit weiteren Formalismen oder irgendwelchen Hierarchien, unnötigen Gedankenwindungen oder theoretischen Methodenspielchen. Das gilt für Software, das gilt für TDD, das gilt für gemeinschaftliches Arbeiten, also gilt es auch für das Coding Dojo. Frei nach Albert Einstein:

„Make it simple, but not simpler“.

Für die Interessierten sei noch das Original-Zitat erwähnt:
“It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.”

Ich, der Ilker

Nach diesem regelrechten Aufsatz an Regeln und Bestimmungen gibt es einen weiteren wichtigen Punkt, der unbedingt erwähnt werden muss. Alle die o.g. Regeln beziehen sich auf meinen Eindruck, meine Meinung und meine Anschauung. Es ist also „Ilker’s Coding Dojo“, welches sich diesen Rechten und Pflichten unterwirft.

Warum erwähne ich das? Ganz einfach, weil jeder auf dieser Welt das gute Recht hat, Coding Dojo’s zu machen. Jeder hat so gar das gute Recht, Coding Dojo’s so zu machen, wie er sich das vorstellt. Das ist auch gut so, denn Diversität ist ein wichtiger Faktor für Fortschritt. Aber es birgt auch Potenzial für Missverständnis und Verkennung. Der eine macht Coding Dojo’s mit dem Streben nach Kampf und Perfektion. Ein weiterer macht Coding Dojo’s um neue Sprachen zu erleben und zu erforschen. Ein anderer macht Coding Dojo’s, um anderen zu zeigen, wie man was macht und die Richtung vorzugeben. Aber ich mache Coding Dojo’s nicht (nur) deswegen. Meine Motivation ist das Motto, welches ich immer wieder versuche zu transportieren: „Lerne & Lehre“.

Bei „meinem“ Coding Dojo steht der lockere Erfahrungsaustausch im Vordergrund, gebunden durch eine konkrete, kleine, realisierbare Aufgabe. Doch es geht nicht um einen netten Plausch oder Brainstorming, sondern um Lernen und Lehren. Wer nicht genau weiß, wie herausfordernd und anspruchsvoll diese beiden Disziplinen sind, dem rate ich, sich damit ein wenig auseinanderzusetzen.

Weiterhin mache ich Coding Dojo’s aus freien Stücken, weil es mir Spaß macht und ich weiter Spaß damit haben möchte. Ich mache es, weil ich eine tiefe, feste Überzeugung habe, dass jeder von anderen lernen kann und jeder den anderen lehren kann.

Ich respektiere diejenigen, die Coding Dojo’s „anders“ sehen, die etwas anderes darunter verstehen oder es anders kennen. Wie gesagt, jedem steht es frei, selbst Coding Dojo’s zu machen und sie so zu machen, wie er es für richtig hält. Ich habe die „Coding Dojo’s“ nicht erfunden, ich bin nicht der Coding-Dojo-Oberlehrer, ich bin kein Kata-Mönch und auch kein Dojo-Messias. Ich bin der Ilker, der Coding Dojo’s macht. Punkt.

Latifa-Dojo

So, und als genau dieser Ilker, der diese Coding Dojo-Bewegung in die .NET-Welt getragen hat, als der Ilker, der Erfahrung mit Coding Dojo’s verschiedener Formate hat, als der Ilker, der das „Lernen & Lehren“ mit Code Kata’s und TDD/BDD & Design Patterns sowie Best Practices in den Vordergrund stellt, als genau dieser Ilker stelle ich die oben genannten Regeln für die Art der Coding Dojo’s auf, die ich mir vorstelle.

Diejenigen, die sich für Coding Dojo’s interessieren, schon mal bei dem einen oder anderen dabei waren, sogar den Weg mit mir „mitgegangen“ sind oder einfach mal gerne dabei sein möchten – ja euch alle – bitte ich um Vertrauen. Bitte, vertraut mir und geht den Weg, den ich hier beschreibe, wenn ihr Coding Dojo’s macht und mitmacht. Verlangt Aktivität, Respekt, Optimismus und Zwanglosigkeit. Verfolgt das Ziel des Lernen & Lehrens. Fordert genau diese Art von Coding Dojo’s, denn diese Coding Dojo’s sind es, die uns alle weiter bringen. Fordert von Coding Dojo’s diese Werte und diese Ziele – von Veranstaltern, von Operatoren, von Teilnehmern, von euch selbst. Ich werde es tun.

Im Sinnbild der asiatischen Kampfkünste, welches unschwer erkennbar auch mit dem Coding Dojo transportiert wird, möchte ich hiermit das oben geschilderte „Format“ als einen „Dojo-Stil“ etablieren. Es widerspricht natürlich dem gemeinschaftlichen Denken, nun von „Ilker’s Dojo-Stil“ zu sprechen oder es so zu kommunizieren. Personifizierung ist nicht zielführend. Wie gesagt, keiner ist besser gestellt als die anderen, keiner ist schlechter gestellt als die anderen.

Dennoch ist es ein stückweit meine Handschrift und meine Vorstellung eines Coding Dojo’s. Deswegen möchte ich bei der Schaffung dieses „Dojo-Stils“ noch eine kleine persönliche Note einbringen. Ich mache das jetzt mal einfach und gebe „meinem“ Dojo-Stil einen Namen: Latifa.

Latifa kommt vom arabischen latif, welches frei übersetzt “höflich, freundlich, sanft” bedeutet. Ich habe es gewählt, weil es im türkischen (latife) für „zuvorkommend, manierlich“ und manchmal sogar „gentlemen-like“ angewendet wird. Es spiegelt für mich die Grundvoraussetzung für gemeinsames Tun & Wirken wider, die auch für ein erfolgreiches Lernen & Lehren notwendig ist.

Es gibt so vieles, welches wir von anderen, unseren Ahnen und anderen Kulturen lernen können. Doch eine Sache ist allen gemeinsam, der Respekt und die Höflichkeit. Wer sich intensiver mit dieser Werte-Einstellung auseinandersetzen möchte, dem Rate ich das Studium (das meine ich wörtlich, also „studere“) des Shoto-Niju-Kun, der 20 Verhaltensregeln von Funakoshi für das Karate-Do.

Feedback im Mittelpunkt

Ein zentrales Element des fortschreitens und verbesserns ist das Feedback. Nach geleisteter Arbeit ist Feedback wichtig, um daraus Erkenntnisse zu gewinnen und damit sein Handeln zu adaptieren. Das ist eigentlich ein Naturgesetz.

Ich möchte diesem Naturgesetz auch hier folgen und möchte abschließend um euer Feedback bitten. Bringt euch ein, macht mit und gestaltet mit. Schreibt mir, was ihr denkt und was ihr machen würdet. Ich freue mich über jedes Feedback.

Doch bei all dem Wirken & Tun rund um das Coding Dojo stelle ich klar und und kommuniziere es mit deutlichen Worten: Ich werde weiter Coding Dojo’s machen, genauer gesagt Coding-Dojo’s im Latifa-Stil. Ich werde das Lernen & Lehren verfolgen und stärken. Das werde ich mit Freude und Spass machen, denn nur so ist es wertbringend und nachhaltig. Für den Latifa-Stil gelten die Voraussetzungen der Gleichheit, der Aktivität, des Respekts, des Optimismus und der Zwanglosigkeit. Die Modi im Latifa-Stil sind frei wählbar, solange sie keinen Kampfcharakter haben. Im Dojo wird gemeinsam an dem Kata gearbeitet und geübt. Es steht die Übung mit dem Code im Vordergrund, deswegen heisst es Coding Dojo.

Wege sind zum gehen da

Es soll klar sein: Für alle, die sich mit diesem, dem Latifa-Stil des Coding Dojo auseinandersetzen möchten und diesen Stil in den Coding Dojo’s erleben möchten, gibt es die wunderbare Möglichkeit sich in der Xing-Gruppe zu melden oder auf die Facebook-Seite zu schauen, um so auch die nächsten Event-Termine mitzubekommen. Ihr seid herzlich eingeladen, mit uns gemeinsam zu lernen & zu lehren.

Weiterhin soll klar sein: Für alle, die sich mit dem Latifa-Stil nicht anfreunden können oder unter Coding Dojo’s etwas anderes verstehen, kann ich folgendes entgegenbringen: Ich werde euch nicht in einem Latifa-Dojo akzeptieren. Ich werde euch nicht für die Werte des Latifa-Dojo ermutigen. Ich werde euch nicht vom Latifa-Dojo überzeugen. Ihr müsst das alles selbst tun. Ihr könnt jederzeit zu Coding Dojo’s im Latifa-Stil kommen, solange Ihr euch an die Regeln und Werte des Dojo’s richtet.

Und wenn sich im Ergebnis keiner für den Latifa-Stil interessiert, dann ist das gut, denn dann habe ich immer noch meine Überzeugung. Und wenn sich im Ergebnis einige für den Latifa-Stil interessieren, dann ist das gut, denn dann habe ich immer noch meine Überzeugung. Und wenn sich im Ergebnis alle für den Latifa-Stil interessieren, dann ist das gut, denn dann habe ich immer noch meine Überzeugung.

Comments
This article has 16 comments:

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

  • [...] Coding Dojos...
    by Erstes internes .Net Coding Dojo « if (done) { blog(); }
    on September 28th 2010

    [...] Coding Dojos wurde in letzter Zeit viel geredet. Es wurden schon Stile ausgerufen die Latifa oder Schwarm genannt wurden. Ich möchte mich nicht für einen Stil entscheiden. Mir ist es wichtig [...]

  • [...] Lerne &...
    by CodingDojo – Connect Your Brains and Be Awesome! « Christian Krause – view it, code it, share it!
    on September 6th 2010

    [...] Lerne & Lehre: Ilker’s .NET Coding Dojo [...]

  • [...] bin mir...
    by .NET Stories: Digitale Erfahrungen » Blog Archive » Auf dem Eisberg
    on July 1st 2010

    [...] bin mir durchaus bewußt, das die Erhebung meines „Latifa“-Stils ein Treiber in dieser Entwicklung war, wenn auch nicht der einzige. Jedoch war es nicht meine [...]

  • Hallo Jungs, man(frau in...
    by Christina
    on June 28th 2010

    Hallo Jungs,

    man(frau in meinem Fall) ist nur für 4 Tage nicht in Computernähe und da baut sich so eine interessante Diskussion auf!

    @Ilker: super Zusammenfassung, wo kann ich mein X darunter setzen :) ? Ich glaube – man sieht ja – unser kleines Münchner Dojo in eine neue Phase angekommen, es wird sozusagen aus eine Familienunternehmen zu einer AG. Dann ist es auf jedem Fall an der Zeit, diesen “Kodex” zu definieren. Und als “alter Dojohase” kann ich nur bescheinigen, du hast alles bedacht, nicht ausgelassen. Genau so läuft es ein latifa-Dojo. Und apropos: danke dafür!

    @Christoph: JEDER, der teil nimmt, bringt seine persönliche Erfahrungen also seine eigene Sicht auf die Dinge, egal ob er .NET kann oder nicht. Einer unseren beharrlichsten Teilnehmer beschäftigt sich mit in UML(!) und das hält ihn trotzdem nicht davon ab, nach der Arbeit hin zu hetzen und die Abende mit C#-Programmierern zu verbringen. Also mach einfach mit!

    @Alle: ich hoffe sehr, dass ihr alle zu dem nächsten Open Space kommt – wahrscheinlich nach Leipzig – dass wir dieses Thema endlich mal persönlich auseinander nehmen (und wieder zusammensetzen) können. Bis dann freue ich mich schon auf weitere latifa-Dojos und alle anderen Arten wo ich von euch lernen kann :)

    Schöne Grüße
    Christina

  • @Steffen: :-) Der...
    by Mike Bild
    on June 28th 2010

    @Steffen: :-) Der arme Ilker. Ich mit der Minderheitenmeinung in seinem Blog. Sorry, Ilker! Lass es mich mal bitte mit einem Wikipedia Artikel Auszug hier von meiner Seite aus vorerst abschließen.

    “Planung ist die gedankliche Vorwegnahme von Handlungsschritten, die zur Erreichung eines Zieles notwendig scheinen. …”

    Das, nicht mehr und nicht weniger, haben wir, meiner Meinung nach, positiv im sinne einer adäquaten Planung gemacht. Ob das jetzt ein positives Beispiel für Planung im CodingDojo ist? Fair?!? Das war und sind meine, natürlich subjektiven, Erkenntnisse. Und … Erkenntnisse sind immer wahre Erkenntnisse! In diesem Sinne beste Grüße und bis bald, Mike

  • Hi Mike, sicherlich mussten...
    by Steffen Forkmann
    on June 28th 2010

    Hi Mike,

    sicherlich mussten wir den “Kunden” am Anfang löchern und seine Anforderungen abfragen. Das steht außer Frage – das finde ich nicht nervig. Ich wehre mich aber dagegen zu sagen, dass das was wir danach gemacht haben ein positives Beispiel für Planung ist. Ich meine so fair musst du doch auch sein und das zugeben.

    Grüße Steffen

  • @Ilker: Zunächst einmal...
    by Mike Bild
    on June 28th 2010

    @Ilker: Zunächst einmal auch von mir Sorry, ich nutze mal auch Kommentarfunktion für den Exkurs am Rande!

    @Steffen: :-) Wir haben durch die kleine Planung zumindest erfahren, dass der Kunde noch nicht so genau weiss und er brauchte eine kleine Weile zum nachdenken. Das hat Zeit gekostet, keine Frage. Ich stelle allerding immer wieder fest: Das Nachdenken und vor allem das Reden über eine scheinbar kleine Sache aufwendig und nervig werden/sein kann. Aber schafft es nicht auch Erkenntnis mit Mehrwert?

    Grundsätzlich bin ich deiner Meinung. Für Kata’s dieser Komplexität brauchen wir keine Planung. Sie sind einfach und jeder hat einen Plan im Kopf. Wir könnten mit TDD/BDD bis zum Punkt einer Fragestellung coden und dann fragen. Fertig!

    Aber, wie ich finde, ist Planung, neben der Abstraktion, Modellierung, Strukturierung, Organisation und Dokumentation nicht auch ein Mittel der Kommunikation, Wortfindung, Teambildung, Fokusierung und Evaluierung des allgemeinen Verständnisses der Problemdomäne für mich, für den Kunden und für alle Beteiligten? Nicht jeder braucht das, mir hilft es und ich denke anderen auch. (Zunächst den state-of-the-art zu erarbeiten = 60% auf http://www.surveymonkey.com/MySurvey_Responses.aspx?sm=ENRqMzpoGM5tKjBTTh0WG3EHmrl54odjILs0bqh4zs0%3d oder http://just-tech-reports.blogspot.com/) Klar, in diesem Fall (Kata in CodingDojos) in Breite und Tiefe unnötig. Nur, sind 15-30 Minuten Übungszeit mit “Scheinkunden/Moderator/CodeMonkey” für eine gemeinsame adäquate Planung und damit Ausrichtung/Fokussierung/Ziel unnötig, zwecklos und kontraproduktiv? Fehlen mit Planung auf einmal Fehler aus denen wir durch Erkenntnisgewinn lernen können? Führt Planung zu Leading einzelner weniger? Bekommt der Lern, Lehr und Entwicklungsprozess einen Wasserkopf und verkompliziert jetzt alles? Raubt Planung jetzt den Spass am “freien, kreativen” Tapsen in Denkfallen? Keine Ahnung -> Beobachten, Erkenntnisse sammeln, Anpassen. Mir machen “Latifa” Coding Dojo’s Online und Offline, mit und ohne Planung, etwas passiver und auch etwas aktiver durch die gemeinsamen Übungen am Code mit Gleichgesinnten viel Spass. Beste Grüße, Mike

  • Sorry Ilker, aber...
    by Steffen Forkmann
    on June 28th 2010

    Sorry Ilker, aber kurzer Exkurs @Mike:

    Fandest du die Planung vom letzten Online-Dojo wirklich so gelungen? Ich meine wir haben eine halbe Stunde nur darüber geredet, dass die Römischen Zahlen für unseren Kunden erst ab 1900 gehen müssen und zukünftig dann irgendwann “als Erweiterung” auch mal ab 1. Durch die explizite Aufnahme dieser “Vereinfachung” vom Kunden sind in der Planung ein Validator-Interface und zwei Validatorklassen entstanden – aus meiner Sicht total überflüssig.

    Ich meine es war doch offenbar jedem klar, dass der Algorithmus um korrekt laufen zu können auch alle Zahlen unter 1900 können muss. Der erste Test war ja dann auch ConvertingArabicOneToRomanShouldGiveI und nicht irgendetwas mit 1900.

    Wenn wir uns schon die Zeit nehmen alles global zu durchdenken, dann hätte ich gehofft wir überprüfen die Anforderungen auf Sinnhaftigkeit und sagen zu unserem Kunden: “Danke, dass du uns die Sache einfacher gestalten willst, aber in diesem Fall bringt es leider nichts.”

    Aber Online ist das Ganze natürlich noch schwieriger. Deswegen bin ich da trotzdem der Meinung, dass das Dojo sehr gut war.

    Grüße Steffen

  • Nachdem ich nun...
    by Mike Bild
    on June 26th 2010

    Nachdem ich nun alle Ansichten und Kommentare, auch bei Steffen Forkmann, gelesen habe, bin ich doch etwas überrascht über diese z.T. starke Differenzierung in “Stile”. Das glaube ich noch, wie auch das letzte Online Coding Dojo mir bewies, in dieser “stilisierten” Form nicht. Das nur am Rande: Ist das nicht auch das Problem beim Kampfsport? Jeder meint der Stil des anderen sei nicht effektiv genug? Beim letzten Coding Dojo konnten wir mit einer angemessenen Planung und TDD ein doch respektables Ergebnis erzielen. Was fehlte im letzten Online Coding Dojo? Übung und damit Routine! Und da ging uns die Zeit aus. Ist ok, wir lernen doch! Stefan Lieser in seinem Blog-Artikel und auch Christoph Tohermes in seinem Kommentar schrieb ähnliches und da meine ich sollte, bevor “stilisiert, abgegrenzt, fokussiert” wird, eingehakt, nachgesteuert, verbessert werden. Vielleicht sollten wir es umgekehrt betrachten? Was geht mit mit dem Verzicht auf adäquate Planung verloren? Am Beispiel der RomanNumeralsKata im Online Coding Dojo im Randori-Stil. Aus meiner Sicht ein gemeinsames Bild der groben Struktur, eine Fahrtrichtung. Die Implementierung wird in jedem Fall aus TDD gestützt. Ein gutes Ziel! Mit Mehrwert für, insbesondere bei verteilten, Online Coding Dojos. KIAI!

  • @Ilker: Natürlich kann...
    by Ralf Westphal
    on June 26th 2010

    @Ilker: Natürlich kann ich mich mit den Latifa-Werten indentifizieren. Kein Problem. Die sind mir nur nicht genug.

    Sie sind wichtig. Gut, dass du sie aufgeschrieben hast. Und dein Stil ist halt, dass du nicht mehr willst im Dojo. Unter dem Dach der Programmierung reichen dir diese Werte. Das ist Latifa, das ist Ilker. Alles wunderbar.

    Damit wir aber eben nicht aneinander rennen, nehme ich den Ball auf und sage eben: das ist der Latifa-Stil und es kann und soll gern andere Stile geben. Ob die orthogonal sind oder Latifa erweitern, ist ja egal. Sie sind eben anders.

    Steffen Forkmann scheint mir auch den Latifa-Stil zu favorisieren. Ilker macht Latifa. Da seid ihr schon zwei. Gut so.

    Beispielsweise Mike, Stefan Lieser und ich denken aber anders. Wenn Coding Dojo nicht ein Stil sein muss, dann können wir nun ohne Reiberei einfach einen anderen Stil ins Leben rufen. Ein Name ist noch zu finden dafür. Dann stehen Latifa und XXX Stil nebeneinander. Dann haben sie Namen und die Community kann drüber sprechen. Dann kann sie vergleichen und sich dem einen oder anderen zuwenden. Oder der eine oder andere verändert sich auch über die Zeit. Entwicklung findet statt.

    Ich finde es gut, dass du hier nochmal Position bezogen hast. Ich werde das gleichfalls in einem Blog-Artikel tun. Ist schon in Arbeit ;-)

    -Ralf

  • Ja, wenn Regeln,...
    by Mike Bild
    on June 26th 2010

    Ja, wenn Regeln, Werte oder Heuristiken nötig bzw. fördernd sind begrüße ich sie auch. “Doch es ist soweit also muss es auch so sein …” Meinst Du den, dass Deine 4 Grundwerte nicht mehr genügend vertreten sind, oder ist eher eine “Evolutionsstufe” erreicht? Deshalb der “Formalismus” von Grundwerten innerhalb des jetzigen Spektrums bis zur nächsten “Evolutionsstufe” oder “Fehlentwicklung”? Seiner Vision des CodingDojos einen Rahmen zu geben, diese festzuhalten und zu kommunizieren finde ich sehr richtig! Auch das gehört für mich zu Aktivität, Respekt, Optimismus und Zwanglosigkeit. Und hier finde ich auch einen schönen Übergang zum “heiß” diskutierten “Nachdenken, dann Coden”. Ich verstehe Deine Haltung und bin auch hier gleicher Meinung, die Code-Katas im Rahmen eines 2 stündigen CodingDojos sind nicht ohne Grund einfach gehalten. Ich kann sie ohne den ganzen “up front overhead”, aber auch ohne TDD lösen. Bei FizzBuzz ginge das allein ohne TDD in sag ich mal 15 Minuten; kommt TDD hinzu vielleicht 40 Minuten. Unit-Test vielleicht auch per TDD ist gut und wichtig, sie gibt dem Code eine formale Grundlage und fördert “Nachdenken, dann Coden”. Aber Architektur/Design “up front” eben auch. Es bietet ebenso formale Grundlage, “Nachdenke, dann Coden” und mehr – Überblick, Struktur, Verständlichkeit, Kommunikationsgrundlage.

    Aber um inhaltliche Übungen geht es innerhalb eines CodingDojos meiner Meinung nach primär nicht. Teilnehmer eines Coding Dojo können in mehrheit code lesen und schreiben und lauffähige Programme erzeugen.Es geht um Übung der und/oder weiterer Methoden/Techniken einer Implementierung. Wie bei Übungungen auf einem Instrument geht es nicht mehr nur um Noten lesen und schreiben und Töne ausstoßen. Es geht um Geschwindigkeit, Sicherheit, Eleganz, Souveränität, Spektrenbreite, Exploration. Natürlich spiele ich bei meinen Übungen mit dem Instrument ein Lied, aber ich spiele es nicht wie immer. Ich experimentiere und trainiere meine Fähigkeiten.

    Softwareentwicklung ist für mich eben nicht mehr wie es damals noch ging die reine Programmierung einer Lösung. Aus Softwareentwicklung ist viel mehr geworden und es wird auch immer spektrenreicher werden. Heute geht es, so meine Erfahrungen, selbst bei kleinen und Kleinstprojekten nicht mehr nur um Code oder ein funktionierendes Programm. Die Anforderungen an Entwickler steigen. Heute ist es beispeilsweise selbstverständlich immer Fachliteratur zu lesen und sich ständig fortzubilden. Das war nicht immer so. Softwareentwicklung fängt für mich bei der Kommunikation der Vision (Kataerläuterung) an und es geht weiter: Erarbeitung der Features und Akzeptanzkriterien, eine Umrahmung der Implementierung durch eine adäquate, verständliche, schriftliche Design/Architektur, das festlegen einer Projektstruktur, der Entwicklungstools, Implementierungsmethodik und technik, Tests, die Implementierung selbst, Kommunikation der Probleme und Erfahrungen, Feedback und Review und das im Team in einer Timebox.

    Das ich nicht alles innerhalb eines Coding Dojos zeitgleich in aller Tiefe durchführen kann, muss klar sein. Dazu ist ein CodingDojo an einem Abend auch nicht da. Aber der Rahmen sollte, dass ist mein Standpunkt, einen Wechsel des Fokus zulassen sobald es die Teilnehmer wünschen, auch wenn es durch die Spektrenbreite nicht einfacher, sondern komplizierter werden kann. Aber wie sagtes Du auch schon “Keep it simple…” und daraus folgt “Alles zu seiner Zeit”.

  • [...] in den...
    by Stefan Liesers Blog » Blog Archive » Gedanken zu Dojos
    on June 26th 2010

    [...] in den Blogs von Steffen und Ilker bereits über verschiedene Aspekte von Dojos diskutiert wurde habe ich den Eindruck, dass ein [...]

  • Hallo Ilker, erstmal vielen...
    by Christoph Tohermes
    on June 26th 2010

    Hallo Ilker,

    erstmal vielen Dank für das einnehmen einer Position. Ausgehend davon lässt sich wesentlich besser über das Thema disktutieren, wenn schonmal jemand eine klare Meinung vertritt. Der “Latifa”-Stil gefällt mir sehr gut. Die vier Grundregeln oder Vorstellungen entsprechen dem, wie ich mir die Arbeit in einem Team gerne immer wünschen würde. Das die Realität oft anders aussieht dürfte hinlänglich bekannt sein und haben wir glaube ich auch alle schonmal selbst erlebt.
    Da ist es doch gerade in Aktivitäten während der Freizeit umso wichtiger eine angenehme Grundstimmung zu haben. Den Alltag abzuwerfen und sich der Aufgabe widmen zu können.
    Beim Dojo können sich Azubis, Studenten, Programmierer, Consultants, Wissensvermittler, Manager und was es nicht sonst noch an verschiedenen Möglichkeiten gibt zusammen auf die Kata stürzen.
    Und das schöne: Gleichberechtigt. Und nach deinem Artikel sogar noch einen Schritt weitergehend: Gleichgestellt.
    Im Beruf würde an dieser Stelle oft das Problem einer Hierarchie zu Tage treten. Um mal einige Stereotypen hier herauszustellen: Der Manager ist gewohnt zu führen, der Consultant will unbedingt sein Wissen einbringen und der Azubi hat eigentlich nichts zu melden. Latifa folgend kann eine solche Situation im Dojo nicht eintreten, weil alle gleichberechtigt sind. Höflicher Umgang und gegenseitiger Respekt prägen das Bild. Sollten es zumindest.
    Ehrlich gesagt lagen bei meinem ersten Online Dojo hier einige meiner Bedenken. Fakt ist: Fachlich fehlt mir in Sachen .NET noch einiges. Ich bin einfach noch nicht firm in dieser Welt. Dazu kommen dann relativ bekannte Namen der .NET Welt, die an so einer Veranstaltung teilnehmen.
    Was also soll ich als relativer Neuling in dieser Gruppe beitragen.. was hab ich dort eigentlich verloren? Das ist für mich auch heute noch eine sehr interessante Frage.
    Meine momentane Antwort würde lauten: Interesse und Spass an der Plattform .NET, Lust zu denken und mich konstruktiv mit anderen Leuten zu einem Thema auseinanderzusetzen.
    Meine Erfahrungen waren trotz dieser Bedenken bisher sehr gut. Mir persönlich haben vor allem die Diskussionen beim Design und der verschiedenen Ansätze sehr viel gebracht. Die verschiedenen Meinungen und das Sprechen; der Zwang nachzudenken, über das, was die anderen sagen, um dann einen sinnvollen Beitrag liefern zu können. Auch als Neuling kann man sich eingebunden fühlen. Wenn man sich darauf einlässt. Und die Gruppe es zulässt.

    Weg von meinen persönlichem Empfinden und wieder zurück zum großen Ganzen.
    Du forderst “Make it simple”, was für unseren Code gilt (KISS) sollte auch für unser Dojo gelten. Finde ich auf jedenfall den richtigen Weg. Das Dojo sollte zwanglos bleiben, ohne den Druck vieler Regeln. Darum gefallen mir auch diese vier Regeln, plus die Ergänzung der Regel von Mike.
    Gleichzeitig gefällt mir auch die Idee eines Manifests. Nicht als starres Regelgebilde, mit einengenden Vorschriften. Eher ein Kodex, eine Anleitung zum lernen; unser selbst gestaltetes Miteinander wie wir es leben möchten.
    Bei Twitter hast du mich gefragt, ob ich es schriftlich brauche, um es verinnerlichen zu können. Das kann ich ganz klar verneinen. Aber ist es nicht trotzdem ein schönes Mittel interessierten Personen zu zeigen: “Schau her, das ist unser Dojo, unser Stil. Wenn dir unser Kodex zusagt, mach mit! Wir freuen uns auf DICH!” Und hier schließt sich dann der Kreis zu meinen Erfahrungen: Vieles was für dich in den Regeln selbstverständlich ist, ist vielen durch ihre tägliche Erfahrung nicht vertraut. Denn Respekt, Höflichkeit und die anderen Regeln sind nichts, was heute im Alltag selbstverständlich ist. So schade/schlimm das auch ist.

    Einen Punkt den ich etwas kritisch sehe ist folgender:

    [Meine Aussagen beziehen sich vor allem auf das online Dojo, mangels Erfahrung eines "echten"]
    Ich möchte zunächst folgende These in den Raum stellen:
    Das reine schreiben von Code kostet relativ viel Zeit und ist wenn man ehrlich ist zwar durchaus wichtig, aber nicht der Teil des Dojos, der am lehrreichsten ist. Und in den 3 online Dojos ist meines wissens noch kein Projekt fertiggestellt worden. Das einzige Meßbare Kriterium ist also die Qualität des Entwurfs und des Code.

    Ausgehend davon steht für mich daher die Strategie im Vordergrund. Wie gehen wir das Problem an? Was sind unsere probaten Werkzeuge? Wie arbeiten wir als Team? wie wird unser Code besser?
    Man könnte nun sagen, wir schaffen einfach verschiedene Formate. Architecture Dojo – XP Dojo – Design -Dojo usw.
    Doch für mich wäre der geeignetere Weg die verschiedenen Elemente sinnvoll in einem Stil zu vereinen und einen Mittelweg zu finden in dem Geschmacksrichtungen der Dojos innerhalb des Latifa – Stils vereint werden. Mit dem Ziel “Lerne & Lehre” erweitert auf “Lerne & Lehre, mit Spaß in und an der Gemeinschaft”

    Ich werd das später noch ergänzen, aber als erste Meinung reicht das denke aus ;)
    Grüße
    Christoph

  • @Ralf: Welche Werte...
    by Ilker Cetinkaya
    on June 26th 2010

    @Ralf: Welche Werte des Latifa-Stils sagen Dir denn nicht zu? Wo siehst Du für Dich mit den Werten & den Vorstellungen ein Problem? Das würde mich schon interessieren.

    @Mike: Naja, also ganz offen: Wenn es immer so selbstverständlich ist und auch so abgelaufen wäre, dann wäre dieser “Formalismus” garnicht erst notwendig gewesen (siéhe: Make it simple, but not simpler). Doch es ist soweit also muss es auch so sein, dass man solche “Selbstverständlichkeiten”, wie Du oder ich es empfinden, trotzdem klar und deutlich formulieren muss. Erst so kann man differenzieren. Der Ralf z.B. sieht schon “andere” Stile. Ergo: Er kann sich offensichtlich nicht mit den Latifa-Werten identifizieren und sieht das anders.

    Darüber hinaus freue ich mich, dass due den Latifa-Stil und die 4 Regeln gut findest. Es ist leideir im Artikel etwas implizit, aber diese 4 Grundregeln basieren auf dem Fundament der “Gleichstellung” (siehe Vermeidung des CODELESS). Und Gleichstellung ist auch “gleich stellen” – auf einer Augenhöhe, auf einer Ebene. Das ist etwas subtil differentes im Vergleich zu “Gleichberechtigt” – Gleichberechtigt heisst nur gleiche Rechte. Gleichgestellt heisst gleiche Rechte, gleiche Pflichten, gleiche Ehre, gleicher Respekt, gleiche Kritik, gleiches Gewicht.

    Überdies gebe ich Dir mit der 5. Grundregel vollkommen recht. Natürlich ist der ehrliche Wille der kontinuierlichen Verbesserung ein fundamentaler Wert. Aber noch sehe ich nicht den Bedarf der “Formalisierung”. Ich gehe einfach davon aus, dass jeder, der beim Coding Dojo dabei ist, das auch so sieht. Genau so, wie ich es bei den ersten 4 Werten auch getan habe, bis ich (eventuell) feststelle, dass doch eine Formalisierung notwendig wird. Was meinst Du? Und Mike: Fällt Dir was auf? ;-)

    Zu dem “heiss” diskutierten “Nachdenken vor Coden”-Thema: Ja, nachdenken bevor man programmiert ist super. Das mache ich auch. Offen gesagt mache ich das die ganze Zeit. Insofern finde ich dass eine ganz natürliche Sache. Und: In jedem Coding Dojo wird das auch gemacht. Nur eben nicht in dem Maße, wie es von Ralf und auch von Dir verlangt wird. Ein Code Kata ist eine derart überschaubare Aufgabe, dass sich eine komplette (wenn auch nur grobe) Lösungserarbeitung “up-front” nicht lohnt. Ganz im Gegenteil. Ich denke auch, dass ein *Coding* Dojo dazu da ist, Lösungen auch ohne “kompletten Überblick” zu schaffen. Das ist schwer zu erklären, aber gut zu lernen. Ein Grund mehr für Coding Dojo’s dieser Art, wie ich meine. Diese und andere Gründe bestätigen mich, nicht von meiner Überzeugung zu weichen und weiter nach “Think before you test/design a specification, but only think about your test/design specification.” zu verlangen.

    Hmm, Mike, zu der Diversität der Inhalte von Dojo’s gebe ich Dir Recht – aber irgendwie nur teilweise. Denn wenn es z.B. um Architektur gehen würde, dann hiesse es ja “Architecture Dojo”. Oder wenn es um Akzeptanz-Tests gehen würde, dann hiesse es ja “Testing Dojo”. Aber es geht eben um’s “Coding”. Coding ist mehrheitlich eine Spezifikations-, Design- & Implementierungsaufgabe. Architektur oder Akzeptanztests spielen dort eine eher untergeordnete Rolle.

    Doch Diversität im Sinne von verschienden Formaten des Coding Dojo’s (wie z.B. Prepari, Randori, Kumite oder andere), oder aber Diversität im Sinne des “Grenzen auslotens” (z.B. ein Ausflug in die Welt der Akzeptanztests, oder Programmieren im Notepad), oder aber Diversität im Sinne der Designvarianz (Z.b. KataFizzBuzz oder KataBowling funktional vs. obektorientiert) finde ich sind tolle Dinge.

  • Aktivität, Respekt, Optimismus,...
    by Mike Bild
    on June 26th 2010

    Aktivität, Respekt, Optimismus, Zwanglos sind aus meiner Sicht so und so Grundvoraussetzung für den gemeinsamschaftlichen Umgang miteinander. Das innerhalb des Rahmens der CodingDojos explizit noch einmal zu erwähnen bringt mich zum Staunen, da ich natürlich davon ausgehe, dass sich jeder der Spaß an CodingDojos hat mit diesen Grundprinzipien identifizieren und diese zum großen Teil auch leben kann. Ein CodingDojo ist eben mit mehr Aktivität als bei einem Vortrag verbunden. Ein CodingDojo ist Teamplay! Ein CodingDojo (und nicht nur innerhalb einen CodingDojo) benötigt Respekt im Umgang miteinander. Alle erarbeiten gemeinsam eine Lösung zu einem Problem. Hier sind Lösungsvorschläge, ob nun in der Anforderungsdefinition, Architektur, Design, Implementierung, Tests von jedem gefragt. Jeder hat das Recht seine Meinung im Rahmen der Problemlösung einzubringen und alle anderen sind aufgefordert darüber nachzudenken, eben die Meinung zu respektieren und evtl. zuzustimmen oder zu verwerfen. Optimismus ist eine positive Einstellung zu Menschen im Allgemeinen und den Problemen die bei CodingDojos im speziellen auftreten zwingend nötig. Wer kann effektiv an einem Problem gemeinsam mit anderen Arbeiten der nicht optimistisch ist und alles “Bullshit” findet? Zwanglos, klar zwanglos. Das CodingDojo ist eine freie Lerngemeinschaft. Niemand wird, mal abgesehen vom Vorsatz der aktiven Teilnahme innerhalb eines CodingDojo, gezwungen an einem CodingDojo teilzunehmen. Kreativität, Spaß, Lernbereitschaft, Lehrbereitschaft, Aktivität, Mut zur Lücke, aus Fehlern lernen, Kommunikation von Erfahrungen, und und und brauchen Zwanglosigkeit. Fehler entstehen auch mit Zwängen. Leistung, im Sinne etwas geschafft zu haben (kein Leistungsdruck), entsteht aus meiner Sicht so und so mit dem gemeinsamen Ziel, Feedback, dem ehrlichen, respektvollen Umgang miteinander. Zwanglos soll es zugehen, aber dennoch lösungsorientiert, timeboxed und dem inneren Willen und Spaß eine kleine Aufgabe zu lösen. Leistungsmessung im klassischen Sinne halte ich Rahmen eines CodingDojos für völlig unnötig.

    “Latifa-Stil” finde ich also gut! Aber klar, nur sind diese Grundregeln nicht so und so wichtige Regeln des gemeinsamen Wirken und Handelns auch außerhalb des CodingDojos? Ich meine schon, deshalb unterstütze ich deine 4 Grundregeln des CodingDojos.

    Make it simple, nach diesem Vorsatz würde ich es auch bei diesen 4 Regeln belassen. Die Teilnehmer entscheiden weitere Regeln, Vorsätze und Ausprägungen. Wobei mich Deine Haltung zu Architektur und Design nach der Anforderungsdefinition schon interessieren würde. Ich bin hier schon der Meinung nach einer Anforderungsdefinition (Feature List, User Stories oder ähnliches) eine grobe Fahrtrichtung mit einem kleinen Entwurf “up front” gemeinsam mit den Teilnehmern zu besprechen und festzuhalten. Es gibt einfach zu viele Lösungsmöglichkeiten mit zu vielen Parametern und unterschiedlichen Kenntnisniveaus. Ich halte, erst Nachdenken dann Coden, für ein wichtiges zu lehrendes, lernendes und zu übendes Grundprinzip der Programmierung im Team. Rumhacken und Erkenntnisse daraus ziehen kann ich beim Lösen einer Kata morgens vor dem Frühstück. Im Team ist eine gemeinsame Lösung gefragt und hier wird Kommunikation nötig. Dafür sollte im Vorfeld Zeit eingeräumt werden. Wie wir im Vorfeld Zeit für Design und Architektur benötigen, benötigen wir im Anschluß Zeit für Feedback, Retrospektive, Review. Besonders hier stellt sich meiner Meinung nach der größte Erkenntnissgewinn/Lernziel für die meisten Teilnehmer ein. Ich behaupte mal, dass dieser Punkt genauso wichtig ist, wie das Coding selbst. (Zugegeben, ohne Code kann weniger Feedback/Review/Retrospektive in der Tiefe entstehen)

    Also vielen Dank für Deinen inspirierenden Beitrag mit dem verbundenen Wunsch euer Vorgehen, Ergebnisse und Feedback etwas detaillierter zu beschreiben und zu veröffentlichen. (Wo finde ich die Ergebnisse von letzten CodingDojo Empowered?) Auch das kann aus meiner Sicht dazu beitragen, Dokumentation vorausgesetzt, dass Spektrum der Erkenntnisse im allgemeinen zu verbreitern.

    Nun bin ich, wie Ralf auch, der Meinung, dass es CodingDojos in verschiedene Ausprägungen, Varianten, Schwerpunkten geben kann. Einem beispielsweise Kontrakt-First, oder Architektur CodingDojo könnte ich ebenso viel abgewinnen wie einem TDD, BDD, ATDD CodingDojo. Und es heißt auch nicht, dass ich TDD nicht machen kann, wenn ich Architektur oder Kontrakt-First gemacht habe. Es sind eben inhaltliche Schwerpunkte. Die 4 Grundregeln bleiben konstant.

    Besten Gruß, Mike

    PS: Mmhhh jetzt fällt mir auch noch was ein ;-) . Was ist mit einer 5 Grundregel? (Das wollte ich doch nicht!) Der ehrliche Wille, der kontinuierlichen Verbesserung.

  • Das ist ne...
    by Ralf Westphal
    on June 25th 2010

    Das ist ne klare Positionierung. Find ich gut.

    Für mich ergibt sich daraus, dass es eben mehrere Dojo-Schulen gibt: die Latifa-Schule und andere. So wie beim Karate Shotokan und Wado-ryu usw. nebeneinander existieren.

    Interessierte können sich dann diese Schulen anschauen und feststellen, welcher sie mehr zuneigen. Sie können auch mit der einen beginnen und dann weiterziehen.

    Sicherlich das Wichtigste ist, dass es in allen Schulen ums Coden geht und ein Geist der grundsätzlichen Freund(schaft)lichkeit und des Respekts und der Gleichberechtigung weht.

    -Ralf

(c) 2000-2012 ilker.de - Creative Computing.

For any case of inquiry regarding this document, you can always contact the website owner.