zu dem Thema des Blogposts, also “TDD: Die einfachste Lösung siegt”, habe ich schon Stellung bezogen. Ich will es nur nur ein wenig umformulieren. TDD lebt von der von Steffen erwähnten “Minimalplanung” – also das planen des Tests. Um genau zu sein ist das TDD, denn der Charakter von TDD ist schnelles Feedbacking und z.T. heftige Refaktorisierung. Ich kenne es so und ich praktiziere es so. Und ich bin damit ziemlich erfolgreich, wenn ich es mal so sagen darf.

Doch es gibt hier in den Kommentaren noch ein anderes Thema. Das Thema ist “Sinn und Zweeck und Ziel und Vorgehensweise” beim Coding Dojo. Hier prallen anscheinend Welten aufeinander.

Ralf, wenn Du das Coding Dojo in der erlebten Form nicht “gut” oder zielführend findest, dann steht es Dir frei, Dich davon fernzuhalten. Wenn Du aus den Coding Dojo’s nichts lernst, dann ist das schade und schön gleichermaßen. Schade, weil ein Coding Dojo ja zum Üben und Lernen gedacht ist. Schön, weil Du damit anscheinend schon alle Lernprozesse, die ich (und andere) im Dojo durchgehen, schon hinter Dich gelassen zu haben scheinst.

Ich repektiere Dein Know-How und Dein Engagement, und ich bin mir ziemlich sicher, dass Du Dir dessen auch bewußt bist. Doch ist es für mich auch unabstreitbar, dass ich Deinem Verhalten bei besagtem Dojo und den Statements hier im Blog nicht nur gutes Abgewinnen kann.

So bitte ich Dich, Dich bei der nächsten Teilnahme an (meiner bzw. unserer) Coding Dojo’s, Dich ehrlich und aktiv einzubringen, so daß alle Teilnehmer nicht nur von Deinem Know-How profitieren können, sondern auch die Beweggründe und Prinzipien verstehen lernen.

Und Ralf, Wenn Du einmal “nur” zuschauen möchtest ist das Ok. Zuzuschauen und danach das Gesehene zu kritisieren ist auch noch Ok. Aber diese Kritik in einer Art und Weise durchzuführen, die für mein Empfinden nicht wertschätzend, konstruktiv und respektvoll genug geschieht – das ist für mich nicht Ok.

Soviel zum “wie” Deines Beitrages. Jetzt noch zum “was”.

Anscheinend ist es mir (oder uns) nicht gelungen, Dir die Wert- und Zielvorstellungen des Coding Dojo’s, wie wir es machen und mögen, überzeugend darzulegen. Denn schließlich monierst Du immer wieder die “Ziellosigkeit”, Du betrachtest dabei “strukturierte und zielgerichtete” Ergebnisorientierung, Du stellst die Gruppenintelligenz in Frage, Du verlangst nach Denkern und Lenkern.

Ich will hier nicht in einem riesigen – so oder so schon deplatzierten – Kommentar auf meinen Standpunkt näher eingehen, sondern Dich am Ende meines Kommentars auf den Link zu meinem „Lernen & Lehren“-Artikel hinweisen.

Weiterhin möchte ich Dir noch folgendes zu Deinen Kritikpunkten sagen: Es mag sein, dass es für Dich Plauderei, Unterhaltung, oder naiver, mittelalterlicher, kindlicher Experimentierdrang ist. Ok. Für mich ist es eine wunderbare und wertvolle Möglichkeit, mich mit anderen auszutauschen. Es ist geradezu erfrischend und macht Spaß, anderen TDD näher zu bringen und auch neue Dinge zu lernen.

Es gab z.B. beim Münchener Coding Dojo locker 5-10 Teilnehmer, die in ihrem Leben noch nie TDD oder “Test-First” gemacht haben. Sie haben in diesen 2 Stunden Tests geschrieben, bevor sie programmiert haben. Sie haben über die Tests nachgedacht, bevor sie weitergemacht haben. Ein wunderbarer Erfolg, wie ich finde.

Also, Ralf, meine aufrichtige Bitte: Versuche uns und unsere Motivation zu verstehen – oder lass’ es bleiben. Trage ehrlich, aktiv und konstruktiv bei – oder lass’ es bleiben. Hab’ mit uns auch ein wenig Spaß und Freude – oder lass’ es bleiben. Komm mit in unsere Coding Dojo’s – oder lass’ es bleiben.

Ich habe im letzten Coding Dojo sehr viel gelernt und habe auch gesehen, wie andere gelernt haben. Ich bin weiter motiviert, mit anderen in lockerer Atmosphäre ein Code Kata per TDD zu lösen und Diskussionen zu führen. Ich lasse weiter Fehler zu und hole auch die “naiven” gerne mit ins Boot. Das alles mache ich, weil es mir Spaß macht, weil es mir viel bringt und weil ich sehe, dass andere es genauso empfinden. Ich hoffe, Du bist auch mal wieder dabei. Willkommen bist Du – und jeder andere – auf jeden Fall. Doch nur unter der Bedingung, dass man aufrichtig am Coding Dojo aktiv, respektvoll, optimistisch, zwanglos und gleichgestellt teilnehmen möchte.

Steffen, mein Kommentar ist denke ich deplatziert. Es tut mir leid, dass ich Das Abschweifen des Themas hier mit dem Kommentar weiterführe, aber ich denke, es ist gut, wenn man den Kontext meines Beitrages beibehält und gleichzeitig auf das „Abdriften des Themas“ mit einem Artikelverweis reagiert. Danke.

Damit zum Abschluß auch der Link zu meinem Artikel, der wesentlich mehr auf meine Vorstellungen, Ziele und Verfahren eines Coding Dojo eingeht: „Lerne & Lehre: Ilker’s .NET Coding Dojo“.

Die gefällt nun sicher “Plauderei” nicht. Ich wähle den Begriff aber bewusst. Denn auch wenn bei dir Tests zuerst geschrieben werden, sehe ich ansonsten keinen Rahmen. Du sagst nicht, dass TDD gelernt werden soll. Du sagst nicht, dass irgendwas anderes gelernt werden soll. Dir geht es nur darum, dass irgendwie die Aufgabe angegangen wird. (Fertigstellung kann dein Ziel auch nicht sein, denn wie die Dojo-Praxis zeigt, ist das ohne Systematik nicht möglich.)

“Wir gehen eine Aufgabe, die alle höchstens grob verstanden haben, einfach mal mit einem Test an.”

So würde ich deine Haltung zusammenfassen.

Die ist legitim. Kein Problem. Wer mag, kann es selbstverständlich gern so tun.

Wie gesagt: Dafür gehe ich nun aber nicht mehr zum Coding Dojo. Erwachsene Menschen können nämlich schneller lernen. Und TDD ist nicht die einzige Technik, um Software mit hoher innerer Qualität zu entwickeln.

Ich versuche aber nochmal eine Analogie, um zu zeigen, wo ich den Unterschied zw. deinem und meinem Ansatz sehe: Alle kennen Brainstorming, nehme ich mal an. Menschen kommen zusammen, um etwas Neues zu produzieren (einen Lösungsansatz für ein Problem oder eine Marketingidee usw.).

Lange hat man geglaubt, Brainstorming sei einfach so der Hit. Es reiche, dachte man, Menschen zusammen zu bringen und ihnen nur die Barrieren fürs Denken zu nehmen. “Lasst den Gedanken freien Lauf. Zensiert nichts. Raus damit!”

So kommt auch durchaus etwas heraus. Wer bisher in reglementierten Gruppen versucht hat, Neues zu produzieren, wird dann auch begeistert sein.

Doch die Forschung hat gezeigt, dass solches Brainstorming nicht die Effektivität erreicht, die erreichbar wäre.

Besser ist es nämlich zum Beispiel, wenn sich jeder Teilnehmer vorher (!) schon Gedanken macht. Dann kommt man zusammen und muss nicht unter dem de facto Druck eines Meetings Einfälle produzieren. Und dann kann man zu Einfällen schon Position beziehen.

Das bedeutet nicht, dass man vorher sich selbst zensieren soll. So wird vielmehr ein gewisser Filter eingebaut, der Rauschen ausblendet und so das Brainstorming-Meeting fokussiert.

Zurück zum Dojo: Ein Dojo wie jetzt grad in Muc ähnelt für mich dem naiven Brainstorming. Es wird gehofft, dass eine Gruppe, die einfach so zusammenkommt einfach so auch produktiv ist. Die Praxis zeigt, dass das nicht stimmt. So einfach ist es nicht. Allemal nicht mit Leuten, die keine Dojo-Erfahrung haben.

Deshalb (und aus anderen Gründen) bin ich der Meinung, dass sich eine solche Dojo-Gruppe dümmer stellt, als sie sein müsste. Nachdenken würde helfen.

Noch ein Wort zur TDD-Praxis: Natürlich zeigt ein API seine Wert erst, wenn man ihn im Code benutzt. Aber ich bin an einem Flipchart viel schneller beim Spielen mit API-Alternativen als in Testcode. Deshalb halte ich es für ein großes Missverständnis, Testcode einzuklimpern, ohne vorher drüber nachzudenken.

Code in der IDE will nicht mehr verändert werden. Er ist sehr starr. Das hat auch das letzte Dojo gezeigt. Ohwei, wie hat sich die Gruppe schwer getan, einen Test von 6 Zeilen einfach zu löschen. Da hat man lieber minutenlang rumdiskutiert, um ein Argument zu finden, ihn zu behalten.

Bottom line: Ich bleibe dabei: Nachdenken hilft. Vor dem Codieren.

-Ralf

ich möchte nur noch einen Aspekt erwähnen oder etwas umformulieren: jedes Dojo lebt aus dem gemeinsamen Streben der Gruppe danach, ein Problem zu lösen. Das passiert nach den zusammen festgelegten Regeln, die die Gruppe demokratisch also nicht zwangsläufig einstimmig festlegt. Das schöne dabei war bisher immer, dass das jedem klar war und jeder akzeptiert hat.

Also gibt es für mich nur eine einzige Voraussetzung, um ein tolles Dojo hinzukriegen: jeder muss sich als Teil der Gruppe fühlen und mitmachen wollen.

Schöne Grüße,
Christina

ich weiß echt nicht worauf du hinaus willst.

“Minimalplanung” ist doch beim TDD gerade gefragt, aber eben keine globale.

Roy Osherove schreibt zur berühmten “String Calculator” Kata:
“Try not to read ahead. do one task at a time. the trick is to learn to work incrementally.”

Man simuliert hier auch den typischen Fall, dass die Anforderungen am Anfang eben nicht klar sind sondern erst stückweise hinzu kommen.

Die Klärung des API’s kommt doch auch durch den Test. Ich schreibe einen Test und schaue mir an, ob mir das Interface als Benutzer des API gefallen würde. Wenn ja dann drücke ich ein paar mal auf Alt+Enter und lasse den Resharper so alle noch nicht vorhandenen Klassen und Methoden erzeugen und habe meinen ersten roten Test.

Es ist doch so auch viel leichter mit so vielen Leuten im Raum über das gewünschte Interface zu reden. Alle schauen sich den noch nicht kompilieren Code an und können meckern und verbessern. Jeder spricht über das selbe und benutzt wie Ilker so schön sagt die selbe Sprache – den Code.

Grüße Steffen

Aber wenn ich dann lese…

“TDD und BDD leben von Empirie, die eine durchdachte experimentelle Aufstellung erfordert.”

und an das Coding Dojo beim Powerday gestern abend denke… dann frage ich mich, wo die “durchdachte Aufstellung” war. Denn durchdacht ist doch – sorry to say – eben kaum etwas worden. Da liegt meine Kritik.

Man mag mich als Theoretiker bezeichnen, aber ich bleibe dabei: gestern abend hätten 10 Minuten Nachdenken den Misserfolg verhindern können. Die Gruppe als Ganzes (als Kollektiv, als soziales System) war dümmer als jeder Einzelne. Denn aus den Kommentaren Einzelner war abzulesen, dass sie das Problem viel strukturierter durchdacht hatten, als der Code es zeigte.

Experiment (Forschung) ohne Nachdenken, ist nicht besser als Nachdenken ohne Experiment. Mir hat also die schlichte Balance gefehlt.

Balance muss es geben zwischen Anforderungen verstehen und Lösungen erarbeiten. Die Balance war gestern durchaus vorhanden.

Balance muss es aber auch geben zwischen Entwerfen und Implementieren. Die hat gefehlt. Nach der Anforderungsanalyse stand keine Klärung des simplen API (der Signatur des späteren SUT). Nach der Anforderungsanalyse stand keine Erklärung, was für die präferierte Vorgehensweise (TDD) nötig ist. (Das VS Projekt war schon quasi fertig.)

Und nach der Anforderungsanalyse standen nicht mal 5 Minuten Nachdenken darüber, wie eine Lösung überhaupt aussehen könnte. So ganz grob. So ungefähr. So ganz grundsätzlich.

Null. Nichts. Nada. Kein Nachdenken. Kein Innehalten.

Und das – mit Verlaub – hat nichts mehr mit Forschung/Experiment zu tun. Und ich kann darin auch keinen Vorteil für ein Entwickeln in der Gruppe sehen. Das ist schlicht Dummheit. Kollektive Dummheit. Das Kollektiv hat seinen Vorteil, aus vielen Intelligenten zu bestehen, nicht genutzt.

Wenn es dann zu Erlebnissen gruppendynamischer Natur kommt, ist das ja nett. Wir haben auch Spaß gehabt. Schön. Aber dafür kann ich zum Fußball gehen oder auch zu einem philosophischen Salon. Wir haben jedoch ein Coding Dojo durchführen wollen. Da denke ich, dass die Erfahrungen im Zusammenhang mit Softwareentwicklung stehen sollten.

Für mich die Bottom Line: Ein Coding Dojo ohne Innehalten und Minimalplanung der Lösung kommt für mich nicht mehr in Frage. Sonst ist die Balance (s.o.) nicht eingehalten.

-Ralf

Ich möchte garnicht zu sehr auf meine Eindrücke gehen sondern eher auf die Aussage “CodingDojo TDD : Die einfachste Lösung siegt!”.

Es gibt eine klare Antwort darauf: JA! Und auch auf die Gefahr hin, hier komisch angestarrt zu werden: JAAAAA!

Die einfachste Lösung siegt beim TDD!

Und vor allem bei einem CodingDojo! Wie Du schon richtig angemerkt hast, haben optimierte Algorithmen Ihre eigene “Schönheit”, nämlich die, dass Sie nicht nur durchdacht sind, sondern auch auf einem logischen Fundament – der Mathematik – aufgebaut sind.

Jedoch ist es nun einmal so, dass wir nicht alle bei der NASA die Raketensteuerung weiterentwickeln oder bei der EADS verteilte, autonome Droiden anprogrammieren. Der Großteil von uns beschäftigt sich im Vergleich dazu mit einfacheren Problemen, meistens im Sinne der Strukturierung & Verarbeitung. Also Komposition, Aggregation, Nachrichtensteuerung und ähnliches.

Dafür und für viele andere – sogar komplexere – Problemstellungen ist es das einzig richtige und effiziente Mittel, die Lösung durch empirische Herangehensweise (also test- bzw. spezifikationsgetrieben) zu erarbeiten. Ich denke, dass viele von uns noch lernen müssen, dass TDD keine Wissenschaft darstellt, sondern nur ein Mittel, ein Werkzeug in unserem “Wissenschaftskasten” ist.

Ich finde auch den Kommentar von Stefan gut, das man die Lösung, die man “bis dato” erarbeitet hat so lange durchprogrammiert, bis man es eben merkt, dass man “gegen die Wand läuft”. Viele Theoretiker verabscheuen diesen Gedanken und argumentieren, dass man “durch einfaches nachdenken” solche Situationen vermeiden kann und schneller zum Ergebnis kommt. Sie vergleichen das mit “Try-And-Error” und belächeln die “einfach sinnlos Code-Rein-Hacker”.

Was diese Fraktion völlig außer acht lässt ist die einfache Tatsache, dass es eben kein “Try-And-Error” ist und eben kein “sinnloses Code schreiben”. TDD und BDD leben von Empirie, die eine durchdachte experimentelle Aufstellung erfordert. Es zwingt den Entwickler mehr als jede systemanalytische Diskussion, sich mit der Funktionalität nachhaltig gedanklich auseinanderzusetzen.

Ein Unit-Test ist wie ein kleiner Mikrokosmos des wissenschaftlichen Experimentierens: Es fordert vom Forscher (Coder), genau nachzudenken und zu erarbeiten, wie das Experiment (Test) durchgeführt werden muss, um die geünschten Erkenntnisse (Funktionalität) daraus zu gewinnen.

Manche mögen dann kritisieren, dass dabei das “Big Picture” vernachlässigt wird und es “keine gemeinsame Richtung” oder keinen “Masterplan” gibt. Hierbei muss man das Mittel TDD in den richtigen Kontext stellen. Es macht sicher keinen Sinn, größere Organisationsstrukturen (Patterns & Architekturen), Schnittstellen (Ressourcen, I/O, DB, UI) oder Datenverarbietungsprobleme nur mit TDD anzugehen. Wunderbare Beispiele dafür sind Parallelverarbeitung, oder autonome Systeme. Das selbe gilt für den Optimierungskontext, hier nenne “nur” das Beispiel der Sortierung.

Das heisst aber noch lange nicht, dass man in einem “kleinen” Rahmen wie der “Funktionseinheit” (vgl. “Unit Test”) zu dem probaten Mittel TDD greifen sollte. Nach Ochkams Rasiermesser ist es offensichtlich auch eine sehr treffende und zielführende Methodik, gestalterische Faktoren nicht nur durch die Umweltschnittstelle zu steuern, sondern die Rückkopplung äußerer Einflüsse auch durch “innere Kräfte” zu verarbeiten.

Das alles hört sich für den einen oder anderen vielleicht abgehoben an – ist es aber nicht. Ich beschäftige mich mit diesem Themen schon länger etwas intensiver und kann nur sagen: TDD/BDD hat einen wunderbaren, erfolgreichen, effektiven und oft sogar effizienten Sinn, wenn man sich darauf einlässt, die Dinge so einfach wie möglich zu sehen und sie genauso einfach anzuwenden. TDD ist kein Allheilmittel und ersetzt keine Systemanalyse, Requirements Engineering, Anwendungsarchitekturen oder Design Patterns. Aber es hilft, auf einem niedrigen Abstraktionsniveau (am Code), bindende Lösungen im gefassten Kontext effektiv und nachvollziehbar zu erarbeiten.

Zurück zum CodingDojo-Kontext. Im CodingDojo werden keine großen Architekturen gebaut. Im CodingDojo schreibt man keine Web-Anwendung mit jQuery-UI und einer relevanzbasierten Suchengine. Im CodingDojo gibt es kleine, überschaubare Aufrgaben mit “leichter” Funktionalität und einfachen Rahmenbedingungen.

Bei solchen Dingen mit großen analytischen Sprüchen zu arbeiten ist schlichtweg mit Kanonen auf Spatzen schießen. Manch einem sollte klar gemacht werden, dass diese “Ich denke auf Papier, also bin ich Architekt”-Einstellung gerade bei so konkreten Problemstellungen mehr ein Indiz für “schwache” Designfähigkeit ist als ein Beleg für “gute” Ingenieurskunst. Schliesslich kann uns soll man ja auch mit Code designen. Das ist ja eines der zentralen Botschaften des TDD/BDD.

Für das CodingDojo heisst das: Die einfachste Lösung siegt im TDD! Und etwas provokativ formuliert: Stop Talking, Start Coding!

ich merke in den Kommentaren nun genau die Entwicklung, die uns in Muenchen die letzten Monate auch aufgefallen ist. Gerade mit einem immer wieder aehnlich aufgebautem Team konnte man sehr gut sehen wie sich von Mal zu Mal eine gemeinsame Sprache, ein gemeinsames Vorgehen entwickelt hat. Das schaerft die Sinne fuer aehnliche Faelle im realen Programmiererleben.

Ich bin genau so lange beim Implementieren der einfachsten Loesung, bis man gegen die Wand laeuft, bis das Team damit gegen die Wand laeuft und dann sieht, dass Ueberlegungen notwendig sind. Dann sehen wir dies jedoch alle im Team und nicht nur ein Einzelner, der mehr Informationen hat.

Das Kommunizieren der Mehrinformationen die ein einzelner Entwickler bereits in der Fruehphase des Prozesses hat ist viel schwieriger, langwieriger und fehlerhafter als wenn das Team schnell implementiert und dann gemeinsam das Problem schwarz auf weiss sieht.

Ilker hat dies fuer mich treffend formuliert und wurde mir dort erst bewusst. Er sagte “Der Code ist unsere Sprache”. Wir diskutieren oft ewig ueber ein Problem und keiner versteht wo das Problem genau liegt. Warum nicht auf dem einfachen Weg umsetzen und dann das Problem als Bild vor sich zu sehen.

Mir ist bewusst, dieser Ansatz gilt nicht fuer komplexe Systeme und beim Zusammenspiel von verschiedenen Systemen muss weiterhin gelten, erst denken, dann handeln. Gerade bei einem Dojo will ich jedoch lernen, wie weit kann ich mit TDD gehen, ich muss es austesten, ich muss es erlernen und es muss in Fleisch und Blut uebergeben den einfachen Weg zu gehen. Nur dann kann ich entscheiden wann ich dieses Vorgehen, diese Technik einsetzen kann, will und werde. Und wenn nach all den Dojos lerne es nur ganz selten einzusetzen, dann weiss ich immerhin mehr als vorher.

Viel Text und schnell dahingeschrieben. Ich will anmerken, das sind Gedanken die mir jetzt durch den Kopf gingen und NICHT recherchierte, bis in’s Ende durchdachte Sinnhaftigkeiten. Also mit Bedacht geniessen, bei Fragen nachbohren und als Diskussionsstoff sehen!

Gruss
Stefan

ich glaube, dass ein Dojo neben dem rein fachlichen Zweck, also dem Lösen einer Programmieraufgabe unter Anwendung und Berücksichtigung bestimmter Paradigmen (wie z.B. TDD) auch noch einen weiteren Zweck erfüllt: “Erlernen des Umgangs mit gruppendynamischen Effekten in Entwicklerteams”.

Im Gegensatz zu Dir, Steffen, bin ich aber nicht der Meinung, dass es einen sinnvollen “Mittelweg” nicht geben kann. Ich glaube vielmehr, dass es diesen geben muss und es eben darauf ankommt, an der richtigen Stelle vom “Coder” zum “Knobler” zu werden und umgekehrt.

In der Tat lag an dieser Stelle meiner Wahrnehmung nach in Karlsruhe auch der Knackpunkt. Denn man wollte zwar den einfachsten Vorschlag nehmen, der zu einem grünen Test geführt hätte, aber eben der von Dir geforderte “Fokus auf die minimal mögliche Generalsierung der aktuellen Implementierung” hat dabei meiner Meinung nach gefehlt. Diesen Fokus zu erlernen kann ein weiteres Ziel des Dojos sein.

Ich bin auf jeden Fall immer wieder fasziniert, welchen Verlauf ein Dojo nehmen kann und welch unterschiedliche Methoden und Effekte zu beobachten sind.

Viele Grüße
Kostja

dass die Lösungen mit beiden Ansätzen gleich gut werden glaube ich auch nicht. Allerdings kann auch TDD fehl schlagen, bei manchen (mathematischen) Problemen kommt man einfach ohne globale Betrachtung des Problems (also ohne Knobelei) nicht auf die richtige Laufzeit-Komplexität. Man bekommt dann mitunter zu einen Algorithmus der korrekt aber exponentiell zu langsam ist. Dann kann man sich streiten, ob das nun erfolgreich war. Ich würde dann sagen: “Jetzt haben wir wenigstens schon mal eine Testsuite und können anfangen zu knobeln.”

Zu der Frage nach dem Ziel des Dojos. Natürlich möchte ich dabei etwas lernen. Aber nicht unbedingt etwas Konkretes. Ich habe bei dem Dojo sehr viel gelernt und das ist so auch genau richtig. Ich habe z.B. gelernt, dass man sich besser abstimmen muss und sonst selbst in einer sicheren Dojo-Umgebung ganz schnell die Ellenbogen ausgefahren werden. Das ist eine extrem wertvolle Erfahrung für mich und vor allem eine die ich allein in meinem Kämmerchen nicht machen kann. TDD hingegen oder fachliche Topics kann ich mir immer auch selbst beibringen – Blogs, Webcasts, usw. gibt es reichlich.

Grüße Steffen