See#

Das von der .NET Usergroup Konstanz-Kreuzlingen organisierte Event hatte eine eine sehr ansprechende Agenda und hochkarätige Speaker zu bieten. Meine Sessionliste:

• Windows Phone 7 Applications mit Silverlight, Laurent Bugnion
• IronRuby für .NET Developer, Thorsten Hans
• ADO.NET Entity Framework in N-Tier Applikationen integrieren, Robert Meyer
• Code-Generierung mit dem Text Template Transformation Toolkit (T4), René Leupold

Besonders schade fand ich, dass ich in Ermangelung meiner Parallelisierungsfähigkeiten bei folgenden Sessions nicht dabei sein konnte, denn sie hätten mich brennend interessiert:

• Powershell für Entwickler, Thomas Krause
• UI/UX – Grundlagen für Entwickler, Roland Weigelt
• Framework Design Guidelines – Wiederverwendbare Frameworks in C#, Rainer Stropek

SL4@WP7

Naja, nicht so schlimm, denn ich wurde von meiner Sessionwahl keineswegs enttäuscht. Den Anfang machte Laurent mit Windows Phone 7 Entwicklung. Angenehm: er spricht deutsch! Er gab einen guten Überblick über die Funktionen des neuen WP7 und die Programmiermöglichkeiten, darunter Silverlight. Highlight hierbei ist sicherlich, dass Laurent live in der Session gegen ein echtes Device die Programmierbeispiele ausgeführt hat und mit der Webcam dem Publikum gezeigt hat. Nice!

IR

Danach ging es schon weiter. Thorsten Hans zeigte in seiner IronRuby-Session wirklich beeindruckend, dass das .NET Framework mit der CLR und DLR eine revolutionäre Programmierplattform ist. Er ging zunächst auf die DLR und deren Komponenten ein und steigerte während seiner Session stetig den Geekfaktor. Zunächst zeigte er, wie man mit IronRuby umgeht – das Handwerkszeug sozusagen. Danach wurde es schon cooler: .NET-Assemblies und IronRuby im Zusammenspiel: IronRuby-Skripte (mit Scope & Context) aus .NET-Anwendungen aufrufen und vice versa. Als Beispiel zeigte Thorsten eine in Ruby geschriebene Validierung einer Kunden-Registrierung eines .NET-Programms. Ich war beeindruckt! Doch Thorsten ließ nicht locker und haute zum Schluß noch einen richtigen Knaller raus: Unit Testing einer .NET-Komponente mit IronRuby & RSpec!

Gut, dass danach die Mittagspause anstand, dass musste ich erst mal verarbeiten :) In der Pause hatte ich dank Basti auch die Gelegenheit, den von Thomas getesteten Sony Vaio VPCS12V9E/B selbst einmal “anzutesten”. Ich muss sagen, dass Thomas die Messlatte ganz schön hoch legt, denn für meinen Geschmack ist die Verarbeitung des Sony wirklich gut. Das Gehäuse ist kein Shiny-Alu-Guß, aber auch kein Plastik. Die Chiclet-Tastatur ist ok, der Druck relativ sensibel. Performance gut, Display in Ordnung.

EF4

Nach der Mittagspause ging es zu Robert’s Entity Framework Session. Er ging zunächst auf die “Schwierigkeiten” der ersten Version des Entity Frameworks ein, um danach gleich mit den Neuerungen von EF4 nachzulegen. An seinem Vortrag besonders gefallen haben mir die vielen kleinen Beispiele aus der Praxis, mit denen Robert seine Expertise in diesem Bereich einmal mehr zu unterstreichen wusste. In der zweiten Hälfte der Session widmete er sich den neuen Features wie (echten) POCO-Support, Domain-First-Design und natürlich dem IObjectSet<T>. Robert ging auch auf Testbarkeitskriterien von EF4-Lösungen ein und nennte einige Leitfäden zum Testing. Fazit: eine guter EF4 Überblick mit wertwollen Praxisbeispielen vom Experten.

T4

Die letzte Session hatte es in sich: T4. René zeigte zunächst die Grundlagen. Was ist T4, Wieso T4. Aufbau, Architektur, Anwendung. So einfach kann eine Einführung sein. Doch dann ließ es sich auch Rene nicht nehmen, in die Tasten zu greifen. Exemplarisch an Anwendungsbeispielen wie z.B. EF-Templates oder Templates für Unit Testing ging er auf die Features der T4-Engine ein. Bemerkenswert: René lässt sich auch durch kleinere technische Probleme nicht aus dem Konzept bringen. Er hatte wirklich eine Fülle von Beispielen parat, mit denen er reichhaltigen Funktionalitäten von T4 erläuterte. Ein Text- und Code-Jongleur, kann ich da nur sagen.

Trotz dieser guten Sessions war mein Eindruck von See# nicht ganz perfekt – doch daran war ich selbst schuld. Durch die lange Anreise habe ich die Keynote von Golo verpasst. Die lange Reisezeit war schlußendlich auch der ausschlaggebende Faktor, warum ich leider nicht mehr bei der Grillparty und dem .NET Coding Dojo mit Stefan dabei sein konnte. Sehr schade. Nichtsdestotrotz konnte ich wieder auf dem Event wirklich tolle neue Entwickler-Kollegen kennenlernen, darunter Peter Bucher, Roberto Bez, Jürgen Gutsch und Thorsten Hans. Für mich hat sich dadurch die Teilnahme an See# doppelt gelohnt.

Let’s go to NRWConf!

Kaum ist die eine Community Conference zu Ende, steht die nächste schon vor der Tür – die NRWConf 2010 am 9./10. September steht an. Wenn man sich die Agenda der NRWConf ansieht, dann klingt das überaus vielversprechend. Also ich werde mir definitiv wieder eine Menge Sessions so zu Gemüte führen und vieles dazu lernen. Am Abend gibt es – wie auch bei der See# – ein .NET Coding Dojo. Diesmal jedoch mit meiner Wenigkeit als Operator. Ich denke es wird nicht nur eine Menge Spaß machen, sondern wieder einmal erkenntnisreich sein ;-)

Ich freue mich!

Nun, dem muss ich deutlich widersprechen. Genau das Gegenteil ist der Fall – und sowohl sein Artikel als auch die Kommentare dazu sind in meinen Augen eine Bestätigung: Räumliche Nähe wird einfach noch viel zu oft unterschätzt!

Professional Engineering

Ich möchte das Beispiel von Golo aufgreifen, in dem er die gute Zusammenarbeit zwischen ihm und Peter schildert:

“… Peter Bucher und ich sind ein solches Team. David Tielke und ich sind ein solches Team. Beide habe ich in meinem Leben noch nicht all zu oft getroffen – jeden von beiden höchstens fünf Mal. Und dennoch harmoniert die Zusammenarbeit in einem Ausmaß, das für Außenstehende nicht nachvollziehbar ist.

Auch wenn uns hunderte von Kilometern trennen, führen wir regelmäßig Programmieren in Paaren durch – per Skype und Teamviewer. Und die Zusammenarbeit funktioniert einwandfrei. Keiner von uns käme auf die Idee, zu sagen, dass wir effektiver oder effizienter sein könnten, wenn wir gemeinsam vor einem PC arbeiten würden.

Vermutlich wären wir dies noch nicht einmal, weil dann nicht jeder seine vertraute Arbeitsumgebung hätte, in der er sich rundum wohlfühlt…. “

Das Beispiel ist ein Zeugnis von professioneller Software-Entwicklung. Da arbeiten offensichtlich zwei Profis zusammen. Sehr gut. Golo leitet daraus ab, dass es nicht zwingend notwendig sei, Teammitglieder an einem Ort, in einem Gebäude, in einem Raum zu haben, um effektiv ein “Team” zu sein. Nun, das mag ja schön und gut sein. Aber Golo: Hast Du denn Vergleiche? Und wenn ja, hast Du gemessen, wie “effektiv” denn beides ist? Ich befürchte nein. Wäre dem so, dann wäre mit großer Wahrscheinlichkeit Dein Fazit anders ausgefallen.

Was ich damit zum Ausdruck bringen will, ist, daß Golo und Peter wohl nie in einem Raum über längere Zeit zusammen gearbeitet haben. Ich unterstelle das jetzt einfach einmal Golo & Peter; bitte korrigiert mich und verzeiht mir, wenn dem nicht so ist. Es dient mir zur Illustration meiner Perspektive zum Thema.

Also, wäre dem so, so hätte Golo gar keinen Vergleich der Effektivität & Effizienz des Teamgefüges zwischen ihm und Peter. Beide sind ausgewiesene Profis in der Software-Entwicklung und schaffen aus der Distanz gemeinsam gute und effiziente Teamarbeit. Der Artikel von Golo beweist es. Man stelle sich nur vor, welche Produktivität und Ingenieursleistung möglich wäre, wenn zwei solche Profis an einem Tisch arbeiten würden. Wow.

Damit sind wir auch schon an einem wichtigen Punkt. Agile Software-Entwicklung und deren Verfahrensweisen behaupten nicht, dass es notwendig sei, ein Team an einem Fleck zu haben, um (gut) Software zu entwickeln. Aber sie behaupten, dass sich spätestens mittelfristig die Produktivität & Effizienz eines Teams steigert, wenn sie an einem Fleck miteinander zusammenarbeiten. Diese Behauptung ist kein Wunschtraum, sondern messbar & belegbar.

Doch es gibt noch einen weiteren, ganz entscheidenden Aspekt der Forderung nach Teamnähe in der Agilität. Golo überspringt in seiner Betrachtung meines Erachtens die Interdisziplinarität agiler Teams. Das ist für mich besonders verwunderlich, zumal er in seinem gelungenen Artikel über die Feature-Orientierung in agilen Methoden sich selbst genug Indizien gibt, die interdisziplinäre Aufstellung von Teams zu fordern & zu fördern.

Agile Teams sind Interdisziplinär

Was heisst das? Das heisst, erst einmal, das Entwickler alleine kein Team sind. Zumindest mal in der agilen Software-Entwicklung nicht. Ein agiles Team ist ein Team, welches eigenständig dazu in der Lage ist, das geforderte Produkt bzw. deren Features ausliefern zu können. Manchmal – besser gesagt: eher selten – reichen dazu Entwickler. Doch meist braucht es mehr, viel mehr. Es braucht Produktmanager, Systemingenieure, Usability-Experten, Designer, Tester und manchmal sogar noch mehr, um ein Feature eines Produktes wirklich fertigstellen zu können.

Ein agiles Team ist ein Team, welches all diese Rollen und Aufgabenbereiche berücksichtigt und mit den Teammitgliedern umsetzen kann. Dass heisst nicht unbedingt, dass Designer ein “fester Bestandteil” des Teams sein muss, wenn er nur zwei Websites designen soll, das Produkt aber weitaus mehr darstellt (z.B. im Backend oder durch Dienste). Doch wichtig ist hier die Erkenntnis, dass ein agiles Team interdisziplinär ist; idealerweise sogar mit dem Kunden (oder Kundenvertreter) an seiner Seite.

Vor diesem Hintergrund macht die Forderung nach räumlicher Nähe von Teammitgliedern in einem Team noch viel mehr Sinn. Leider gibt es noch viel zu oft die Situation, dass Entwickler von der Marketing-Abteilung die Anforderungen über ein Feature (<Ironie>als “Story” natürlich, haha</Ironie>) in einem “agilen” Ticketsystem vorgesetzt bekommen. Die Entwickler “sprinten” dann und liefern das Ergebnis an die Testabteilung, um danach ein Paket der Infraktruktur bzw. Installation-Engineers “über den Zaun” zu werfen. In meinen Augen haben es solche Teams echt schwer, denn sie sind nicht agil, sondern fragil.

Keine Scheu vor Transparenz

Die Emergenz, die durch interdisziplinare Teams entsteht, ist nämlich erst dann wirklich mess- und spürbar, wenn die Kommunikationsmittel als auch die Kommunikationsbarrieren untereinander so gering wie möglich ist. Doch nicht nur gute Kommunikation ist ein Ziel der Co-location. Ein aus meiner Sicht wesentlich wichtigerer Faktor ist der Faktor der Transparenz.

Durch die Nähe zueinander sieht man auch, was der andere so macht. Soll heissen, man lernt seinen Tagesablauf, seine Aufgaben, seine Tools, seine Herausforderungen – na eben das ganze Arbeitsumfeld. Umgekehrt sehen andere, mit welchen Dingen man selbst tagtäglich konfrontiert ist und was es tatsächlich bedeutet, Software zu entwickeln. Durch die Transparenz entsteht mehr Verständnis zu der Aufgabe und der Leistung des anderen Teammitglieds. Man versucht sich gegenseitig zu helfen und aufzubauen. Das wiederum hilft der Kommunikation und der Produktivität im Team.

Abschließend kann ich nur sagen, dass ich nicht nur ein Befürworter von räumlicher Nähe bin, sondern als Agilist versuche, so nah wie möglich an meinen Teammitgliedern und dem Kunden dran zu sein. Manchmal macht man es sich meiner Meinung nach zu einfach, wenn man Distanzen unter gemeinsam arbeitenden Kollegen als gegeben hinnimmt.

Be Agile!

Ich möchte in diesem Zusammenhang gerne nochmal an zwei Punkte des agilen Manifests erinnern: People over Process (and Tools), sowie Collaboration over Contracting. Für mich steht fest: wer von sich behaupten möchte, agile Software-Entwicklung zu betreiben, der wird früher oder später die Vorteile von räumlicher Nähe von Teams erkennen und versuchen, diese Nähe von Teams so gut wie möglich herzustellen. Alles andere sind in meinen Augen nur Lippenbekenntnisse und Halbwahrheiten über Agilität.

Wohl nicht zuletzt durch diese “Stärkung” zu Beginn war die Teilnehmerschaft bei diesem Dojo besonders motiviert. Nach der obligatorischen Begrüßung ging es auch schon an die Wahl des Modus und des Kata’s. Wir haben uns nach Abstimmung für den Prepari-Modus entschieden und uns wieder einmal an das sagenumwobene Kata BankOCR ausgesucht. Auf Grund der Teilnehmerzahl haben wir auch die Gruppe in zwei Teams und separate Räumlichkeiten aufgeteilt.

Dabei gab es diesmal einige Besonderheiten. Bei Avanade haben die Meetingräume Namen von berühmten Münchener Persönlichkeiten – so kam es auch, dass wir den Teams auch diese Namen gaben. Darüber hinaus haben beide Teams eigene “Operator” und “Coder” gehabt. Für das Team “Von Klenze” war der Operator diesmal Christian; die Macht über die Tasten hatte Tom. Das Team “Von Miller” wurde durch den Operator Andreas unterstützt, während Dimi über die Kontrolle über den Rechner hatte.

Nach der Teamaufteilung ging es schon los. 45 Minuten lang wurde kräftig designed, diskutiert und programmiert. Bei beiden Teams war das TDD schon in Fleisch und Blut übergegangen, denn schließlich hatten beide zur 5 minütigen Pause schon Tests und Code aufzuweisen. Zuversichtlich ging es dann auch schon in die zweiten 45 Minuten. Mein persönlicher Eindruck war, dass gerade diese zweite Runde viele Aha-Effekte auslöste damit den Erfahrungsaustausch besonders förderte.

Den Abschluß des Dojo’s machte eine (diesmal etwas längere) Retrospektive. Die Teilnehmer gaben Feedback zum Code, zur Teamleistung und zur eigenen Perspektive. Wiederum bemerkenswert war die allgemeine Zufriedenheit über den Ablauf des Dojo und die geleisteten Resultate. Nach ein paar Schlußworten meinerseits ging es dann noch (mit nahezu gleicher Teilnehmerzahl) in ein Bistro in der Nähe auf eine ausgedehntere Nachbesprechung eines der besten .NET Coding Dojo’s, die ich jemals erlebt habe. Vielen Dank an alle Teilnehmer und an Avanade!

So oder ähnlich erging es auch dem ein oder anderen beim jüngsten Estimation Meeting, welches wir in einem Projekt durchgeführt haben. Für einige war es das erste Schätzmeeting, bei dem nicht einfach so Manntage herausposaunt wurden, sondern das von agilen Methoden wie XP oder Scrum bekannte schätzen in Relationsgrößen (z.B. Story Points) umgesetzt wurde.

Für den Anfänger ist der Zeitbezug im Schätzungsverfahren meist so manifestiert, dass er sich schwer tut, überhaupt anders denken und schätzen zu können. Die erste, wichtige Hürde hin zum relativen schätzen ist eine klare Vorstellung davon, was nun der Unterschied zwischen größenorientiertem Umfang und zeitorientiertem Aufwand ist. Um den Teilnehmern und Neulingen im agilen Schätzzirkus den Einstieg zu erleichtern, habe ich mich einer kleinen Metapher bedient:

Da ist er, der „Ratatouille Estimation Scale“. Klassisch, einfach. Fibonacci und am Ende Hightower-Zahlen. Das war’s. Doch es ist mehr dahinter als nur die blanken Zahlen. Es ist die Metapher, die Schätzen besonders geholfen hat.

Denn der Film „Ratatouille“ und die Liebe zu Gaumenschmaus ist ein schönes Beispiel, an dem sich größenorientiertes Schätzen erklären lässt. Bei der Menge der Köstlichkeiten geht es nämlich nicht darum, wie „schnell“ man diese Leckereien herunterwürgen kann. Es geht auch nicht darum, einfach wahllos seinen Hunger zu befriedigen. Nein, es geht darum, den Umfang und Wert der Köstlichkeiten zu erfassen ;-)

Nur ein Häppchen? Wohl eher eine 1 oder 2. Ein echtes Stück Käse? Eher die 5. Viel Käse und Trauben dazu? Lecker. An die 20. Kistenweise Käse, Gemüse, Obst und Wein? Wow. 50 oder mehr!

Die Besonderheit dabei: Es wird schnell deutlich, dass es nicht um die Zeit geht. Schließlich kann man ein Stück Käse sicherlich in ein paar Stunden „abfrühstücken“ – oder aber scheibchenweise über eine Woche lang genießen. Mit steigendem Umfang wird es allerdings schwerer. Denn jetzt kommen andere Lebensmittel hinzu, die vielleicht andere Haltbarkeitsmerkmale aufweisen oder aber besondere Behandlung bzw. Lagerung benötigen. Das ist ein relativ schönes Bild für den Begriff der “Komplexität im Umfang“.

Den Neulingen im Estimation Meeting hat diese Metapher sehr geholfen, denn schon nach den ersten paar Schätzrunden war die “Zeit” in der Besprechung der Features „wie verschwunden“ :-)

Und genau so ist es auch. Zumindest für mich. Ich habe lange Zeit Tests und Implementierung in separaten Projekten entwickelt. Bis ich bemerkt habe, dass es mir nicht hilft, sondern mich eher bei meiner Entwicklung stört. Seitdem halte ich Tests und Implementierung immer ganz nah beieinander, sozusagen „Seite an Seite“. Ich möchte in diesem Post meine Beweggründe & Konsequenzen für Side-by-Side-Specs (oder Near-Specs, wie ich es gerne nenne) schildern, und somit meine Antwort auf Stefan’s Frage geben.

Nun zunächst einmal beschränke ich mit bei den Near-Specs auf Unit Tests. Ganz klassisch im Sinne des TDD. Integrationstests sind bei mir nach wie vor Far-Specs, also separate Projekte. Doch es soll ja um die Unit Tests gehen, besser gesagt um Tests, die aus dem Test-First-Ansatz heraus entstehen. Das können Tests bei TDD oder aber auch Specs bei BDD sein. Ergo: Tests, mit denen ich meinen Code designe & entwickle, halte ich sehr nah am Code.

Verhalten greifbar formen

Doch wieso sind bei mir die Tests nun an der Implementierung dran? Es gibt einen ganz einfachen und für mich auch unschlagbar effektiven Grund: Die Tests sind greifbar. Sie sind dort, wo ich sie brauche, nämlich an dem Verhalten, für das ich sie zur Spezifikation gebraucht habe. Seit dem ich die Tests an der Implementierung habe, „forme“ ich auch mehr und öfter. Soll heissen: Ich führe öfter und effizienter Refactorings durch. Nicht nur vom SUT, sondern natürlich auch von den Tests selbst.

Überhaupt ist es mit den Tests im Implementierungsprojekt ein ganz anderes, viel effizienteres arbeiten. Wenn ich nach einiger Zeit wieder einmal in einem Projekt etwas zu tun habe, schaue ich mir die Tests an. Das Schöne bei den Near-Specs ist jetzt, dass ich sehr schnell zwischen Spezifikations- und Implementierungssicht wechsle und deutlich zügiger navigieren kann. Das fällt mir besonders bei Tests mit mehreren Abhängigkeiten / Mocks auf. Ich komme mit dieser Art von „Code lesen“ viel besser zurecht als vorher mit dem hin- und herspringen zwischen mehreren Projekten.

Zugegeben, anfangs tat ich mir noch ein wenig schwer, denn schließlich ist die Anzahl der Testklassen – genereller: die Menge an Testcode – für ein SUT meist deutlich mehr. Neben der Umgewöhnung des „nicht mehr über Assembly-Boundaries“ hinweg arbeitens hatte ich das Gefühl, dass mich der Testcode „stört“ oder mir „im Weg steht“. Doch dieses Gefühl war schnell wieder weg, als ich das Prinzip auf größere Projekte angewendet habe und immer wieder die Tests für die Spezifikation und das Codeverständnis gebraucht habe. Spätestens dann war bei mir die Erkenntnis da: Side-By-Side-Specifications Rule!

Doch mit dieser „Colocation“ der Tests an die Implementierung tauchen neue Fragen auf. Eine ganz besonders oft gestellte Frage ist die der Auslieferung der Tests in Release-Assemblies. Es ist schließlich erstrebenswert, nur das in ein Release einfliessen zu lassen, was auch wirklich vom Benutzer gebraucht wird: die Funktionalität. So stand ich auch vor dieser Aufgabe, welches sich aber sehr schnell und vor allem einfach bewältigen ließ.

Reduce to the Max

Die Idee ist denkbar einfach: Wenn ich Tests und Implementierung zur Entwicklungszeit nicht trenne, dann trenne ich sie eben später, undzwar zur Auslieferungszeit. In einfachen Worten: der Build muss diese Aufgabe erledigen. Da ich sowieso meinen Code über Build-Skripte bauen lasse, lag es sehr nah, diese Skripte einfach anzupassen. Für meine eigenen Projekte habe ich oft ein kleines Powershell-Skript. Bei größeren Projekten oder CI-Umgebungen ist der Aufruf eines eigenen Post-Clean-Events vor dem Build ein guter Extension-Point.

Als ich die Menge und den Inhalt der Kommentare bei Stefan’s Post gesehen habe, dachte ich mir nur: warum schreiben so viele darüber und finden es „schwierig“ oder „unsauber“, ohne es offensichtlich einmal probiert zu haben? Ich habe es probiert und ich fand es überhaupt nicht schwierig – ganz im Gegenteil. Jetzt ist das für mich eine viel angenehmere, effizientere und vor allem intuitivere Arbeitsweise. Das Build-Skript zum filtern der Testartefakte ist denkbar einfach, bei mir sind das meistens nur so 10 bis 20 Zeilen. Schließlich ist es ja auch „nur“ ein Release-Build. Ich rufe es nicht die ganze Zeit auf wie ein CI-Build, und CD mache bzw. brauche ich derzeit auch nicht.

„Soooo lange, wie ich brauche, diese Kommentare überhaupt zu lesen, brauche ich nicht einmal, wenn ich sogar das Build-Skript per TDD erstelle“ war mein Gedanke, als ich mit dem Lesen der Kommentare fertig war. Und da ich ein Freund von empirischen Erkenntnissen bin, dachte ich mir: „Auf geht’s, das machst Du jetzt!“. Gesagt getan. Das Ergebnis kann man sich auf github ansehen. Erkenntnis: Die Entwicklung des Build-Skripts (ohne TDD Framework und mit meinen „bescheidenen“ Powershell-Kenntnissen) hat etwas mehr als eine Stunde gedauert. So lange habe ich in etwa auch zum Lesen der Kommentare gebraucht ;-)

Separation of Concerns

Doch zurück zum Thema. Beim Lesen der Kommentare ist mir auch aufgefallen, dass man öfter das Argument der „Separation of Concerns“ (SoC) gegen die Zusammenführung von Tests und Implementierung anbringt. Es sei im Sinne der SoC, Tests von der Implementierung zu trennen. Auch gute Freunde von mir, wie z.B. Tehlike – für den ich im Übrigen diesen Post auch auf Englisch verfasst habe – entgegneten mir das gleiche Argument. Dazu mein Statement:

Tehlike, yanılıyorsun! ;-)
(Auf deutsch: Tehlike, Du irrst Dich!)

Ja, ich denke diejenigen irren sich, die SoC als Argument für eine Trennung von Tests & Implementierung anbringen. Sie irren sich meiner Meinung nach sogar gewaltig. Denn SoC ist in meinen Augen bei genauerer Betrachtung sogar ein Argument für die Zusammenlegung von Tests und Implementierung.

Separation of Concerns besagt nämlich, dass unterschiedliche Zuständigkeiten eines Objekts voneinander getrennt werden sollten. Zuständigkeiten sind im Sinne der Domänenmodellierung und Systemanalyse Aspekte von Verhalten und Funktionalität. Ergo: Unterschiedliche Zuständigkeiten eines Verhaltens sollten voneinander getrennt werden. Ein schönes Beispiel ist der Taschenrechner. Die Funktionalität des Addierens des Taschenrechners gestaltet sich aus dem Tastenfeld, der Recheneinheit, und der Anzeige. All das sind Aspekte der Funktionalität, die in eigenständige Zuständigkeiten münden. Im Sinne der „Separation of Concerns“ sind diese Aspekte zu trennen und damit die Komponentenorientierung und Wiederverwendbarkeit zu stärken.

Completeness of Concern

So weit, so gut. Doch Separation of Concerns bedeutet für mich im Umkehrschluß auch, dass man eine Zuständigkeit einer Funktionalität auch zusammenhalten sollte. Ein einziger „Concern“ sollte in sich geschlossen sein. „Das ist er doch automatisch“ denkt man sich. Naja, ganz so einfach ist es meiner Meinung nach nicht. Denn eine Zuständigkeit einer Funktionalität findet man in der Software-Entwicklung oftmals nicht als „ganze Einheit“ an einem Fleck, sondern überall verteilt.

So wird z.B. in der klassischen Softwareentwicklung die Zuständigkeit in den Requirements erfasst. Man findet sie in der Use-Case-Dokumentation und in UML-Diagrammen wieder, diesmal mit ein oder zwei Szenarien. Natürlich wird das Verhalten und dessen Aspekt auch in den Tests manifestiert – dazu sind sie ja da. Und – wer hätte das gedacht – die Funktionalität findet man auch im Code wieder. Resultat: Ein einziger Concern, der im Entwicklungsprozess an allen möglichen Stellen auftaucht. In einem solchen Szenario ist es für den Entwickler meistens wie ein Puzzle, bei dem die Puzzlestücke überall sind – nur nicht auf dem Tisch.

Es ist also für die „Vollständigkeit einer Zuständigkeit“ nicht hilfreich, Tests und Implementierung voneinander zu trennen. Weiterhin hat das Trennen von Tests und Implementierung nichts mit Separation of Concerns zu tun, denn schließlich geht es sowohl bei den Tests als auch bei der Implementierung um einen einzigen Concern – dem Aspekt der Funktionalität, die das SUT eben abbilden soll.

Es ist gerade die Fraktion der BDD-Anhänger, die genau diesem Umstand mit all Ihren Argumentationen und Prinzipien hervorheben möchten. Sie reden nicht von Tests, sondern von Spezifikationen, sie reden nicht über Verifikation, sondern über Verhalten. Ja, sie gehen sogar soweit und reden im Sinne der Context-Specifications von „Concerns“, also „Zuständigkeiten“. Das alles sind klare Hinweise, das die Spezifikation eines Verhaltens und deren Umsetzung als unzertrennliches Paar zu betrachten sind. Übrigens ist diese „Expressivität“ auch ein Grund, warum „BDD“ so gut geeignet ist für Einsteiger in TDD bzw. Test-First.

Feels just like it should

Wenn man mal eine gewisse Zeit per TDD/BDD entwickelt, dann fällt einem oft auf, dass man bei jeder Änderung mindestens zwei Dinge ändert. Man ändert oder erweitert die Tests und man ändert oder erweitert die Implementierung. Ein Verhalten, eine Zuständigkeit, doch zwei Perspektiven, zwei Änderungspunkte.

Das ist bei Far-Specs, (also getrennten Tests und Implementierung über Assembly-Boundaries) genauso wie auch bei Near-Specs (Tests & Implementierung Seite-An-Seite). Doch bei Near-Specs ist es einfacher, schneller und intuitiver, Änderungen am System durchzuführen. Darüber hinaus wird das Streben nach „Vollständigkeit eines Verhaltens und deren Zuständigkeit“ gestärkt. Das wiederum zahlt auf Lesbarkeit, Wartbarkeit und Flexibilität ein.

Seit nun seit knapp 3 Monaten entwickle ich Unit Tests, TDD & BDD ausschließlich per „Side-By-Side-Specifications. Diese „andere“ Art der Codeorganisation ist für mich äußerst angenehm und effektiv gleichermaßen. Für mich ist es ein stückweit näher dran am „TDD-Spirit“, dem test- bzw. spezifikationsgetriebenen designen und entwickeln von Software. Mit Tests & Implementierung nebeneinander fühlt es sich so an, wie es eigentlich sein sollte.

Also: Feels just like it should ;-)

It’s been something like a week since Stefan asked a provoking question in his blog (german): „Where to put the Tests?” He wrote that he’s strictly separating tests from their implementation in separate projects. However, motivated by a statement of me, he gave the idea of having tests & implementation in the same project a try. Wow, all code in one assembly. He as well as a punch of commentators on his blog came to the conclusion, that separating tests from implementation using separate projects is better. I argue the converse.

It’s simply old-fashioned style to separate tests & implementation with separate projects. I did separate my tests from implementation code for years. However, about half a year ago, I realized that this separation doesn’t help me much. Instead, it hinders my development process. Since then I keep tests & implementation together in one project. They are located as near to each other as possible. Let’s name this “side-by-side” residency. In this post I want to show and explain the main reasons, consequences and experiences in favor of “side-by-side specifications” or “near specs”.

Well, first of all, I reduce the practice of „near specs” to unit tests only. Just as in classical sense of TDD. Integration tests and verification-driven tests are located in separate projects (thus being “far specs”), as usual. For me, putting tests and implementation altogether in one project makes sense in test-first approaches. That is, TDD testing or BDD specifications. Ergo: It’s about tests I use to drive my implementation. Tests, which I’m using to design and develop the desired functionality.

The grip of behavior

So, what’s the point then to put tests and implementation side-by-side? In my opinion there’s a quite naive, yet effective reason: You get grip of your tests. The tests are simply there. They’re where I need them; they’re there where I expect them. They are right there where the behavior is. Since I keep tests next to my implementation, I’m just better able to “put them in shape”. Means: I do refactorings a lot more effective and frequent. Naturally not only on SUT, but tests as well.

Generally speaking, it’s a kind of different, more efficient style of development to work with implementation & tests right at hand. Coming back to projects after some time makes it a breeze. I just look and read the tests. Then, I navigate frequently between tests and implementation to understand the details. “Near specs” make it less painful and more pleasant to read the code. This is especially the case for tests where several dependencies / mocks exist. No jumps through projects, no loading of solutions here and there. Just reading, that’s it.

To put it candidly, it was hard at start. The number of test classes – or the amount of test code in general – is quite a lot compared to implementation code only. I had to get used to it somehow. From time to time, I had a strange feeling that my tests are distracting me. It was so unusual for me that I felt that my tests “messed up” my organization in my “production” project. It didn’t last long though. As I continued to keep my tests right where my implementation is, I more and more realized how cool and beneficiary it is to do so. Especially as I utilized this approach on a larger codebase. Since then, it’s clear for me: putting specifications/tests side-by-side rules!

Wait, the world’s not shining always. New questions arise with this new “colocation” of tests right where the implementation is. Probably the most often asked is how the release assemblies of such applications look like. Needless to say, it’s desirable to let release assemblies contain only what the customer actually needs: the functionality. However, with tests in same assembly, how would you achieve this?

Reduce to the Max

The solution is quite simple: If tests and implementation are no longer divided in design- or development-time, then the split-up needs to take place later on, at delivery-time! Simply put, the build needs to take care of this task. Since I’m used to use build scripts for my projects, it’s quite a common thing for me to adjust end enhance my scripts to filter out the test classes and test-related references. For my own tiny projects, I most often use powershell scripts. At larger contexts with CI and Buildsystems, a call to a cleanup extension is an obvious, handy task.

Back to Stefan’s post. As I read through comments, I thought to myself: Why do so many people write so much about it and judge this approach as “tricky” or “dirty” without obviously not having tried it once? I did give it a try and I’m feeling very fine with it. It’s neither difficult, not dirty at all. The contrary is the case. Now that I use „near specs“, my daily TDD and development life is more pleasant and effective than before. Building a filter for test-related artifacts is an easy task. In my scripts, I usually need about 10 lines for this. Moreover, it’s worth to keep in mind that filtering is “only” needed for release builds. No CI build whatsoever affected.

Once read through the whole thread, I just said to myself: „I even would build my build script test-first faster than reading all this”. As some of you know me as a friend of empiric results and measurement, it’s obvious that I needed to check if my statement really would turn out true. Just do it and see if it’s really that fast and easy. No sooner said than done! I pushed the results to my github repository. Brief summary: Even without test-framework and with my „limited“ powershell knowledge, I was able to build my test-artifact filtering in about the same amount of time I spent to read the blog. ;-)

Separation of Concerns

Another argument quite often rose against putting tests and implementation together is “Separation of Concerns” (SoC). “Partitioning tests and implementation in separate projects is following this principle”, it’s being said. Even good friends of mine, like Tehlike bring SoC onto the table against “near specs”. By the way, I specially write this article in English for Tehlike, and therefore:

Tehlike, yanılıyorsun! ;-)
(In english: Tehlike, you are mistaken!)

Yes, I think that those are mistaken who think that SoC is a reason to split tests and implementation. From my perspective, the opposite is the case. SoC is – once considered to look at it carefully – even a reason to put tests and implementation side-by-side.

The essence of Separation of Concerns is quite easy: diverse perspectives, say „concerns“, of a behavior of an object should be separated. „Concerns“, in context of domain modeling and system analysis, are aspects of behavior and functionality. Take the calculator example. The functionality of „addition“ of a calculator has different aspects. You need to enter the numbers through keys, the calculation unit needs to add the numbers, and the sum needs to be displayed. All concerns – better: different concerns – of one functionality. With respect to „Separation of Concerns“, those aspects need to be separated. In consequence, a component-oriented and reusable solution is fostered.

Completeness of Concern

So far, so good. But wait. For my understanding, Separation of Concerns means by implication, that a single concern should strive towards entirety. That is, one single concern ideally should aim completeness. „Isn’t this automatically the case?“ you might think. Mhh, not really, in my opinion. Most often, one concern is located on very diverse and unusual locations within a software development process.

Take the „classical“ software engineering scenario as an example. A behavior and its concern is described in requirements documentation. You can find different, mostly edgy details of the same concern in UML diagrams and Use Case documents. Of course, tests reflect the concern again. Well crafted, tests most likely specify the concern at its best. Naturally, the concern is in production code, implanted as final functionality of the system. And what’s the result now? Straight answer: The result is a mess. Most often, a developer finding himself in such a situation is faced with puzzle pieces everywhere – but not on the table.

Hence, for me it’s obvious that partitioning tests and implementation in separate projects is not helping me to strive towards „Completeness of Concern“. Moreover, splitting up tests an implementation is not related to Separation of Concerns. Both tests and implementation care about the same concern, that’s the simple truth.

BDD lovers in the wild will clap their hands. The abovementioned is more or less the same they proclaim over and over. They don’t talk about tests; they care about “specs”. They don’t talk about verification; they care about “behavior”. Yes, they even care about concerns, drivers and observations. Altogether, this is even for beginners quite a good hint towards a mindset, where tests and implementation build a chained, inseparable pair.

Feels just like it should

Let’s face it. Once developing a reasonable time in TDD/BDD style, you clearly realize one thing: Whenever you need to change or extend the system, you have at least two „changepoints“. First, you change tests. Right afterwards, you change your implementation. One single behavior, one single concern. But two perspectives, two edits. That’s the case for „far specs“ (that is, tests located in a separate project) as well as for “near specs” (that is, tests residing in the same project along with the implementation “side-by-side”).

The difference: With near specs, you change and develop the system faster, & easier. It’s simply more efficient and intuitive. Near specs foster „Completeness of Concern“. This essentially contributes to better readability, maintainability and flexibility of the overall system.

It’s been more than 3 months now since I started to structure my unit tests strictly side-by-side along to my implementation. For me, this “different” style of code organization is absolutely pleasant and effective. Right now, I can’t think of switching back. In my opinion, putting tests and implementation as near as possible is in favor of the “TDD spirit”. With tests and implementation being at the same place, for me TDD now more and more “feels just like it should” ;-)

In vielen Kommentaren und Blog-Posts wurde die jüngste Bewegung über .NET Coding Dojo’s als „für die Community nicht hilfreich“ tituliert. Jetzt, wo es zwei verschiedene „Stile“ von .NET Coding Dojo’s gäbe, sei auch noch ein entscheiden und ein „was ist nun besser“ hinzugekommen. Den Meinungen kann ich mich größtenteils anschließen. Doch ich möchte noch etwas hinzufügen: Das philosophische, frenetische, ja fast religiöse Reden und Ausarbeiten dieser „Stilunterscheidung“ zwischen Schwarm und Latifa ist mir doch deutlich zu krass und hat mich über die letzten Tage mehrheitlich nur dazu gebracht, beim Lesen der Meinungen immer wieder zu denken: „Hääh, oder wie oder wat?“

Eine Bereicherung

Insofern finde ich es ein schlechtes Signal und eine besorgniserregend überspannte Kommunikation, von „der Teilung der Dojo-Welt“ oder der „Trennung der Community in zwei Lager“ zu sprechen. Das Gegenteil ist der Fall, die „Community“ wird bereichert. Sie wird bereichert um andere Sichtweisen, um andere Vorgehensweisen und andere Menschen – ganz unabhängig davon, ob die Bereicherung nun als gut oder schlecht zu bewerten ist.

Darüber hinaus ist es schlichtweg überzeichnet, wenn man sich so massiv mit der „Gestaltung von Coding Dojo’s“ auseinandersetzt und die „Stilrichtungen“ oder “Schulen“ miteinander in fast religiös ausufernder Manier differenziert. Coding Dojo’s sind bei weitem nicht das einzig wichtige für einen Software-Entwickler, zumindest für mich. Ich mache Coding Dojo’s aus Spaß – in meiner Freizeit. Andere machen es vielleicht aus einer anderen Motivation heraus. Aber das in letzter Zeit ist mir deutlich zu viel des Guten, wenn es überhaupt dem Attribut gutwillig genüge träge. Es gibt auch noch andere Dinge, also sollte man das ganze Tohuwabohu um die .NET Coding Dojo’s relativieren.

Ich 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 Motivation, irgendwelche „Lagerschaften“ zu erarbeiten. Nein, vielmehr ist diese Formalisierung der Regeln aus der Erfahrung des Coding Dojo’s bei den dotnetpro.powerdays entstanden. Meine Wahrnehmungen waren nämlich deutliche Divergenzen zwischen dem Verhalten einzelner Teilnehmer und den als „Latifa“ titulierten Werten.

Latifa ist tot, es lebe Latifa

Ich denke auch, dass die Werte-Prinzipien sowie auch andere Prinzipien, auf die ich hier nicht näher eingehen werde, nicht als spezifisch für ein Coding Dojo reduziert werden können. Ich denke, die „Latifa-Werte“ sind über ein Coding Dojo hinaus auch im täglichen Miteinander und Arbeiten beachtenswert. Deswegen – und wegen der für mich zu konterkarierenden Darstellung der Stilisierung von Dojos – werde ich die Latifa-Werte nicht mehr ausschließlich im Kontext von Coding Dojo’s anwenden. Es gibt kein „Latifa-Coding-Dojo“ mehr. Weil für mich diese Werte & Prinzipien nicht nur für Coding Dojo’s gelten, sondern in meiner Welt Anspruch auf Allgemeingültigkeit erheben.

Schwarm drüber?

Also, alles wieder gut, alles wieder lustig und soz. „Schwarm drüber“? Nein, ist meine klare Antwort. Jedenfalls nein für mich. Es ist ja auch meine Perspektive, die ich hier schildere. Ich habe für mich erkennen und lernen dürfen, dass ich offensichtlich eine eingeschränktere Menge an Gemeinsamkeiten mit Meinungen, Verfahrensweisen, und Prinzipien anderer habe. Besonders ist mir aufgefallen, dass ich – für mein eigenes Bedauern – mit Ralf und Stefan weniger Gemeinsamkeiten habe als ich zunächst vermutete.

Ich habe den Eindruck, dass meine Ansichten & Werte sich von den Werten & Prinzipien von Ralf & Stefan auf fachlicher Ebene deutlich unterscheiden. Meine Wahrnehmung ist weiterhin, dass die Unterschiede zwischen mir und Ralf/Stefan auf persönlicher Ebene noch deutlicher sind. Für mein Empfinden ist für diese Relation der Begriff des „diametralen entgegen stehens“ durchaus treffend.

Das .NET Coding Dojo für „Profi’s“ ist Schwarm ?!?

Ein Beispiel dafür ist für mein Empfinden die Zielsetzung bei Coding Dojo’s. Ich mache Coding Dojo’s in meiner Freizeit und ich möchte in meiner Freizeit Spaß haben. Das ist für mich soetwas wie ein Primärziel. Diesen Eindruck habe ich von der Zielsetzung von Ralf nicht. Für mich stellt sich die Zielsetzung von Ralf als zielorientiert und leistungsorientiert dar. Bei Ralf geht aus meiner Sicht deutlich mehr um „professionelles Lernen“.

Ein weiteres Indiz ist sicherlich die unterschiedliche Betrachtungsweise von „professioneller & moderner Softwareentwicklung“. Für mein Empfinden genügen doch eine ganze Menge an Ansichten und „Lehren“ von Ralf & Stefan nicht mehr meinem Anspruch der professionellen & modernen Softwareentwicklung.

Das fängt für mich schon bei unnötigem Sauberkeitsfetisch wie dem Trennen von Tests und Produktionscode in verschiedene Projekte an. Das ist für mich ja schon fast wie jeden Tag das Auto durch die Waschanlage zu fahren. Zum Einen, weil der Code ein kleines Code Kata im Coding Dojo ist und keine Mission-Critical-Anwendung. Zum Anderen, weil es schlichtweg nicht mehr zeitgemäß ist, Tests vom SUT zu trennen. Je näher sie zueinander stehen, um so besser.

Frankreich wird Fußballweltmeister

Ich könnte jetzt weitermachen und „weiterwettern“, z.B. das für mein Dafürhalten das von Ralf & Stefan transportierte „TDD“ mit der Anleitung des „vorher die Lösung auf Papier erfassen“ und dann „gestärkt und mit klarem Kopf Tests programmieren“ so viel mit TDD zu tun hat wie Frankreich mit der Fussballweltmeisterschaft (Anmerkung des Autors für den “ernsthaften” Leser: Das war ein kleiner übertriebener Witz am Rand. Bitte schmunzeln, Danke.)

Doch ich werde dieser Versuchung widerstehen, denn ich habe für mich erkannt, dass es eben verschiedene Ebenen und subjektive Wahrnehmungen von professioneller & moderner Software-Entwicklung gibt. Ich hatte schon im meinem Artikel über „mein .NET Coding Dojo“ (ergo: meine Perspektive eines Coding Dojo’s) schon angedeutet, dass ich mich gerade mit dem Thema TDD & Planung noch deutlich sowie ausführlich äußern möchte und werde. Zurück zur Professionalität & Modernität.

Meine Wahrnehmung der unterschiedlichen Grade und Auffassungen von fachlicher sowie persönlicher Professionalität & Modernität zwischen dem nun nicht mehr vorhandenen „Latifa-Dojo“ und dem „Schwarm-Dojo“ ist es auch, die mich dazu veranlasst, ab heute auch bestimmte Begriffe bei meiner Kommunikation mit .NET Coding Dojo’s explizit auszuschließen. Dazu zählen „Lerne & Lehre“, „Professionell“ & „Modern“.

Das heisst nun keineswegs, dass es keine Coding Dojo’s gibt, die moderne & professionelle Software-Entwicklung fokussieren. Das heisst vielmehr, dass ich mir moderne & professionelle Methoden bei einem Coding Dojo wünsche, aber sie eben nicht bei allen erfüllt werden.

Fun as fun in fun

Abschließend kann ich für mich als folgendes Fazit ziehen: Ich werde weiter .NET Coding Dojo’s besuchen. Vor allem, weil sie mir Spass machen. Wenn sie mir keinen Spass mehr machen, dann werde ich sie auch nicht mehr besuchen. Der Spass steht bei mir im Vordergrund, denn es ist für mich eine Freizeitaktivität. Diese Freizeitaktivität hat mir viele Erkenntnisse beschert. Und das ist gut so.

Aber ich werde mich auch von Coding Dojo’s distanzieren, die dieses Primärziel für mein Dafürhalten nicht erfüllen. Dazu zählt für mich das „Schwarm-Dojo“. Es mag andere Meinungen dazu geben und auch andere Entwickler, die eben mehr Wert auf andere Komponenten legen. Für diese mag viellecht auch ein „Stil“ wie der Schwarm-Dojo schön, gut, frisch und fröhlich sein. Gut. Für mich ist es eben nicht so.

Selbst wenn die inhaltliche Substanz eines Schwarm-Dojo’s für mich attraktiv wäre (was sie für mich nicht ist), ja selbst dann würde ich mich auf Grund der momentan für mein Empfinden zu großen persönlichen Diskrepanz zu Ralf & Stefan mit großer Wahrscheinlichkeit nicht dazu motivieren können, ein Dojo mit Ralf & Stefan zu besuchen.

Auf dem Eisberg

Ich werde weiter auf dem Eisberg sein. Wenn meine Werte, meine Prinzipien und meine Arbeitsweise mein Eisberg sind, dann bleibt mein Name ist zwar Ilker, aber auf dem Eisberg bin ich so ähnlich wie Kalle. :-) Na juuud juuuud juuud juuud juuud…

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:

• Falls jemand „Spectator“ sein möchte, muss er es bei Dojo-Beginn allen mitteilen. Zuschauer haben keine Pflichten, aber auch keine Rechte. Im Gegensatz zu den Teilnehmern dürfen sie keinen Beitrag leisten, sondern nur „beobachten“. Sie werden auch vom Abstimmungs- und Feedback-Recht befreit.
• Eine Person darf nur einige Male – sagen wir mal bis zu dreimal – „Spectator“ sein. Spätestens beim 4. Dojo-Besuch muss er aktiv werden. Sollte er es weiterhin nicht wollen, muss er alle Teilnehmer um Beobachtungserlaubnis bitten. Bei Erlaubnis bleibt er „Spectator“, bei Verweigerung muss er das Dojo verlassen.

§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:

• Jeder einzelne Teilnehmer ist verpflichtet, andere auf mögliche Respektsverletzungen hinzuweisen. Er kann sich jederzeit dem „Operator“ zuwenden. Es obliegt dann der gesamten Dojo-Gruppe, sich gemeinsam zu besinnen. Das kann durch auflockernde Übungen, eine kurze Pause oder andere Besinnungstechniken geschehen.
• Bei einer offensichtlichen Respektsverletzung, ob willentlich oder nicht, wird das Dojo sofort abgebrochen. Es gibt keine Retrospektive, keine Diskussion. Die Beteiligten an der Respektsverletzung werden durch die anderen Teilnehmer oder den Operator auf Ihr Fehlverhalten höflich und respektvoll hingewiesen und dazu aufgefordert, Ihr Verhalten zu reflektieren und eine Lösung zu erarbeiten. Das Dojo wird nach Abbruch nicht wieder begonnen. Alle Teilnehmer verlassen das Dojo.

§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:

• Ein Lächeln ist der Botschafter der Optimismus. Jeder Teilnehmer ist dazu aufgefordert, seine positive Grundhaltung auszudrücken. Manche Lächeln, manche machen kleine Witze, manche suchen Nähe und das Zwischengespräch. Trotz aller Aktivität und Fokus, die man beim Dojo hat (siehe „Regel 1“), ist Optimismus eine Voraussetzung, der man auch als Teilnehmer nachkommen soll.
• Stellt ein Teilnehmer für sich fest, nicht mehr positiv Beitragen zu können, sollte er aus freien Zügen – auch ohne Angaben jedweglicher Gründe, wenn nötig – das Dojo verlassen dürfen. Denken andere Teilnehmer, dass jemand in der Gemeinschaft keine positive Grundhaltung mitbringt, sind sie dazu aufgefordert, demjenigen mit ermutigenden und positiven Worten ihre Wahrnehmung mitzuteilen. Das kann persönlich in der Pause geschehen, oder aber indirekt durch Beteiligung des Operators.

§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:

• Es gibt keine Leistungsziele und keine Leistungsmessung. Weder von Einzelnen, noch von der Gemeinschaft. Ausschließlich Bewertung im Sinne des Feedbacks und des Meinungsaustausches sind für die Teilnehmer möglich. Teilnehmer mit Leistungsanspruch sind von den anderen Teilnehmern von diesem Anspruch freizustellen.
• Selbstbestimmt heisst nicht selbstautoritär. Trotz der Zwanglosigkeit gelten für jeden Teilnehmer die Grundsatzregeln, die Grundsatzvorgehensweise sowie die Regel des kollektiven Entscheids. So ist es verpflichtend und selbstverständlich, wenn ein Teilnehmer einer anderen Auffasung ist die Mehrheit der Teilnehmer, dass dieser sich der kollektiven Meinung beugt bzw. nach dem gemeinsamen Entschluß zu richten hat. Ist die eigenee Meinung mit der gemeinschaftlichen Meinung fundamental nicht vereinbar, so bleibt es jedem frei, das Dojo zu verlassen.

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.

Wie dem auch sei, am Ende des besagten Artikels hatte ich einen Ausblick darauf gegeben, dass ich nicht nur die Punkte nennen werde, die ich als Schwachstelle in Scrum sehe, sondern auch meine Ideen dazu beitragen werde, diese Schwachstellen zu stärken und damit Scrum als agile Managementmethode für mein Verständnis erfolgreicher zu implementieren. Das habe ich für das Thema “bessere Sprintdauer” schon getan, und damit widme ich mich heute einem ganz besonderen „Schwachpunkt“ – dem Scrum Master.

Die innere Handbremse

„Oh je, der Scrum Master ist ein Schwachpunkt von Scrum?“ werden sich nun viele stirnrunzelnd denken. Ja, genau so ist es, der Scrum Master ist meiner Meinung nach sogar eine richtig hinterlistige Schwachstelle in Scrum-Projekten. Das liegt viel weniger an dem Scrum Master als Person als am Scrum Master als Rollenimplementierung, wie er in vielen Büchern beschrieben wird und von Scrum-Trainern bei Unternehmen „antrainiert“ wird.

Viele Scrum Master in heutigen Organisationen sind „Vollzeit-Scrum Master“, die dediziert ein Scrum Team betreuen und sich tagtäglich mit den Sorgen, Nöten und Bedürfnissen Ihres Teams auseinandersetzen. Meiner Meinung nach ist hier schon der erste Schwachpunkt erkennbar. Obwohl die Rollendefinition in „Scrum-Bibeln“ nicht oft vom Scrum Master als institutionalisierte Position spricht, wird sie überall diskutiert, implementiert und implantiert.

Ein Scrum Master ist dazu da, sich überflüssig zu machen. Eines seiner größten Ziele ist es, sein Team in die Selbstorganisation zu führen und dort zu halten. Doch wie geht das bei einem Scrum Master, der eine Planstelle in einer Organisation ist? Mehr noch, hinter der Rolle Scrum Master verbirgt sich dann eine konkrete Person, ein konkreter Arbeitsplatz, ein konkretes Schicksal. Und diese Person soll sich jetzt überflüssig machen? Das wird wohl selbst der barmherzigste Mensch nicht tun. Jetzt könnte man diesen Vorwurf mit „don’t blame the tool“ abwiegeln, aber das wäre zu einfach. Die Schwachstelle liegt viel tiefer begraben als es auf der Oberfläche sichtbar ist.

Zwischen den Stühlen

Zumeist befindet man sich als Scrum Master innerhalb einer „agilen“ Organisation sowieso in der Zwickmühle. Einerseits sollte man das Team nicht führen, sondern begleiten. Andererseits bleibt das Management als „Chicken“ selten mehr als die ersten paar Sprints ruhig. Nicht selten trägt es „Erwartungen“ und „Strategische Leitlinien“ an den oder die Scrum Master heran. Schließlich ist der Scrum Master ja überzeugt von Scrum und der Idee, dass der Product Owner nun das Management betreiben soll. Die Kennzahlen über Team- und Projektperformance holt man dennoch beim Scrum Master ein, weil der „einfach näher dran am Geschehen ist“.

Viele Scrum Master fügen sich in diese organisatorische „Kneifzange“, anstatt sie mit Kraft zu durchbrechen. Wie soll man auch, wenn z.B. der eigene Job daran hängt oder die letzte (dicke) Auszahlung des Dienstleistungsvertrages mit dem Kunden noch aussteht?

Der Alleskönner

Viele eingefleischte Scrum-Experten und erfahrene Trainer stellen deshalb die Rolle des Scrum Masters auf ein hohes Podest. Der Scrum Master sei „eine Führungsrolle im Prozess“, es dauere tausende von Stunden, die Charakteristika und schwierigen Aufgaben eines Scrum Masters zu meistern. Ein Change Agent und Facilitator hat es eben nicht leicht.

Der Scrum Master als Rolle wird oft als Alleskönner dargestellt. Schließlich muss er die Grundlagen des Managements beherrschen, ein absoluter Teamplayer sein und obendrein auch noch ein feiner Kerl den jeder mag. Der Scrum Master ist der neue MacGyver in der agilen Software-Entwicklungslandschaft und kann selbst aus den schwierigsten und aussichtslosesten Situationen mit Einfallsreichtum, Know-How und Cleverness den Erfolg hin zur effektiven & profitablen Software-Entwicklung gestalten.

Eine schöne Vorstellung. Doch die Realität ist eine andere. In der Realität gibt es nur einen MacGyver, und den sogar nur im Fernsehen. Schade für die vielen Softwarefabriken und Weborganisationen, schade für die vielen Scrum Trainer und Berater, schade für die Tausenden von „Certified Scrum Master“. Doch Karten auf den Tisch: Es wäre auch zu schön gewesen, oder?
Mittlerweile ziehen sogar Alpha-Agilisten und Scrum-Kenner das „Scrum Is Always Better, Scrum Master Is Always Hero“-Gefühl durch den Kakao. Mit wunderbar leichtem und gleichzeitig nachdenklich stimmendem Humor schreitet seit einiger Zeit „Scrum Norris“ durch die geistigen Pfade der Agilität.

Quo Vadis Scrum Master?

Doch weder Humor noch Lamentiererei helfen einem dabei, diesen Schwachpunkt des „Scrum Master-Daseins“, nämlich die viel zu starke Fokussierung der Rolle und deren Implementierung, zu verbessern. Was tun? Wie kann man in einem Scrum-Team oder in einer Organisation mit Scrum-Teams diesen viel zu starken Fokus auf den Scrum Master mindern? Ich möchte hier einen konkreten Verbesserungsvorschlag und eine konzeptionelle Perspektivänderung als Diskussionsgrundlage vorstellen.

Dazu möchte ich ein Szenario aus der Entwicklung selbst voranstellen, um den Effekt der Maßnahme deutlicher hervorzuheben. Es wäre meines Erachtens sehr hilfreich für Team und Scrum Master, wenn die Abhängigkeiten zum Scrum Master zu allen anderen Rollen sowie zu der umgebenden Organisation so gering wie möglich sind. Um Abhängkeiten voneinander zu entkoppeln, gibt es in der Software-Entwicklung einige bewährte Methoden. Eine davon ist die sog. „Dependency Inversion“ oder „Inversion of Control“. Das hört sich doch genau nach dem an, was gebraucht wird, nämlich eine „Inversion of Control“ im wörtlichen Sinne. Nicht der Scrum Master organisiert das Team, das Team organisiert das Team.

Scrum Master in Bewegung

Übertragen auf den Prozess und die Rahmenbedingungen, die die Scrum-Methode vorgibt, ließe sich eine solche Indirektion mit einem einfachen Mittel erreichen: Die Rolle des Scrum-Masters wird im Team rotierend „durchgereicht“. Statt eines Scrum Masters, der sich dediziert um ein (oder noch schlimmer mehrere) Teams kümmert, kümmert sich das Team um die Erfüllung der Rolle des Scrum Masters. In der Praxis kann man den „Scrum Master-Hut“ z.B. sprintweise, monatsweise, oder quartalsweise von Team-Mitglied zu Team-Mitglied weiterreichen.

So ist jeder einmal mit der „Verantwortung“ des Scrum Masters konfrontiert und lernt obendrein eine weitere, wichtige Perspektive des Prozesses kennen. Dadurch erschließt sich sukzessive dem ganzen Team eine tiefere Kenntnis der Vorgehensweise. Es ergibt sich eine induktive Selbstorganisation: Man lernt die Probleme und Aufgaben der Scrum Master Rolle kennen und hilft sich gegenseitig im Team, dass es nicht zu Problemen kommt oder diese schnell ausgeräumt werden.

Aus Sicht des Prozesses mündet das Rotationsprinzip in mehrere Vorteile. Zunächst wird einmal wird nicht nur die Selbstorganisation gefördert, sondern auch das Know-How effektiv verteilt. Der Bus-Faktor wird im Kontext des Prozesses und der Methodensicherheit massiv erhöht.

Refokussierung der Kommunikation

Für den Product Owner ist der wechselnde Scrum Master ein regelrechter Segen: Statt sich die ganze Zeit auf den Scrum Master zu konzentrieren, kann (und muss) er sich nun mit dem ganzen Team auseinandersetzen – so wie es am effektivsten ist und sich auch „gehört“. Darüber hinaus lernt der Product Owner, seine geschäftlichen Anforderungen und Interessen mit der „Masse Team“ zu koordinieren, statt mit dem „Ansprechpartner“ Scrum Master, wenn es mal wieder Abstimmungsprobleme oder Missverständnisse gibt.

Nicht nur der Prozess, sondern auch die umgebende Organisation – also das Unternehmen – profitiert von dieser Maßnahme. Statt wieder neue Stellen oder Stufen in die Organisation zu implementieren, wird durch die Rotation der Scrum Master von „allen“ getragen. Ergebnis: Keine neue „Position“ Scrum Master, keine Kompetenz- und Verantwortlichkeitskonflikte mit Teamleads (Gruppenleiter) oder Head-Of’s (Abteilungsleiter), keine Skalierungsprobleme. Die Führungsmöglichkeiten sind klar und bei einem partizipativen Führungsstil höchst effektiv.

Die Rückkopplung zum mittleren Management und der strategischen Führung wird greifbarer, denn jetzt kann sich das Management nicht mehr den „Scrum Master“ als Mittelsmann für Mitarbeiterführung herauspicken. Der Fokus für wird stattdessen zum Product Owner gelenkt. Der wiederum wird – wie auch das Management selbst – realisieren und anerkennen müssen, dass sich eine Selbstorganisation nicht kommandieren lässt, sondern sich nach Bedürfnissen orientiert.

Scrum Master: Kein Platz für Projektleiter

Das Unternehmen wird schlanker, weil der „klassische“ Projektmanager nun nicht mehr in die für ihn äußerst angenehme „Scrum Master“-Schiene flüchten kann, sondern sie entscheiden muss: Entweder Product Owner oder Team!

Ich selbst dachte vor ein paar Jahren noch, dass der klassische Projektmanager nur die Wahl zwischen Scrum Master und Product Owner hat. Falsch! Heute darf ich die Lehre ziehen, dass ich damals auf den Scrum Master als Rolle viel zu Stark fokussiert gewesen bin. Team und Product Owner sind die “Key Player”, der Scrum Master ist nur Mittel zum Zweck, und das – wenn möglich – nur soviel wie unbedingt notwendig.

Mein Fazit: Mit einem rotierenden Scrum Master schafft man viele inherente Hürden aus dem Weg. Das Team, der Product Owner und die umgebende Organisation fokussieren sich deutlicher auf die Aufgabe. Der Prozess Scrum wird dadurch im Software-Entwicklungs-Theater wieder mehr zum Bühnenbild, das Team zu den Schauspielern und der Product Owner zum Regisseur. Damit ist dann auch eine gute agile Vorstellung wesentlich einfacher und schmerzfreier umsetzbar. Vorhang auf!

Vorne sitzt Ralf Westphal, der Architekt, der Wissenvermittler, der Konferenzorganisator – kurzum eine .NET Lichtgestalt. Er klickt und tippt noch schnell Dinge in sein Laptop. Die Teilnehmer warten. Komisch, üblicherweise macht man Witze und redet über einige interessante Blogposts, bevor es losgeht. Ich hätte z.B. erwartet, dass einer in die Runde „Null oder nicht null, Hauptsache Ergebnis!“ wirft und so ein wenig die Runde auflockert. Doch Nein. Es liegt Konferenzduft in der Luft. Alle starren und warten.

18:45 Uhr – Es geht los: Nach ein paar einleitenden Worten und dem lieben Dank an Jan, dem Hüteträger und Evangelisten für die super Organisation der Location geht es schon los. Ralf ist am Zug. Was danach genau im Münchener .NET Coding Dojo passiert ist, beschreibt Ralf akribisch und meiner Meinung nach ziemlich treffend in seiner Retrospektive für das Coding Dojo. Inhaltlich kann ich dem kaum etwas hinzufügen und möchte mich nochmals bei Ralf für diese gute Session bedanken.

Doch ganz so unkommentiert möchte ich es dabei natürlich nicht belassen. Steffen, der vor kurzem sehr erfolgreich das Hambuger .NET Coding Dojo initiiert hatte, hat in einem Tweet seine Bedenken über den „Community-Gedanken“ geäußert. Seiner Meinung nach ist ein Coding Dojo keine „One-Man-Show“ mit Musterlösung. Ich habe ihm per Twitter schon geantwortet, möchte aber hier noch ein wenig detaillierter auf meine Auffassung eingehen.

Das „Format“ Coding Dojo

Ich hatte schon vor über einem halben Jahr einmal über das Ziel von Coding Dojo’s gebloggt. Damals, in einem Coding Dojo mit Pete, habe ich im Nachhinein mir einige Gedanken über das „Format“ Dojo gemacht. In besagtem Coding Dojo lief nämlich alles – also wirklich alles – gerade nicht so, wie es sich Pete und ich vorgestellt hatten. Wir hatten uns mit ein paar Kata’s vorbereitet und den Ablauf schon ein wenig vorgedacht. Aber es kam alles anders. Warum?

Die Antwort ist einfach: Weil wir es zugelassen haben. Wir haben eine Sache beherzigt: Ein Coding Dojo ist eine Veranstaltung für die Teilnehmer. Jeder sollte nach einem Dojo mit dem Gefühl nach Hause gehen können, dass er etwas gelernt hat. Im Coding Dojo mit dem KataBlog war den Teilnehmern die Komponentenorientierung und das IOC nicht so wichtig wie grundlegendere Themen, wie z.B. MVC als Pattern oder die HTTP-Request-Response-Pipeline von ASP.NET. Das haben wir beachtet und unseren Plan zurückgestellt.

Aber warum ein Coding Dojo ohne Coding?

Adaptiert auf das Coding Dojo von letzter Woche von Ralf lässt sich folgendes hinzufügen: Wir als Münchener .NET Coding Dojo Crew haben Ralf eingeladen, weil es die Teilnehmer – also wir, die Coding Dojo Community – so wollten. Wir haben Ralf nicht eingeladen, damit er eine Show abzieht. Wir haben Ralf auch nicht eingeladen, weil er der Ralf ist.

In einigen vorangegangenen Coding Dojo’s kam als Feedback der Teilnehmer immer wieder „zuwenig Architektur“, „zuwenig Design“, „zuwenig Vorgabe“. Als ich mit Ralf auf der VSOne darüber geredet habe, schlug er ein „Architektur-Dojo“ vor. „Super!“ dachte ich mir und freute mich, den Dojo-Teilnehmern mit einer Einladung ihren „Wunsch“ erfüllen zu können.

Wer beim .NET Coding Dojo vergangenen Mittwoch dabei war, der wird mir beipflichten, dass diesmal wirklich über Architektur, Design, Anwendungsaufbau und Komponenten-Orientierung ausgiebig diskutiert wurde. Ralf hat sein Versprechen gehalten. Er kam, dachte, designte und diskutierte. Genau so, wie es oftmals in Feedbackrunden vorheriger Dojo’s angefordert wurde.

Coding Dojo ist kein Workshop

Trotzdem. Es war anders als die vorherigen Coding Dojo’s. Ganz anders. Keine Diskussionen über die Kata-Wahl, keine Diskussion über Anforderungsanalyse, keine Design-Strittigkeiten. Statt dessen Ralf. Ralf wie er leibt und lebt. Das ist die Aufgabe, das ist die Vorgehensweise, das ist EBC, das ist State-Of-The-Art, das ist Regelwerk & Konvention. Punkt. Natürlich mit fester und stichhaltiger Argumentation und der Erläuterung der Beweggründe.

Aber irgendwie war es kein Coding Dojo so wie ich es kannte. Es gab hier und da mal Rückfragen an Ralf, „wieso“ und „weshalb“. Aber aktiv mitgemacht – aktiv Architektur gemacht – das hat meiner Meinung nach mehrheitlich Ralf getan. Ralf hat schon ab und an probiert per Rückfrage die Teilnehmer einzubinden. Doch andererseits gab es für die Teilnehmer nicht wirklich viele Optionen. Besser gesagt: Es war ein geplante Session, mit strukturierter Vorgehensweise und festem Rahmen. Da bleibt nicht viel Luft und Platz für anderes.

Man kann mir „als Veranstalter“ jetzt natürlich alles mögliche vorwerfen. Z.B. dass ich ja hätte eingreifen können, wenn es mir zu „passiv“ und zu „vorgetragen“ erscheint. Oder man könnte mir den Vorwurf machen, dass ich in den vorangegangen Coding Dojo’s einfach nur chaotisch in die Tasten gehauen habe, anstatt strukturiert vorzugehen und damit praktisch immer wieder so ein „wir brauchen Architektur“-Feedback provoziert habe. Ok, dann soll man mir die Vorwürfe machen. Meine Antwort dazu ist: Ich habe es zugelassen, weil es wichtig ist, Dinge zuzulassen. Darüber sollte man nachdenken.

Coding Dojo und Community

Jetzt transportiere ich mal meine persönliche Auffassung etwas deutlicher, damit es nicht wieder heisst, ich wäre zu objektiv oder würde mich hinter geschnörkeltem Satzbau verstecken. Ich persönlich denke, dass das letzte Coding Dojo absolut kein Coding Dojo war. Es war ein Architektur-Workshop mit Ralf Westphal. Und wenn ich das so sagen darf: Es war ein guter Architektur-Workshop. Aber es war für mich mit Sicherheit kein Coding Dojo. Es gab keine aktive Einbindung der Teilnehmer, es gab keine lockere Atmosphäre, es gab kein Coding und keine großen Diskussionen. Ich finde, das war kein Coding Dojo, wie ich es mir wünsche und wie ich es auch gut finde.

Aber meine Meinung ist nicht wichtig – das habe ich nach nun mehr als 50 Coding Dojo’s gelernt. Es ist nicht wichtig, wie ich Probleme löse. Es ist auch nicht wichtig, welches Framework ich verwende. Und es ist schon garnicht wichtig, wie ich Analyse, Architektur, Design oder Entwicklung betreibe. Denn das einzige was zählt im Coding Dojo sind die Akteure. Die Akteure im Coding Dojo sind die Teilnehmer. Das ist entscheidend.

Dojo = Lernen?

Wenn also die Teilnehmer des „Coding-Dojo’s“ mit Ralf in der Feedback-Runde sagen „Ja, das hat mir gut gefallen, ich habe super mitgemacht & viel gelernt“ – dann, ja dann ist es wohl ein Dojo gewesen. Vielleicht kein „Coding“ Dojo, aber es war ein echtes Dojo. Aber wenn die meisten kommentarlos und höflich klatschend das Dojo beenden, dann, ja dann war es wohl kein Dojo. Wie gesagt: Für mich war das kein Dojo – schon garnicht ein Coding Dojo. Aber das Feedback am Ende von Ralf’s Session war durchaus positiv. Also scheint es für einige Teilnehmer ein Dojo gewesen zu sein.

Natürlich möchte ich an dieser Stelle noch ein paar weitere Dinge loswerden. Ich möchte nicht, dass man die Definition des „Coding Dojo“‘s auf „Hat es dir gefallen?“, “Konntest Du mitmachen?” oder „Hast du etwas gelernt?“ reduziert. Ein echtes Coding Dojo hat einige weitere Parameter, die entscheidend sind für den speziellen, magischen Charakter und den guten Erfahrungsaustausch. Der aufmerksame Leser wird z.B. erkannt haben, dass ich nicht ein einziges Mal TDD erwähnt habe. Wenn Interesse daran besteht, die Bestandteile und das Format „Coding Dojo“ aus meiner Perspektive genauer kennenzulernen, dann bitte sagt mir das (schreibt einen Kommentar oder eine Email), und ich werde es niederschreiben.

Fazit & Ausblick

Abschließend möchte ich zu „Ralf’s Coding Dojo“ noch folgendes loswerden. Es war der Wunsch der Community und ich (und Ralf) haben versucht, diesem Wunsch gerecht zu werden. Es war eine gute Erfahrung. Ich habe viel daraus gelernt und ich denke, dass auch die Teilnehmer etwas mitnehmen konnten. Es war ein guter Architektur-Workshop und Ralf hat viel investiert, um den Teilnehmern seine Sicht zu zeigen und Wissen zu transportieren. Danke, Ralf.

Doch eines steht heute schon fest: das nächste .NET Coding Dojo, welches im Übrigen wieder ein ganz besonderes Dojo ist, wird mit absoluter Sicherheit ganz anders ablaufen. Nicht nur, weil diesmal nicht der Ralf eine Aufgabe stellen wird. Nein. Es wird ganz anders, weil die Partizipation und das aktive teilnehmen exemplarisch exerziert werden. Das nächste Münchener .NET Coding Dojo findet am 22. Juni im Rahmen des dotnetpro.powerday’s statt und hat den treffenden Titel „.NET Coding Dojo Empowered!“. Sei dabei und erlebe, wie man gemeinsam Lernen & Lehren kann, wie man gemeinsam eine Problemstellung mit Logik & Spaß lösen kann, wie man professionelle Software-Entwicklungs-Methoden im Team einsetzt! Es wird wieder einmal einzigartig und sehr lehrreich werden. Zur Anmeldung!

Ralf wird im Mai-Dojo mit uns den Schwerpunkt Architektur & Design trainieren. Einerseits ist das untypisch für ein .NET Coding Dojo, denn schließlich ist im Coding Dojo das „Coding“ nicht nur im Titel verankert, sondern auch das A und O eines jeden Dojo’s. Andererseits sind Anwendungs-Architektur und –Design wichtige Themen, denen besonders im Kontext der testgetriebenen Entwicklung Beachtung bemessen werden sollte. Umso besser und spannender ist es bei diesem Dojo, wie wir alle gemeinsam von der Idee, der Anforderung über die Architektur und bis zum Test-Driven-Design und der Implementierung gelangen werden.

Ein besonderes Thema verlangt auch eine besondere Location. Dank der tatkräftigen Unterstützung von Microsoft und dem Evangelisten mit dem Hut haben wir einen wirklich exklusiven Standort für dieses Dojo gefunden: Das Microsoft-Technology-Center in Unterschleißheim öffnet der .NET-Coding-Dojo-Crew die Pforten für diesen „Extra-Workout“. Danke!

Kühl sag‘ ich, kühl!

Wo wir gerade dabei sind: Die Idee und das Konzept des .NET Coding Dojo’s ist erfreulicherweise schon in einige Städte Deutschlands vorgedrungen. Dennoch – oder gerade deswegen – kommt es immer öfter vor, dass ich angesprochen werde und man mich frägt wie das denn im Coding Dojo so abläuft. Die ALT.NET-Crew in Berlin hat auf ihren Coding-Dojo-Seiten eine ziemlich gute Beschreibung, doch jetzt gibt es eine noch anschaulichere Alternative: MSDN TV war bei einem Dojo in München zu Gast und hat ein paar interessante Impressionen mitgenommen!

Eine Überasschung, aber für mich eines der Highlights in dieser Folge ist die Nahaufnahme von zwei „.NET Coding Dojo Core‘s“, sozusagen dem ideelen Fundament der Münchener Coding-Dojo-Crew, Philipp (aka. Fuip) und Olaf (aka. Nurph). Natürlich gibt es mittlerweile viele tragende Stammgäste und immer wieder neue Teilnehmer, die alle dazu beitragen, ihr eigenes Dojo zu dem zu machen was es ist und mit uns gemeinsam weiter zu trainieren, um so immer mehr und deutlicher an die professionelle Softwareentwicklung heranzukommen. Euch allen vielen Dank! Ach ja, Jan hat in der Folge auch mich zum Thema interviewt. Alles in Allem: Kühl… sehr kühl! :-)

.NET-Coding-Dojo-Chillout

Und weil in München gerade .NET Coding Dojo-Workout-Wochen sind geht es nach der Denk-Design-Diskussions-Orientierung im Mai im Juni wieder direkt an den Code! Das Münchener .NET Coding Dojo wird im Juni wieder ein Dojo erster Klasse veranstalten: Am 22. Juni sind wir zu Gast beim dotnetpro.powerday für C# Profis! Tagsüber wird von Golo und Albert (dem Online-Dojo-Virtuosen) C# Know-How kompakt und verständlich vermittelt, abends wird im .NET Coding Dojo gechillt eine Code-Kata mit dem neu gewonnenem Wissen gelöst. Chillen, Programmieren und Lernen geht nicht? Dann überzeuge Dich vom Gegenteil im .NET Coding Dojo bei dem C#-Profi-dotnetpro-powerday! Anmelden und gechillt coden!

Doch zunächst möchte ich auf die nächsten .NET Coding Dojo-Termine hinweisen, denn der Mai wird ein regelrechter Coding-Dojo-Workout-Monat werden!

Coding Dojo Berlin: Round II

Gong! Die zweite Trainingsrunde für das .NET Coding Dojo in Berlin steht kurz vor der Tür! Morgen schon, am 04.05. werden die Hauptstädtler so richtig die Bude rocken. Ich zitiere: „Strukturiertes Vorgehen, schnelle Finger und messerscharfe Logik sind unsere Waffen!“ So ist es richtig, und die Berliner Crew braucht nicht nur diese Eigenschaften, sondern auch weitere Unterstützung von .NET Entwicklern, TDD-Jüngern und CCD-Freunden. Gemeinsam das Code-Kata lösen, welches Mike schon durch das Sparring gepfercht hat. Sei dabei: Anmelden und Mitmachen!

Coding Dojo Online: Weinert’s 2. Sinfonie

Beim letzten Online Coding Dojo haben der Albert und die Online-Teilnehmer alles gegeben, um das Code Kata zu lösen. Es hat wieder einmal jede Codezeile gezählt. Die Kata und der Albert als virtuos auf der Tastatur fegender Kunst-Coder waren so fesselnd, dass nach dem Fall des ersten Online-Dojo-Vorhangs schon fest stand: Es muss eine 2. Sinfonie geben! Diese Woche ist es soweit. Am Donnerstag, den 06.05. findet das zweite .NET Online-Coding-Dojo statt. Es wird wieder eine Herausforderung erster Klasse werden, also nicht zögern und zaudern, sondern gleich anmelden und mit Albert und der geballten Know-How-Power der .NET-Online-Community das Code-Kata im Online-Coding-Dojo lösen! Auf geht’s!

Coding Dojo Wien: MVC FTW!*

Andreas, Adrian und die Wiener Dojo-Fraktion machen weiter an ihrem ASP.NET MVC Fundament und verknüpfen exemplarische Anwendungsentwicklung geschickt mit dem Coding Dojo und den darin gestellten Herausforderungen des Test-First, TDD & CCD. Das und vieles mehr qualifiziert die Wiener Gruppe zur Avangarde und Vorreitern der Coding Dojo-Szene in Österreich. Sei dabei, wenn es am 14.05. wieder heisst: MVC-Training im Coding Dojo – Anmelden! (*Update!)

Coding Dojo Hamburg: Die Premiere

Vorhang auf, meine Damen & Herren. Die .NET-Community in Hamburg präsentiert das erste .NET Coding Dojo in Hamburg, am 19.05.2010! Es wird eine ganz besondere Premiere, eine würdige Premiere der Coding Dojo Begeisterten in Hamburg werden, denn Hamburger sind bekannt für den hohen Anspruch, den sie an sich selbst stellen. Gleich das erste Coding Dojo wird ein Randori werden. .NET Entwickler im Norden Deutschlands, lasst euch gesagt sein, wer dieses Highlight verpasst, ist selber schuld! Auf geht’s zum .NET Coding Dojo Hamburg: Anmelden!

Coding Dojo München, Dojo Deluxe

Das Münchener .NET Coding Dojo macht weiter und trainiert weiter hart und unermüdlich. Modernste Software-Entwicklungs-Methoden, TDD im Hochleistungsbereich und CCD Eleganz treffen sich in München zum Coding Dojo der Extraklasse. In München geht es im Mai heiß her! Ralf Westphal wird mit der .NET Coding Dojo Gemeinde in München ein Dojo der Extraklasse abhalten und das D in Dojo dick und fett unterstreichen. Denken, Designen, Diskutieren!

Als Sahnehäubchen “On-Top” wird es eine besondere Location geben, die wir eine Woche vor dem Dojo bekanntgeben werden! Freut euch, dieses „Dojo Deluxe“ darf man nicht verpassen! Sei dabei, wenn die .NET Community mit modernsten Software-Entwicklungs-Methoden das Code-Kata von Ralf löst! Auf geht’s: Anmelden!

Coding Dojo Bei Dir!

Nach diesen Dojo-Highlights komme ich wieder zum Anfang meines Posts zurück. Wir, die .NET Coding Dojo Community aus München sind überzeugt von den Vorteilen, die ein .NET Coding Dojo mit sich bringt. Immer wieder freuen wir uns, gemeinsam eine Aufgabe zu lösen, neue und bekannte Gesichter wiederzusehen und uns auszutauschen. Über kleine Dinge, wie z.B. Resharper-Shortcuts. Aber auch über große Dinge, wie z.B. Template Method vs. Higher Order Functions. Das ist es aber nicht, was Pete und mich als Initiatoren der .NET Coding Dojo-Bewegung nun dazu veranlässt, einen Haken hinter unser erstes Etappenziel zu setzen. Es ist etwas anderes.

Mittlerweile gibt es viele Interessierte, die die Idee und das Konzept des .NET Coding Dojo’s gut finden und selbst implementieren. Es gibt .NET Coding Dojo’s nun nicht mehr nur in München, sondern auch in Berlin, Hamburg, Wien, Augsburg, Ingolstadt, Karlsruhe und sogar ortsunabhängig Online! Auch wenn nicht viel darüber geredet wird oder darf, ich kenne mittlerweile eine handvoll Unternehmen, die intern regelmäßig Dojo’s durchführen, und das mit sensationellen Erfolgen. Doch auch diese Verbreitung und das allgemein steigende Interesse für .NET Coding Dojo’s ist es nicht, was unsere erste Etappe als erledigt markiert. Es ist etwas anderes.

Goto Dojo Considered Helpful

Es ist der einfache, ungeschriebene, stille aber dennoch treibende und gedeihende Gedanke, dass die .NET Entwickler-Gemeinde Coding Dojo’s als eine hilfreiche und gleichzeitig unterhaltsame Maßnahme akzeptiert und implementiert. Es ist die Bewegung und Bereitschaft der Community, eigenständig Coding Dojo’s zu organisieren und zu veranstalten. Es ist der schlichte Umstand, dass mittlerweile „.NET Coding Dojo“ nicht mehr nur mit „Pete“ oder „Ilker“ oder diesen Blog hier assoziiert wird, sondern vielmehr mit gemeinsamer Entwicklungsleistung, mit Code-Kata’s, der Clean-Code-Developer-Bewegung und mit den vielen Gesichtern und .NET-Enthusiasten in der Community. Das ist es, was uns dazu veranlässt ein „Check“ zu machen und uns auf schon auf die nächsten Coding Dojo’s zu freuen.

An dieser Stelle möchte ich jeden .NET Entwickler, TDD-Interessierten und CCD-Freund dazu motivieren, selbst an einem .NET Coding Dojo teilzunehmen oder aber ein .NET Coding Dojo zu gründen. Wie man aus der Ankündigungsliste unschwer ableiten kann, ist es garnicht so schwer, ein .NET Coding Dojo zu gründen. Die gesamte Coding-Dojo-Community kann und wird euch dabei unterstützen mitzumachen. Die besten Anlaufstellen sind hier die Xing-Gruppe und die Facebook-Page! Sei dabei, mach mit, es lohnt sich!

Goto Dojo Considered Helpful!

Helfen ist schön, geholfen werden ist schöner!

Ich weiß es nicht genau, aber ich vermute es ein wenig, dass Thomas auch froh ist, wenn er durch Meinungsaustausch seine eigenen Herausforderungen besser einzuschätzen vermag. Ich persönlich empfinde diese „Kalibrierung“ als wichtigen Baustein zur Festigung der eigenen Meinung.

Thomas hat mit Null Verständnis gefragt, wie die Handhabung von NULL als Rückgabe von Methoden bei anderen Entwicklern umgesetzt und eingeschätzt wird. Viele haben kommentiert, einige haben auch Blog-Post-Antworten geschrieben. Ich habe das mit Kommentaren und dem Null Toleranz-Beitrag auch getan, der unermüdliche Ralf hat auch kräftig in die Tasten gehauen. Überraschenderweise mit mehreren Aussagen.

Ralf geht in seinem „Plädoyer für Regeln“ auch auf einige Punkte ein, die ich über die Handhabung von NULL in Anwendungsszenarien bemerkt hatte. Ralf hat so vieles geschrieben, dass es mir schwer fällt, wirklich alle Themen in einem oder mehreren Blog-Posts zu erwidern. Einen Überblick über meine Perspektive möchte ich dennoch geben.

Mind the Null!

Ralf stellt im Namen der Community die erste Null-Regel auf:

“Man darf Null benutzen und auch als Wert zurückgeben – aber Vorsicht! Erst prüfen, ob es nicht auch anders geht”

D’accord! Das hatte ich ja auch schon in Kommentaren und per Twitter erwähnt. Doch wann kann man Null verwenden, wann nicht? Gibt es dafür eine „kontextarme“ Regel? Kann man pauschal sagen: „Verwende es nicht!“. Meiner Meinung nach ist das nicht so einfach. Klar kann ich auch sagen, dass man Null einfach nicht anwenden soll, aber ich mache es mir nicht so einfach.

Wenn ich nämlich obige Regel einem Embedded-Entwickler entgegenbringe, dann lacht der mich mal gepflegt vor seinen Kollegen aus. In der Embedded-Entwicklung, wie auch bei sehr ressourcenintensiven Geschäftsanwendungen ist es nämlich durchaus erstrebenswert, oft NULL zurückzugeben, um damit z.B. eine leere Liste oder leere Suche zu signalisieren. Es mögen sich wenige daran erinnern, aber NIL (als Synonym für NULL) ist die Abkürzung für „Not-In-List“.

Null für Hacker

Ich selbst durfte schon mehrere serverseitige Komponenten von „Exception-Flut“ befreien, in dem ich sie in einigen Stellen durch NULL ersetzt habe. Danach lief der Service doppelt so schnell bei 25% weniger Ressourcenverbrauch. Bin ich jetzt ein Aussetziger, weil ich die Regel nicht befolgt habe?

Ich denke nein. Denn: In einigen Anwendungsszenarien ist es gang und gäbe NULL als Mittel einzusetzen. Mehr noch, es ist „normal“, soz. “die Regel”. Deswegen sage ich nach wie vor: Die Regel ist richtig, man sollte vorsichtig mit NULL umgehen und es mit bedacht einsetzen. Doch eine „Faustregel“ ist es für mich noch nicht, denn man kann es (noch) in bestimmten Anwendungsfällen vorteilhaft und stringent einsetzen.

CatastrophicFailureException ?? Null

Ralf schreibt:

„Null-Regel #2 (von Ilker; noch zu diskutieren): In Katastophenfällen darf Null zurükgegeben werden.“

Das ist keine Regel. Den Regelbedarf und die Kreativität zum Design eines Regelwerks wie Ralf habe ich (noch) nicht. Ich habe dafür aber Programme, die Probleme lösen. Bei einigen, wenigen Programmen habe ich NULL als Rückgabe für „katastrophale Fehler“ zurückgegeben.

Das hat mir bei der defensiven Programmierung geholfen, denn es ging um eine etwas kritischere Komponente, die an Schnittstellen sog. „Guards“ hatte, die alle möglichen Exceptions abgefangen haben. Im Nachhinein betrachtet hätte ich es wohl auch mit einer „CatastrophicFailureException“ oder mehreren, spezifischeren Exceptions lösen können. C’est ca!

Null nur bei „gleicher Kategorie“

Die dritte Regel von Ralf:

“Null darf nur Rückgabewert sein, wenn Null zur selben Kategorie gehört wie ein Nicht-Null Rückgabewert”.

Naja, streng genommen ist NULL ja nichts, und damit kann man es auch nicht kategorisieren. Antizipieren kann ich da nur, dass es um das Beispiel von Thomas mit der Liste gehen kann. Dem kann ich nur zustimmen. Hier ist ein Ausnahmefall zwar auch möglich, aber doch eher selten.

Dein Pflock ist mein Maibaum!

Ralf hatte mir zu viel “Rumgeeiere” in meinen Aussagen über NULL attestiert. Das will ich doch gerne versuchen besser zu machen und Ralf‘s „Pflock in Boden“ in meine triviale niederbayrische Welt übertragen und damit mal den „Maibaum ins Dorf“ stellen. Also, auf geht’s, Maderl & Buam – mein Maibaum im Dorf „Nullinger“!

Ilker’s Statement zu Null als Rückgabe von Methoden:

NULL ist gefährlich, meide NULL, außer es gibt triftige Gründe. Triftige Gründe können Performance, Speicher oder dynamische Datenstrukturen sein. Solltest Du NULL als „Indikator“ für etwas verwenden (z.B. „Nicht gefundener Benutzer“), ziehe eine Vermeidungsstrategie mit Exceptions oder ReturnCodes in Erwägung. Sei auf der Hut, NULL ist überall. Prüfe, ob deine Parameter oder deine Methoden NULL zurückgeben. Prüfe besonders, wenn Du parallelisierst oder wichtige Schnittstellen bedienst. Solltest Du ein NULL finden, versuche zunächst damit umzugehen. Geht das nicht mehr, signalisiere die Ausnahme. Achte darauf, dass ein NULL die Methode nicht verlässt.

So, ich hoffe das war konkret krass korrekt genug!

Immer diese Abhängigkeiten

Nachdem nun der Maibaum in Django Asül-Manier aufgestellt ist, möchte ich neben dem Ausgangsthema mich noch ein wenig den neuen Themen widmen, die Ralf in seinem Rules of Null-Post erwähnt hat. Ralf regt sich dabei ganz besonders über die „It depends“-Phrase auf. Ja, „It depends“, die allmächtige und einzige Antwort auf alles, was so im Leben an Fragen auf einen zukommen kann. Die Antwort „It depends“ ist kurz, erfüllt die Aufgabe und ist hochgradig flexibel bei gleichzeitig maximaler Wiederverwendbarkeit. Geradezu traumhafte Eigenschaften aus der „Nerd-Software-Entwickler“-Perspektive, oder nicht? Vielleicht ist es deshalb auch so beliebt in unserer Banche?

Spaß beiseite. „It depends“ ist eine Phrase, die mehr oder minder Inhalt liefern kann. Ich stimme Ralf zu, wenn er sagt, dass dieses „Es kommt drauf an“-Getue mit der Zeit nicht mehr auszuhalten ist. Deswegen kann ich die Reaktion von Ralf auch gut verstehen. Ich selbst finde es teilweise immer wieder erschreckend, wie oft auf diese Floskel zurückgegriffen wird, ohne darüber nachzudenken. Dennoch verwende ich es – ab und an zumindest, wenn ich es für erwähnenswert erachte.

Niemals ist niemals niemals

Fakt ist auch, dass „It depends“ nicht nur eine Bierdeckelweisheit ist, sondern auch als Abkürzung verwendet wird. Im Stile „ich erspare mir und Dir jetzt nähere Details“. Das kann gut und schlecht interpretiert werden. So oder so, es kommt darauf an :-) Genauer gesagt, auf den, der es interpretiert.

Womit wir bei der Quadratur des Kreises angelangt wären: Es ist nunmal so, dass wir Systeme vereinfachen und Abstraktionen schaffen, um es zu verstehen. Dabei geht auch Genauigkeit und Wahrheit verloren. Manchmal sogar so sehr, dass die aus der Vereinfachung abgeleitete Erkenntnis nicht mehr adequat bzw. erwartungsgerecht ist. Insofern ist „It depends“ nicht nur eine Fassade oder Ausrede, sondern eine zuweilen notwendige Mahnung, den Kontext und die Erkenntnis zu hinterfragen, sich bewußt mit der Lösung und Problemstellung auseinanderzusetzen. Für die Agilisten unter uns: „It depends“ ist ein auch ein Aufruf zum „Inspect & Adapt“.

Ich kann mich guten Gewissens Ralf anschließen, wenn es darum geht, Leitfäden und Empfehlungen über die Anwendung von NULL mit der Community zu erarbeiten. Meinungsaustausch ist Katalysator für Lernen, Entdecken, Erfahren und Bestätigen. Doch ein Regelwerk will ich nicht erstellen. Ich gebe meine Meinung und meinen Standpunkt gerne wieder. So wie ich es erfahren habe und so, wie ich es für gut empfinde.

Regeln habe ich auch. Ich habe meine eigenen Regeln, ich habe Teamregeln und ich habe noch eine Reihe weiterer Regeln, die ich für mich beachte und schätze. Regeln sind für mich wichtig. Ich möchte damit sagen, dass ich durchaus Ralfs Motivation nachvollziehen kann. Doch ich habe meine Beiträge nicht mit dieser Motivation mit der Community geteilt. Mein Ziel ist die Kommunikation und der Erfahrungsaustausch. Das wird auch so bleiben.

NSpec ist einer der ersten – wenn nicht sogar das erste explizite – BDD-Framework für .NET. Mittlerweile wird es auch nicht mehr aktiv betreut. “Schade”, denkt man sich auf der einen Seite. Andererseits jedoch nicht sooo schlimm. Schließlich war der Autor mit dieser “finalen” Version offensichtlich zufrieden. Überdies ist die NSpec-Basis auch in andere Test-Frameworks eingeflossen – dazu aber später mehr. Bleibt auch noch anzumerken, dass man NSpec und MSpec nicht miteinander verwechseln sollte. Die Frameworks unterscheiden sich massiv, obwohl die Namensähnlichkeit das nicht vermuten lässt. Auch MSpec wird in meiner kleinen Serie sicherlich in der Zukunft noch seinen Platz finden. Doch nun zurück zu NSpec (N wie Nordpol) :-).

Bei NSpec dreht sich, wie nicht anders zu erwarten war, alles um Spezifikationen. Ich werde hier nicht näher auf die Gemeinsamkeiten oder Unterschiede zwischen TDD und BDD eingehen, werde auch nicht groß ausholen, wie und wieso BDD entstanden ist. Es sei nur kurz angerissen, dass bei BDD nicht das “testen” im Vordergrund steht, sondern die Spezifizierung des Verhaltens – Behavior Driven Design eben. Abgesehen von der Terminologie ergeben sich weitere Unterschiede, die auch am Beispiel von NSpec feststellbar sind. Genug Vorgeplänkel, auf geht’s zum Test-Training mit dem FizzBuzz-Kata!

Der Ton macht die Musik – das Wort macht die Geschichte

Visual Studio öffnen, Projekt anlegen, Referenz hinzufügen, los geht’s! Äähhh… wohl doch nicht… wie schreibt man eigentlich Spezifikationen im Code? Also Finger wieder weg von der Tastatur und überlegen, um was es eigentlich geht. Ok, es geht um FizzBuzz. FizzBuzz ist ein Spiel mit Spielregeln – das ist es im Endeffekt, worum es hier geht. So eine Spielregel ist recht einfach, denn es gibt zu einer bestimmten Spielsituation – sagen wir mal zu einem bestimmten Kontext – immer eine Regel, die man anwenden muss, damit man weiter im Spiel bleibt. Anders ausgedrückt ist bei einer Spielsituation zu prüfen, ob die Regel richtig angewendet wird – ob also die Erwartungen an das Spielverhalten erfüllt werden.

Aha – so ist das also. Hört sich vielleicht etwas abgedreht an, aber dieses kurze Repetitorium hilft beim Schreiben der ersten Spezifikation ungemein. Denn NSpec kennt zwei Attribute, namentlich [Context] und [Specification]. Mit der kleinen o.g. FizzBuzz-Geschichte macht das auch Sinn, wie man dann auch im Code sehen kann:

using NSpec.Framework;

namespace FizzBuzzNSpec.Specs
{
    [Context]
    public class when_a_number_is_a_multiple_of_three
    {
        [Specification]
        public void then_translation_should_return_fizz()
        {
            Specify.That(game.Translate(6)).ShouldEqual("Fizz");
        }

        private readonly FizzBuzz game = new FizzBuzz();
    }
}

Anderes Framework, andere Sitten

Die Konsequenz dieser Verbalisierung und Strukturierung ist zunächst einmal eine verbesserte Lesbarkeit. Weiterhin fällt auf, dass es nicht mehr eine einzige “Testklasse” gibt, sondern 4 verschiedene Spezifikationsklassen. Für jede Spielregel eine. Das Stukturierungssystem ist zwar mit klassischen Test-Frameworks auch möglich, wird aber nicht so offensichtlich “verlangt” wie es das BDD-Test-Framework NSpec hier tut.

Den Code für die anderen Spielregeln spare ich mir – es sieht dem o.g. Beispiel sehr ähnlich :-). Hat man erst einmal das “sprechendere” schreiben der Tests bzw. Spezifikationen verinnerlicht, geht es mit NSpec auch zügig voran. Schade ist hier die fehlende Integration und Unterstützung für Visual Studio und die üblichen Code-Assistenten. Mir blieb also nichts anderes übrig, als in der Konsole meine Tests auszuführen. Das hat mich beim implementieren schon gebremst.

Bewertung

• Dauer
  Naja, knapp 15 Minuten für FizzBuzz ist doch schon dreimal länger als mit NUnit. Die mangelnde Integration und die 4 Klassen machen schon etwas aus.
• Größe
  Statt wie bei den “Klassikern” 4 Methoden sind es nun 4 Klassen. Schon etwas mehr Code – hält sich aber noch “in Grenzen”.
• Tooling
  Schlecht. Der Runner ist dabei – das war’s.
• Usability
  Geht so. Die Assertions mit Specify reichen für die gröbsten Fälle aus.
• Support
  Die Entwicklung von NSpec ist eingestellt. Support damit auch. Zukunftssicherheit ist etwas anderes.

NSpec for a taste of BDD

NSpec – ein Vorreiter im .NET-Bereich was BDD angeht. Man merkt dem Framework deutlich an, dass es ein “erster Wurf” von der Adaption der BDD-Methodik ist. Nichtsdestotrotz ist as Framework schlank, stabil und gut anwendbar. Es zeigt schon in der Anwendung, wie das “System BDD” die Herangehensweise an die Spezifikation und Verifikation von Code ändert. Man beschäftigt sich automatisch mehr mit Kernaussagen und ist “gezwungen”, sich deutlicher und expliziter in der Domänensprache zu artikulieren. NSpec kann diesen systematischen Aspekt transportieren, ist aber mittlerweile auf Grund der mangelnden Integration und des fehlenden Supports nicht mehr für “Real-World”-Projekte ernstzunehmen. Trotzdem hat mir der Ausflug mit NSpec Spaß gemacht. Da bekomme ich glatt Lust & Laune mir schon das nächste Framework anzuschauen. Stay tuned!

Der Pate unter den Test-Frameworks

So ist es auch nicht weiter erstaunlich, dass man nahezu überall, wo das Wörtchen “Test” fällt, auch “NUnit” zu sehen bekommt. Sei es nun bei den Codeassistenten, bei Build- oder CI-Tools, Addins und sogar weiteren Test-Frameworks. Die Verbreitung und Unterstützung von NUnit ist hier einfach nicht zu toppen. Aber auch die vielen Kontakte und Beziehungen des “Paten der Test-Frameworks” helfen nicht viel beim Meta-Test mit dem FizzBuzz-Kata! Auf geht’s!

Der Code

FizzBuzz ist mit NUnit und den “Standard-TDD-Regeln” schnell implementiert. Referenz hinzufügen, Testklasse inklusive Testmethode aufbauen, noch schnell ein using NUnit.Framework; und die beiden Attribute [TestFixture] (für Klassen) sowie [Test] hinzugefügt – und schon kann man fröhlich testen!

Wer jetzt einen Codeassistenten wie Resharper oder Coderush hat, ist praktisch nur ein Klick bzw. Tastenschlag von der Testausführung entfernt. Doch auch ohne “Code-Beschleuniger” gehen NUnit-Tests elegant, z.B. mit dem TestDriven.NET Addin. Mal von diesen “Integrationstüren” abgesehen, bietet NUnit auch eigenständige Runner für die Konsole sowie auch als Windows-Anwendung an. Passt!

using NUnit.Framework;

namespace KataFizzBuzzNUnit
{
    [TestFixture]
    public class FizzBuzzTest
    {
        private FizzBuzz target = new FizzBuzz();

        [Test]
        public void Multiples_Of_Three_Returns_Fizz()
        {
            Assert.That(target.Translate(6), Is.EqualTo("Fizz"));
        }

        [Test]
        public void Multiples_Of_Five_Returns_Buzz()
        {
            Assert.That(target.Translate(10), Is.EqualTo("Buzz"));
        }

        [Test]
        public void Multiples_Of_Three_And_Five_Returns_FizzBuzz()
        {
            Assert.That(target.Translate(15), Is.EqualTo("FizzBuzz"));
        }

        [Test]
        public void No_Multiples_Of_Three_Or_Five_Returns_Number()
        {
            Assert.That(target.Translate(7), Is.EqualTo("7"));
        }
    }
}

Bei der Implementierung fühlt man sich schon fast wie bei MS-Test, jedoch mit einem ganz gewaltigen Unterschied: Die Assert-Klasse im Allgemeinen sowie die Assert.That() Syntax von NUnit sind mächtig – und mächtig hilfreich. Das mit NUnit 2.4 eingeführte Constraint Model ist nicht nur besser lesbar, sondern auch intuitiver. Kennt man mal die wichtigsten Constraints, vergisst man sie auch nicht mehr so schnell. Alles in Allem ist TDD mit NUnit eine runde Sache. In weniger als 5 Minuten strahlten meine 4 Tests und ich uns gegenseitig an.

Bewertung

• Dauer
  Zackig, Knackig, ohne Trärä und Tamtam. FizzBuzz-Regeln in 5 Minuten. Mit Codebeschleuniger geht’s sogar noch schneller. Passt.
• Größe
  Ähnlich wie bei MS-Test. Eine kompakte Testklasse mit 4 Testmethoden.
• Tooling
  MS-Test war schon sehr gut – doch NUnit ist sogar noch besser! Die Verbreitung in der OSS-Gemeinde macht sich hier bemerkbar. Top.
• Usability
  Sehr gut. Assert’s schön mit Constraints. Wenn man möchte sogar noch beschleunigt über das Erben von AssertionHelper. Angenehm.
• Support
  Unmengen an Material im Internet. Open-Source, stabil, große Gemeinde, aktive Entwicklung. Zufrieden.

Hmm, es fällt mir schon schwer, etwas “negatives” an NUnit zu finden. Es mag den einen oder anderen stören, wie die Test-Projekt-Struktur von NUnit aufgebaut ist. Auch der GUI-Runner ist jetzt nicht der Augenschmaus schlechthin. Doch die Kernkompetenzen werden von NUnit bravourös gemeistert.

NUnit – Die Referenz

Als kleines Fazit kann ich für mich schon mal sagen – NUnit hat die Messlatte ganz schön hochgelegt. Effektiv betrachtet ist NUnit als Test-Framework derzeit die Referenz, mit der sich alle anderen messen lassen müssen. Das ist auch gut so, denn NUnit ist durch die jahrelange, stetige Entwicklung viele Schritte gegangen – manchmal auch einige Schritte voraus. Bleibt die Frage offen: Gibt es noch bessere Test-Frameworks für C# und .NET als NUnit? Abwarten, meine Test-Serie geht in Kürze weiter. Stay tuned!

Los geht’s mit Projekten

Aber zurück zur Sache. Es muss ja schließlich das mittlerweile mehr als bekannte FizzBuzz-Kata als Fingerübung implementiert werden.

Da tut sich schon interessantes am Anfang auf: Durch die nahtlose Integration in Visual Studio fügt man keine Referenz auf irgendeine Framework-DLL hinzu, sondern startet die Tests mit der Erstellung eines Testprojektes. Für mich persönlich ein wenig gewöhnungsbedürftig – ich schreibe man Tests und Code für gewöhnlich in der selben Assembly und lagere es nur auf ausdrücklichen Wunsch aus.

Nach Abschluß der durch den (eigentlich um die Arbeit zu beschleunigen konzipierten) Projekt-Wizard durchgeführten Vorbereitungen und der manuellen Abschlussvorbereitungen kann es nun endlich losgehen.

Straight-Forward mit Attributen und Asserts

Die Test-Methoden gehen schnell von der Hand, man braucht nur das [TestMethod] Attribut hinzufügen. Die Assert-Klasse deckt alle notwendigen Prüfungen ab, bietet aber im Vergleich zu anderen Frameworks wie z.B. NUnit wesentlich weniger “methodische Expressivität”. In unserem Fall brauchen wir nur die AreEqual-Methode. Schon nach dem ersten Test fällt allerdings die lange Testdauer des Testrunners ein wenig negativ auf. Das kann auch wesentlich schneller gehen.

Das Test-Ergebnis sieht relativ unspektakulär aus:

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace FizzBuzzMSTest
{
    [TestClass]
    public class FizzBuzzTest
    {
        [TestMethod]
        public void Multiples_Of_Three_Returns_Fizz()
        {
            FizzBuzz target = new FizzBuzz();
            string translation = target.Translate(6);
            Assert.AreEqual("Fizz", translation);
        }

        [TestMethod]
        public void Multiples_Of_Five_Returns_Buzz()
        {
            FizzBuzz target = new FizzBuzz();
            string translation = target.Translate(10);
            Assert.AreEqual("Buzz", translation);
        }

        [TestMethod]
        public void Multiples_Of_Three_And_Five_Returns_FizzBuzz()
        {
            FizzBuzz target = new FizzBuzz();
            string translation = target.Translate(15);
            Assert.AreEqual("FizzBuzz", translation);
        }

        [TestMethod]
        public void No_Multiples_Of_Three_Or_Five_Returns_Number()
        {
            FizzBuzz target = new FizzBuzz();
            string translation = target.Translate(7);
            Assert.AreEqual("7", translation);
        }
    }
}

Bewertung

• Dauer
  Die FizzBuzz-Implementierung ging relativ zügig von der Hand. Ich habe ca. 15 Minuten gebraucht. Der “lahme” Testrunner hat mich etwas gestört. Die meiste Zeit ging für das Projekt, die Referenzverweise und das hin und her zwischen den Projekten drauf.
• Größe
  Die Testgröße ist überschaubar. Eine kompakte Testklasse mit 4 Testmethoden. Eine klassische Class-Per-Class Struktur. Das Testprojekt ist isoliert vom Code.
• Tooling
  Ein regelrechtes Heimspiel mit der VS-Integration. Auch Code-Assistenten wie Resharper oder Coderush kennen den MSTest. Alles in Allem eine sehr gute Unterstützung.
• Usability
  Durch den Projekt-Wizard und die entsprechende Dokumentation komfortabel für allgemeines Testing. Speziell für TDD/BDD allerdings etwas hakelig. Immer gleich die Test/Code-Separation. Die Asserts sind sicherlich ausreichend.
• Support
  Was soll man hier schreiben, außer MS? Das Framework wird direkt von Microsoft mit Visual Studio ausgeliefert. Die Dokumentation ist gut, Online-Material ist sicherlich vorhanden. MSTest ist in der Community (vor allem für Open Source oder kleinere Projekte) nicht so weit verbreitet wie andere Frameworks.

MS-Test ist ein solides Framework, mit dem sich sicherlich auch gut TDD betreiben lässt. Man merkt dem Featureset an, dass es nicht nur für Unit-Testing ausgelegt ist. Der integrierte Runner ist schick, das Reporting ein Highlight. Ich sollte nicht unerwähnt lassen, dass vor Allem die Kombination TFS/MSTest ein sehr gutes Reporting/Monitoring-Werkzeug darstellt.

Zu den Tests selbst gibt das Framework wenig Hilfestellung bzw. Guidance zur Strukturierung und Anwendung der Tests. So wird wohl am meisten die Class-Per-Class Struktur angewendet werden, mit den üblichen TDD Best Practices.

MS-Test leider nur für “Profis”

Ein absolutes Manko ist die nicht-freie Verfügbarkeit des Frameworks und damit auch das Fehlen des Features in der Express-Edition. Einfach mal Tests/Code schreiben und veröffentlichen ist somit unmöglich. Für bekennende TDDler ein No-Go. Mit den 15 Minuten Fizzbuzz ist die Umsetzungsgeschwindigkeit in Ordnung – wobei ich zugegebenermaßen Fizzbuzz auch schon wesentlich zügiger implementiert habe. Das bringt mich dann auch zum nächsten Test-Framework unter meiner Meta-Test-Lupe… stay tuned!

Ein Bereich, den ich mir dabei näher angeschaut habe ist das Tooling. Ich wurde in der Vergangenheit schon öfters gefragt, welches Test-Framework ich denn einsetze. In letzter Zeit werde ich aber auch ab und an gefragt, welches Test-Framework denn jetzt besser sei. Als Hilfestellung zur Findung einer Antwort auf diese Fragen sowie einen Überblick über die gängigsten Test Frameworks soll dieser Artikel beitragen.

Die Kandidaten

Mit diesem Artikel beginnt die kleine Blog-Serie “Meta-Test”, die Stück für Stück die populärsten Test-Frameworks für .NET und C# unter die Lupe nimmt, sie bewertet und natürlich auch vergleichen wird. Bisher gab es schon folgende Tests:

• MS Test – Visual Studio On Board Test-Framework
• NUnit – All-Time-Hall-Of-Fame-Most-Valueable-Tester
• NSpec – der spezifizierende BDD-Veteran

Die Hypothese

Vorab möchte ich allerdings noch eine – für mich wichtige – Anmerkung äußern. Beim Test der Testframeworks habe ich mehrere Code Kata’s mit allen Frameworks geschrieben. Am häufigsten habe ich wohl FizzBuzz geschrieben, gefolgt von Replacer, LineCounter und ein paar Mal Minesweeper. Ich habe dabei schon deutliche Unterschiede nicht nur in den Frameworks, sondern auch in der Adaption selbst festgestellt. Für den hier gezeigten Vergleich gelten folgende Hypothesen:

• TDD & BDD sind gleichwertig.
• TDD & BDD sind prinzipiell das Gleiche, mit Unterschieden in Benennung und Teststruktur
• TDD & BDD wendet man für die selbe Aufgabe an, zum Software-Design

So, und jetzt der Disclaimer:
Achtung: Die genannten Hypothesen sind nicht meine Meinung über TDD bzw. BDD!

Ganz im Gegenteil. Ich habe zu TDD ein gefestigtes Meinungsbild. Ich habe auch Erfahrung mit BDD. Gerade deswegen bin ich sehr vorsichtig mit beiden Begriffen. Ich denke, TDD und BDD sind nicht das Gleiche. Doch eine weitere Vertiefung in das Thema lenkt nur von den Frameworks ab. Deswegen wieder schnell zurück zu den Test-Frameworks.

Die Anforderungen

Als Entwickler möchte man ein möglichst effektives und intuitives Test-Framework als Werkzeug, um testgestriebenes Softwaredesign durchzuführen. Beim programmieren mit Visual Studio zum Beispiel, wenn man die Tests für die gerade zu entwickelnde Klasse oder Methode formuliert, da gehört die Unterstützung von Tools wie Resharper, CodeRush oder Gallio heutzutage schon zum guten Ton.

Ebenso geht es bei dem Vergleich um die Anwendbarkeit und Effizienz. Also wie expressiv, wie deutlich kann ich meine Tests formulieren und wie intuitiv ist die Umsetzung der Tests. Die Umsetzungsgeschwindigkeit spielt dabei genauso eine Rolle wie die Lesbarkeit, Wartbarkeit und gutes Reporting. Dazu noch später mehr.

Das Ziel

Um auch eine konkrete, relativ faire Vergleichssituation zu erreichen, stelle ich alle Frameworks an einem einzigen Beispiel vor, nämlich dem KataFizzBuzz. FizzBuzz ist eine sehr einfache Kata, die gerade genug “Widerstand” bietet, um die Grundzüge des treibenden Software-Designs sowie des Test-First zu vermitteln. Ich habe mich bei der Programmierung der Kata sogar nur auf das Teilproblem der “Fizz”- und “Buzz”-Übersetzung konzentriert. Es gibt unzählige Implementierungen von FizzBuzz. Bei dem Vergleich der Test-Frameworks habe ich mich für die “triviale” und “zügige” Implementierung entschlossen. Konkretisiert bedeutet dies, das es mein Test-Ziel war, das ich mit allen Test-Frameworks ungefähr folgenden Code produziere:

    public class FizzBuzz
    {
        public string Translate(int number)
        {
            if (number % 15 == 0)
                return "FizzBuzz";

            if (number % 5 == 0)
                return "Buzz";

            if (number % 3 == 0)
                return "Fizz";

            return number.ToString();
        }
    }

Die Metriken

Um nun die einzelnen Frameworks untereinander vergleichen zu können, braucht es nicht nur einer gemeinsamen Basis & Ziels, sondern auch einer gemeinsamen Messmetrik. Um es nicht zu theoretisch zu gestalten, habe ich einige ganz einfache, aber wie ich finde dennoch aussagekräftige Metriken ausgewählt:

• Die Dauer der Implementierung
• Die Größe der Test-Artefakte (Klassen usw.)
• Das Tooling, also die Unterstützung durch VS / Frameworks / Codetools
• Die Usability, also handbuchnachschlagefreie Handhabung der API / Tools
• Der Support durch Hersteller, Community und User

Doch die wichtigste Metirk ist mit Abstand die Bewertung des Ergebnisses der Test-Frameworks – also der Tests ansich. Die Tests werden unter die vier Grundmerkmale Intuitivität, Expressivität, Lesbarkeit und Wartbarkeit gestellt. Natürlich bleibt da meine eigene subjektive Note an der ein oder anderen Stelle hängen, schließlich habe ich die Frameworks eigenständig getestet und habe auch keinen Anspruch auf gestelzte Objektivität :-).

So, damit sollten die Vorbereitungen und Rahmenbedinungen für den ultimativen Vergleich der Test-Frameworks für das .NET Framework & C# abgeschlossen sein. Dieser gigantische Vergleich von einer Unmenge an Test-Frameworks – für den ich keine Kosten und Mühen gescheut habe :-) – wird als Blog-Post-Serie in den nächsten Tagen veröffentlicht.

Stay tuned!

Antwort zu: Scrum kennt keine technischen Verfahren

Boris Gloger schreibt: “Scrums primärer Zweck war und ist, Teams, Abteilungen und Firmen zu unterstützen, mit den Prinzipien von eigenständigen Arbeitsteams ihre Aufgaben zu bewältigen. Es war niemals geplant, Entwicklern beizubringen, wie man entwickelt. Wenn man Scrum implementiert, dann erkennt man schnell, dass die Entwickler nicht mit der Arbeitsweise von Agile vertraut sind.”

Ich habe Scrum als agiles Software-Management-Framework kennengelernt. Spezifisch für die Domäne der Software-Entwicklung. Scrum ist kein Selbstorganisatios-Framework. Nicht umsonst ist Scrum ein Vertreter der agilen Software-Entwicklungs-Verfahren, und nicht ein “Autonomie-Team-Modell”. Insofern kann man einem agilen Software-Management-Verfahren schon abverlangen, die Software-Entwicklung als Domäne zu unterstützen und zu fördern.

Antwort zu: Scrum hat zu lange Sprints

Boris Gloger schreibt: “Es wurde NIEMALS ausdrücklich gesagt, dass ein Sprint 30 Tage lang sein muss, sondern es war nur als Vorschlag gemeint. Ken und Jeff machten vor 15 Jahren mit den 30 Tagen große Fortschritte. Nicht mehr und nicht weniger. Sprints sollten so lange sein, wie es das Team und der PO für nötig halten und 2 Wochen werden oftmals vorgeschlagen. Allerdings verkompliziert sich dadurch die Sache für die meisten Entwickler.”

Das schöne an agilen Verfahren ist das Inspect & Adapt. Wenn etwas nicht mehr zeitgemäß ist, oder vielleicht nicht in den Kontext hineinpasst, dann wird es eben verändert. So auch mit der Sprintdauer. Für mich ist es offensichtlich, dass kürzere Sprints deutliche Vorteile bieten – auch bzw. gerade für Entwickler. Eine “Verkomplizierung” sehe ich da nicht.

Antwort zu: ScrumMaster aka Projektmanager

Boris Gloger schreibt: “Der ScrumMaster ist eine neue Führungsrolle. Ken hat dies vor Jahren geschrieben und für die ersten Scrum Experten, wie mich, war dies klar verständlich. Jedoch wollte dies die gesamte Agile Gemeinschaft nicht anerkennen, da es ihrem Verständnis nach nicht nötig war, dass Teams eine Führungskraft benötigen und Scrum eine neue Führungsrolle einnimmt. Ein ScrumMaster ist weder ein PM, noch ein Master des Teams. Er ist der Master innerhalb des Bezugssystems des Prozesses. Er ist der Leiter des Teams und der PO und es ist seine Aufgabe, die Organisation mittels Scrum zu verändern und Scrum als ein Paket von Tools und Grundwerten einzusetzen.”

Mit Nichten. Ich habe in meinen bescheidenen paar Jahren, in denen ich mich Scrum auseinandergesetzt habe und immer noch intensiv beschäftige den ScrumMaster niemals als Führungsrolle verstanden. Ja, es gibt das Prinzip des Servant Leaderships für einen ScrumMaster. Ja, der ScrumMaster ist der Hüter des Scrum-Grals. Ja, der ScrumMaster ist ein Change Agent. Aber Nein, der ScrumMaster ist kein Team-Leiter. Nein, es gibt keine Position “ScrumMaster” in einem Organigramm, sondern die Rolle ScrumMaster. Nein, der ScrumMaster ist kein Entwicklungs-Alpha-Tier.

Antwort zu: ScrumMaster ist kein Leader

Boris Gloger schreibt: “Ein Entwickler hat nicht die Fähigkeiten ein Team zu leiten, eine Organisation zu ändern und sein Team vor der herkömmlichen Organisationskultur zu beschützen. In dieser Hinsicht wird die Rolle des ScrumMasters großteils missverstanden. Er ist ein Moderator, aber das ist Teil seiner Führungsrolle als ScrumMaster. Ein ScrumMaster zu sein, das bedeutet, sich ein Set and Fähigkeiten anzueignen, die erlernt und geübt werden müssen. Dies kann 10000 Stunden in Anspruch nehmen, bevor man davon ausgehen kann, dass man diese Disziplin auch beherrscht.”

Mit Verlaub, Herr Gloger, das geht zu weit. Es tut mir leid Ihnen entgegnen zu müssen, dass Ihre Auffassung für mich nichts anderes als protektionistischer Mumpitz ist! Sie haben gerade die Entwickler, also mich, meine Kollegen und meine gesamte Berufszunft gekränkt. Was fällt Ihnen ein, sich so herablassend über einen Entwickler und seine Fähigkeiten zu äußern? Zugegeben, nicht jeder Entwickler hat das Zeug zum Teamleiter. Nicht jeder Entwickler kann sich eloquent und zielsicher vor Führungsriege oder Investoren artikulieren.

Doch das heisst noch lange nicht, dass alle Entwickler per se nicht geeignet sind, die Rolle des ScrumMasters zu übernehmen. Sie tun mit Ihrer Aussage den vielen Entwicklern da draussen Unrecht, die tagtäglich lernen, die versuchen ihre Entwicklung und ihre Organisation zu verbessern, die ihre Teams und Kollegen leiten. Ja genau, die Entwickler, die sogar auf Kurse von ScrumCoaches wie Ihnen gehen, um das System Scrum sowie die Rolle ScrumMaster zu verstehen und sich dafür zu zertifizieren.

Ihr Verständnis des ScrumMasters als “allwissende, allmächtige” Instanz kann ich nicht teilen. Sie beschreiben den ScrumMaster ja geradezu als den Robin Hood der Scrum-Gemeinde, der sich für die armen bekehrten Entwickler einsetzt und sich mutig und stark vor die etablierte, elitäre Wasserfall-Adelschaft stellt. Nein, Herr Gloger. Sowohl die klassische als auch moderne Software-Entwicklung ist erfolgreich mit Teamgeist, dem verständnisvollen & respektvollen Umgang miteinander und dem gemeinsamen Verständnis für das Ziel. Allesamt Eigenschaften, die ich in Ihrer Aussage kläglich vermisse.

Antwort zu: Mangelhafte Struktur des Backlogs

Boris Gloger schreibt: “Mike Cohn hat uns das beigebracht und ich habe es in meinem Buch beschrieben. Scrum war nicht als ein Set von Tools geplant, das alles beschreiben kann. Der Backlog ist sehr unternehmens-/team-/produktspezifisch und Scrum kann in dieser Hinsicht keine Anleitungen liefern. Nur Best Practises können das.”

Richtig. Zumindest was die Strukturierung des Backlogs angeht, bin ich der Meinung dass dies sehr stark von Projekt zu Projekt variieren kann. Genau hier ist es gut, eine allgemeine, flexible Aussage zu liefern, die da heißt: Es muss ein Backlog geben. Wie das dann aussieht, bleibt im Ermessen der Projektbeteiligten, spezifischer des PO’s und des Teams. Es ist etwas ganz anderes, ein Backlog für ein Webportal aufzubauen als ein Backlog für ein kritisches Leitsystem. Best Practices können da einen guten Leitfaden darstellen.

Antwort zu: Scrum skaliert nicht

Boris Gloger schreibt: “Ich kann euch versichern, dass Scrum auch auf Ebenen oberhalb eines Teams erwiesenermaßen angewendet werden kann. Ich habe dies hunderte Male erfolgreich durchgeführt. Scrum Anwender wie ich haben Möglichkeiten entwickelt, Scrum in Organisationen einzusetzen, genauso wie auf Unternehmensebene. Gut, es wurde nicht in Ken’s erstem Buch beschrieben und viele Scrum Consultants haben keine Ahnung, wie das gemacht werden kann. Wenn ihr euch allerdings an Leute wendet, die Scrum seit 2003 einsetzen und Scrum auf Unternehmensebene angewandt haben, dann könnt ihr erfahren, wie das geht. Zu diesen Leuten gehören: Bas Voode, Mike Cohn, Stacia Broderick, Boris Gloger, Andreas Schliep, und viele mehr. Wie gesagt, man kann dazu nichts in den frühen Büchern finden, sondern in den Köpfen der Leute, die das bereits mehrmals gemacht haben.”

Eine für mein Dafürhalten argumentativ etwas schwachbrüstige Aussage. Mit irgendwelchen Mitteln, ein paar “Scrum Of Scrums”, einem Company Backlog und ein paar Chief Product Owners ist die Skalierungsaufgabe “Scrum” noch lange nicht gelöst. Wenn es funktioniert, ist es gut. Doch die Aussage bezieht sich auf Scrum als Rahmen- und Richtwerk. Dort ist von Skalierung nicht die Rede. Man muss auch mal zugeben können das Scrum einfach nicht für größere Konstrukte “designed” wurde.

Embrace Change!

Alles in Allem interpretiere ich den offenen Brief mit kritischen Augen. Irgendwie kommt es mir so vor, als ob sich in dem Brief das “Ministerium für Scrum” gemeldet hat und ein paar Statements in den Raum wirft, um Scrum als System sowie auch das Ministerium selbst zu schützen. Scrum ist unbestritten ein hilfreiches agiles Management-Werkzeug. Scrum hat in der agilen Bewegung auch zweifelsohne große Beiträge geleistet. Dennoch ist dies kein Grund, konstruktiver Kritik mit derartig pauschalisierten Floskeln zu entgegnen.

Ich glaube an die Vorteile von Scrum, erkenne aber auch Gefahren und Schwachstellen. Alles hat seine Vor- und Nachteile. Wichtig ist für mich der “Agile Spirit”, der im agilen Manifest und vielen agilen Best Practices verankert ist. Inspect & Adapt, Embrace Change, People over Processes, Collaborate. All das sind die essentiellen Werte agiler Software-Entwicklung – und auch von Scrum.

In vielen Fachblättern und Artikeln wird eine Sprintdauer von 30 Tagen (4 Wochen) vorgeschlagen. Manchmal findet man auch 2-4 Wochen als empfohlene Sprintdauer. In jedem Fall aber sollte die Sprintdauer stabil über Sprints hinweg bleiben.

Mein Einwand: Die Sprintdauer ist eine Schwachstelle in Scrum. Besser gesagt: lange Sprintzyklen sind eine Gefahrenquelle für den Erfolg von Scrum-Teams. Denn gerade lange Sprintzyklen sind für die meisten Teams der erste große Fallstrick. Die meisten Teams, die mit Scrum beginnen, fangen mit langen Sprints von 4 Wochen und z.T. sogar mehr an. Schwierig in mehrfacher Hinsicht, denn dadurch berauben sie sich eigenmächtig der Vorteile agiler Verfahren. Die Flexibilität wird eingeschränkt, die Feedbackschleife des Inspect & Adapt wird verlängert und dem Team wird hohe Planungskompetenz bzw. -verantwortung aufgebürdet.

Was kann man tun um diesen Risiken entgegenzuwirken? Ganz einfach: Kurze Sprints! Mit kurzen Sprints meine ich auch kurze Sprints. Aus meiner Sicht ist die ideale Sprintdauer eine Woche lang. Ja, richtig gelesen, nur 5 Werktage! Jede Woche Planung, jede Woche Review, jede Woche Retro.

Daily Scrum, Weekly Sprint

Was erreicht man dadurch? Zunächst einmal schafft man durch so eine kurze Sprintdauer eine hohe Planungsfrequenz. Das ist für fast alle Beteiligten nur von Vorteil. Der PO hat hohe Flexibilität, während das Team einen sehr überschaubaren Planungszeitraum hat. Das Team geht genauer auf die Stories und das Design ein, bricht in der Planung genauer Tasks auf. Dadurch ergeben sich quasi automatisch verbesserte Schätzung und stabiles Commitment. Das wiederum stärkt die Vorausplanung und Releaseabstimmung auf der Product Owner-Seite.

Ein-Wochen-Sprints bedeuten aber auch schnelleres Inspect & Adapt. Jede Woche gibt es eine Retrospektive, das wichtigste agile Gremium in Scrum. Jede Woche eine Retrospektive zu haben ist ein wenig wie “und wöchentlich grüßt das Scrumeltier” – es kommen Anfangs immer wieder die gleichen Themen ins Gespräch. Das liegt vor Allem daran, dass es viel einfacher ist, wöchentlich “inspect” zu betreiben, als effektiv “adapt” durchzuführen. Doch genau das ist das schöne am schnellen, wöchentlichen Sprint-Puls. Es wird die Agilität förmlich “antrainiert”. Das Team lernt wesentlich schneller, wirklich zu adaptieren, anstatt es irgendwie auf die lange Bank zu schieben.

“Accelerate” für eine gute “Velocity”

Ein nicht ganz auf den ersten Blick erkennbarer Vorteil der Wochensprints ist der schnelle “Ramp-up” des Teams zur stabilen Velocity. Während ein Team mit 4-Wochen-Sprints nach den ersten 3-5 Sprints (also nach 3-5 Monaten!) erst so halbwegs stabile Produktivität und Schätzkompetenz aufweisen kann, gelingt einem Team mit Wochensprints nach der gleichen Sprintzahl (also nach 3-5 Wochen) noch mehr. Ergo: Ein zügiges Teaming wird erreicht.

Gerade Wochensprints haben meiner Meinung nach die Bezeichnung “Sprint” verdient. Denn wöchentliche Iterationen “fühlen” sich nicht nur wie ein Sprint an, sondern sind auch so intensiv und ergiebig wie ein Sprint. Das liegt nicht nur am höheren Takt, sondern auch an einer ganz lapidaren Tatsache: Die Arbeitswoche.

Unsere gesamte Lebens- und Arbeitskultur tickt in diesem “Wochentakt”. Viele denken, planen und organisieren in Wochenzyklen. Das kommt auch dem wöchentlichen Scrumsprint zu Gute. Teams mit Wochensprints kommen mit dem Wochentakt “einfach besser zurecht” – wissentlich oder unwissentlich. Höchstwahrscheinlich ist dies dem Fakt geschuldet, dass die gesamte Arbeitswelt sich an diesem Takt orientiert. Egal ob nun Scrum oder nicht, die Kalenderwoche ist und bleibt eine präsente Zeiteinheit, die für Planung, Vereinbarung und Organisation angewendet wird.

Kurz und Knackig

Bei all den Vorteilen, die eine kurze, nach meinem Ermessen am Besten wöchentliche Sprintdauer hat – es gibt auch hier wieder einige Dinge, die man vor der Einführung oder beim “Sprinten” beachten sollte. Ein allgemeiner Fallstrick kann es werden, die Planung des Sprints auf den Montag zu legen, und die Retrospektive auf den Freitag. So wie es bei klassischen Jour-Fixe Meetings zum guten Ton gehört Planungsgespräche an das Ende der Woche zu legen, ist das bei Wochensprints auch förderlich. Eine mögliche Variante wäre es, die Planung auf den Freitag zu legen und Review/Retro auf Montag.

Damit ist der nächste Achtungspunkt schon implizit genannt: Nicht versuchen, alle “Scrum-Meetings” in einen Tag zu quetschen. Ganz im Gegenteil, die Planung kann Freitag vormittags erfolgen. Der Nachmittag ist reserviert für Konzentrationsarbeit, Tageskommunikation, Vorbereitung des Boards und des Reviews / Retro’s.

Montag ist vormittags “Tabu” – denn genau dann befindet man sich in der “Twilight Zone”. Ende des letzten Sprints oder Anfang des nächsten Sprints – schon durch die Planung oder noch im Review – noch Montagsmüde oder schon im Tatendrang – ein Montag Morgen eben. Der späte Nachmittag kann dann nach dem üblichen Daily für die kurze Review/Retro investiert werden. Bei Wochensprints ist eine 4 stündige Planung angemessen, eine Review/Retro von einer Stundes komfortabel ausreichend.

Fazit: Kurz & Knackig – das ist die bessere Sprintdauer in Scrum!
Es gibt natürlich noch mehr Aspekte als die aufgeführten, um zu einer ausgewogenen Sprintdauer für sein Team zu kommen. Für mich bleibt jedoch die in den meisten Fällen zutreffende Erkenntnis: Kurz & Knackig ist besser als Lang & Weilig. Was denken Sie? Ihre Meinung ist gefragt!

Massiv Sportlich

Schon das letzte Münchener .NET Coding Dojo im Februar war wieder eine spannende und anregend erkenntnisreiche Veranstaltung. Das Lösen des KataTennis hat sich als eine wunderbare Übung für den überlegten, soz. “wohl bedachten” einsatz von Test-Driven-Design und -Development herausgestellt.

TDD kann viel im Design und in der Implementierung bewirken. Es fördert lose Kopplung, gestaltet aktiv die Trennung der Verantwortlichkeiten mit und unterstützt das minimalistische “DRY“-Denken. Es gibt auch frequentiven Feedback in der Entwicklung. Sei es nun, dass man sich auf dem grünen Pfad bestätigt fühlt – oder aber frühzeitig “riecht”, das da etwas nicht ganz ausgereift ist. In jedem Fall war KataTennis im Februar-Dojo eine schöne Aufgabe, die all diese Faktoren präsentierte. Mehr noch, das Dojo zeigte, dass es sich lohnt, die Analyse der Problemdomäne nicht außer Acht zu lassen. Der Code lässt sich wie immer auf dem Codeplex-Projekt einsehen.

Massiv Interessant

Doch das war noch lange nicht alles, was sich zum Thema .NET Coding Dojo im Februar getan hat! Vorreiter war schon im Januar die .NET User Group Karlsruhe mit einem .NET Coding Dojo der “Schwarzgurt-Klasse”. Es wurde KataPotter angegriffen. Die DNUG hat gespürt, dass ein Coding Dojo schweißtreibend ist – aber auch spannend und fesselnd. Denn schon einen Monat später gab es in professionell agiler Manier eine Retrospektive zum Coding Dojo. Die DNUG Karlsruhe bleibt also am Ball!

Auch ich konnte noch einen kleinen Beitrag zur Coding Dojo Idee leisten, in dem ich auf der diesjährigen VSOne das Format und die Ziele des .NET Coding Dojo vorgestellt habe. Doch bei der Vorstellung alleine bleibt es bei Dojojanern natürlich nicht – in der Session wurde demonstrativ ein “Mini-Dojo” mit KataFizzBuzz gestartet. Es war eine wunderbare Erfahrung, wie interessiert und motiviert unvoreingenommene Teilnehmer im Coding Dojo mitmachen. Danke für das zahlreiche Interesse!

Im Übrigen möchte ich dabei noch betonen, dass die diesjährige VSOne eine wirklich gelungene und qualitative Veranstaltung gewesen ist.

Last but not least: Die .NET Coding Dojo-Idee ist grenzübergreifend! Angespornt und motiviert durch die Events in Deutschland gab es im Februar auch ein eigenständig von Andreas organisiertes .NET Coding Dojo in Wien! Es wird also auch schon in Österreich kräftig trainiert. Kurzum: Massiv Interessant!

Massiv Im März

Natürlich steht auch schon das nächste Münchener .NET Coding Dojo vor der Tür. Am 10. März erwartet die Teilnehmer ein Coding Dojo der Extra-Klasse. Im März-Dojo werden die gebündelten Kräfte und Kompetenzen von .NET Enthusiasten, Software-Entwicklern & TDD-Interessierten gebraucht. Soviel sei schon vorab verraten: dieser Coding Dojo wird eine Herausforderung!

Im “Massiv-Im-März” Coding Dojo werden wir drei spannende Code Kata’s im Angebot haben, die wieder besondere Techniken sowie Praktiken fordern und fördern. Es geht dabei um Analyse, Design und Implementierung gangbarer, nachhaltiger, effektiver Lösungen zu einem kleinen Programmierproblem. Kurzum: Gemeinsam lernen & lehren von profesioneller Software-Entwicklung mit TDD, CCD und Design Patterns.

Was heißt das? Ganz einfach – auf geht’s zum Dojo! Anmeldung per Xing Event oder Facebook Event!

Übrigens, ein schöner Zufall will es, dass das Münchener .NET Coding Dojo parallel zu den Tagen des dotnetpro.powerday stattfindet. Wer es noch nicht weiß, in den dotnetpro.powerday zeigen Ralf & Stefan auf Ihre gewohnt einprägsame Weise, welche Werte, Prinzipien & Praktiken es bedarf, um nachhaltigen, wartbaren und erweiterbaren – also Clean Code zu schreiben. Die frisch gewonnen Erkenntnisse kann man dann natürlich bei uns im Coding Dojo einsetzen! :-)

Und das erste Münchener .NET Coding Dojo des Jahres startete wahrhaftig mit einem Paukenschlag! Erstmals überstieg die Teilnehmerzahl den Rahmen einer Dojo Session, so dass wir zwei Teams machen mussten (und wollten), die gegeneinander in einem “Dojo-Battle” antreten und ein Code Kata lösen sollten.

Nach einer kurzen Willkommens-Einwärm-Phase ging es auch schon zur Wahl des Code Kata’s für den Abend. Zur Auswahl standen KataBowling, KataMinesweeper und der KataLocCounter in der C# Variante. Nach der kurzen Vorstellung der Code Kata’s entschied sich die Dojo-Gemeinde für den KataLocCounter. Eine besonders erfrischende und spaßbringende Wahl, wie sich im Laufe des Abends herausstellen sollte.

Starke Teams denken, testen, zählen

Das Code Kata ist gewählt, die Aufgabe und Rahmenbedingungen erklärt, nun konnte es schon losgehen. Fast. Die Teams mußten noch formiert werden. Die wurden im Zählverfahren (wie denn sonst ;-)) aufgeteilt. Wie es der Zufall will, waren die Teamstärken gut verteilt.

Team 1 war stark besetzt mit der analytischen Expertise von Andre, den CCD- und .NET Guru’s Ralf und Stefan. Hinzu kamen erfahrene Dojojaner wie Thomas und Christina, gestärkt mit einem Dutzend weiterer .NET-Entwickler.

Doch wer nun dachte, Team 2 wäre schwächer aufgestellt, der irrte sich gewaltig. Christian, ein Dojo-Gänger der ersten Stunde und kraftvoll vorandesignender C# Architekt, der durch zahlreiche Dojo’s durchtrainierte Stefan, die geballte TDD/BDD-Erfahrung von Björn und ein starkes Dutzend .NET-Coder waren ein anspruchsvolles Lineup.

Die Teams waren aufgeteilt, das gedankliche Stretching und Warmup getan. Es konnte losgehen!

Jede Codezeile zählt

In einer ersten Phase wollten die Teams sich ein wenig detaillierter mit den Anforderungen an den Line-Counter auseinandersetzen, um eine “Design-Strategie” auszuarbeiten.

string code="Diese Zeile zählt!";
// Einzeilige Kommentare zählen nicht

// Dieser Kommentar und die leere Zeile davor zählen auch nicht
int count = 0; // Diese Zeile zählt natürlich!
bool countComments = false; /* Diese Zeile zählt auch */

/* So ein Kommentar
über mehrere Zeilen hinweg
zählt natürlich nicht als Code! */

Ein paar Kommentarbeispiele :-)

Interessante Erkenntnis hierbei: Man hat sich zwar mit den fachlichen Anforderungen und den daraus ergebenden Features bzw. Rahmenbedingungen auseinandergesetzt, dabei aber die Analyse und eine gemeinsame Implementierungsstrategie nicht wirklich erarbeitet. Geklärt war zumindest, dass es galt, Kommentare im Code zu erkennen und nicht mitzuzählen. Das Wie und eine gemeinsame Übereinkunft über die Strategie fiel bei beiden Teams “unter den Tisch”.

Doch das war offensichtlich zunächst nicht weiter schlimm, denn es schien erstmal wichtiger, das die Teams in den TDD-Rythmus kommen. Die ersten Tests gingen traditionell etwas schwerer vom Kopf in die Tastatur über, doch nachdem man sich auf den Happy-Pfad im Testing und eine inkrementelle Auslieferung des Programmes geeinigt hat ging es dann flotter.

Das Ergebnis innerhalb der Count-Methode des Team 1 war bis dato recht überschaubar:

            var lines = source.Split(new string[] { Environment.NewLine }, StringSplitOptions.RemoveEmptyEntries);

            return lines
                .Select(x => x.Trim())
                .Where(x => !String.IsNullOrEmpty(x))
                .Where(x => !x.StartsWith("//"))
                .Count();

Soweit so gut.

Stolperstein Block-Kommentare

Nach den einfacheren Fällen trafen beide Teams mit den mehrzeiligen Block-Kommentaren auf eine etwas härtere Nuss, die es zu knacken galt.

Wie sollte man denn die mehrzeiligen Kommentare erkennen? Vor Allem, wie sollte man dann mit besonders “außergewöhlichen” Kommentierungen umgehen?

int count = 1; /* mehrzeilige
kommentare können */ count++ /* herausfordernd sein */ ;

Außergewöhnliche Kommentare

An dieser Stelle holte die Teilnehmer die “zu kurze Analyse” zu Beginn wieder ein. Welche Strategie sollte man wählen? Die zeilenbasierte Verarbeitung aufgeben und zeichenbasiert arbeiten? Umschwenken auf schweißtreibende, aber mächtige Regular Expressions? Oder sogar eine Kombination von allem?

Das besondere und mich nicht überraschende: beide Teams wählten unterschiedliche Strategien. Während Team 1 die Eleganz des “Flows” der LINQ-Expression nicht aufgeben wollte und es mit Regular Expressions angereichtert hat, entschloss sich Team 2 für eine kleine Status-Maschine und einen Mix aus zeilen- und zeichenbasierter Verarbeitung.

Showdown

Nach knapp 3 Stunden war es dann soweit. Die Teams klopften die letzten Tests und Codezeilen ein, um sich dann im Schlußvoting dem gegnerischen Team zu stellen. Gespannt warteten die Teams auf den Code und die Resultate des Gegners.

Team 1 präsentierte zunächst das lauffähige Programm, danach das gute Dutzend Tests und den damit getriebenen Code. Auffällig: Der Code erschien dem Gegner auf den ersten Blick als kompakt und elegant.

Team 2 konterte prompt. Eine äußerst saubere Test-Suite, ein durch die differierende Implementierung etwas längerer Code und die Besonderheit, dass die Implementierung sogar (teilweise) Kommentar-Tokens innerhalb von Strings ignorieren konnte.

Ergebnis: Beide Lösungen waren unvollständig – aber gut vorangetrieben. Während Team 1 stärkeren Wert auf Auslieferbarkeit & Effizienz gelegt hatte, engagierte sich Team 2 mehr in den Bereichen saubere Tests & Funktionalität. Ausnahmsweise gab es beim ersten Dojo-Battle keinen Verlierer – beide Teams waren gleich stark. Die Ergebnisse von Team 1 und Team 2 lassen sich auf dem Dojo-Projekt bei Codeplex begutachten.

Fazit: Ein wirklich gelungener Abend mit engagierten Teams, die trotz der Herausforderungen und Schwierigkeiten eine gute Leistung abgeliefert haben! Danke an alle Teilnehmer! Chapeau!

Für alle, die nicht nur still und leiste in ihrem Kämmerchen Code Kata’s üben möchten. Für alle, die wissen wollen, mit welchen Tricks und Kniffen man mit Design Patterns, Methoden & TDD zu sauberem Design und Code kommt. Für alle, die sich selbst und andere in Punkto professionelle Softwareentwicklung weiterbringen möchten!

Am Mittwoch, den 20.01. werden im .NET Coding Dojo wieder .NET Enthusiasten, Software-Entwickler und System-Analytiker ein Programmierproblem annehmen, in Einzelteile zerlegen und es nach eigener Architektur und Bauplan kunstvoll wieder zusammenführen. Sei dabei!

Event-Details & Anmeldung über das Xing-Event bzw. die Xing-Gruppe.

Danke nochmals an Gregor & die DNUG für die Organisation und das nette Geschenk! Diese Woche scheint sowieso die “Dojo-Woche” zu werden, denn Morgen geht es schon wieder weiter mit einer neuen Herausforderung im Experten Dojo in München.

Die Anforderungen

• Das Spiel ist zu Ende, wenn alle Felder belegt sind
• Das Spiel ist zu Ende, wenn ein Spieler eine gesamte Reihe belegt hat
• Das Spiel ist zu Ende, wenn ein Spieler eine gesamte Spalte belegt hat
• Das Spiel ist zu Ende, wenn ein Spieler eine gesamte Diagonale belegt hat
• Ein Spieler kann ein freies Feld belegen
• Die Spieler belegen so lange ein freies Feld, bis das Spiel beendet ist

Auch die .NET Experten im Coding Dojo München hatten Ihren Spass an dem kleinen Spiel. Es musste natürlich kräftig überlegt und entwickelt werden – ohne Anstrengung geht’s eben nicht :-).

Summa summarum ein gelungenes und nettes KataTicTacToe. Auch zu empfehlen für TDD-Einsteiger. Es gibt jedem die Möglichkeit, eine eigene Lösung zu entwickeln und zeigt dabei die Grundprinzipien des TDD auf. Das Ergebnis der Profis lässt sich im Übrigen auf dem Codeplex-Projekt-SVN begutachten.

Achso, wer Lust hat, nicht nur die ganze Zeit über TDD zu lesen und zu reden, sondern auch mal “hautnah” TDD mit C# und professionellen Softwareentwicklungsmethoden live erleben und mitmachen möchte, für den sind schon die nächsten Sessions im Kalender markiert.

Wie immer sind am Anfang des Monats, genauer am 2. Dezember, die Einsteiger im Dojo gefordert. Zwei Wochen später, am 16. Dezember sind die .NET Experten gefordert, im Coding Dojo ihre gesamte Expertise einzubringen, um die sich selbst gestellte Aufgabe zu meistern.

TDD im Rampenlicht

Naja, das nur nebenbei. Mir geht es eigentlich um ein anderes Thema. Mir geht es um etwas Generelles. Als Pete und ich mit den .NET Coding Dojos angefangen haben, gab es positive Resonanz. Es wurden Dojo’s veranstaltet und Code Kata’s exerziert. Super! Meiner Ansicht nach kam TDD dadurch ein kleines Stück mehr in’s Rampenlicht als es schon durch Clean Code Developer bereits war. In zahlreichen Posts gab es Diskussionen um die Sinnhaftigkeit von Unit Tests, die Kata Berichte und grundlegender Erkenntnisse über TDD. Eine besonders positive Sache, denn Weiterentwicklung und Entdeckung sind schöne Dinge.

Doch eine Sache stört mich. Manchmal stört es mich sogar gewaltig. Dieses Trara und Tamtam um TDD und Beeinflussung des OO-Designs durch Tests und das Entkoppeln von Zustand. Bei dem einen oder anderen Post kann ich mir das Kopfschütteln während des Lesens einfach nicht verkneifen. Die Spitzfindigkeit und unnötige Verkomplizierung einfacher Sachverhalte geht mir zuwider. Für manch einen mag es Anspruch sein, über ein Feuerwerk an Eloquenz einfachste Dinge mit fesselnden Trapezschwüngen der Rhetorik auf das Hochseil des Softewareentwicklungszirkusses zu katapultieren. Die lufterhitzenden Spots, der nervöse Trommelwirbel, der adrenalisierende Schweiß der Konzentration inklusive. Für manch einen. Für mich jedenfalls nicht.

Im Gegenteil. Es stört mich. Es irritiert mich. Denn mich interessiert das Thema selbst. Ich denke es Bedarf keines jonglierens mit DIP, SRP, YAGNI, DRY, um wirklich im Alltag der Software-Entwicklung gut bestehen zu können. Man darf mich hier nicht falsch interpretieren. Auch ich finde es wichtig, sich mit “Dependency Inversion”, “Single Responsibility”, “Decisions on Last Responsible Moment” und “Repetition Avoidance” auseinanderzusetzen, damit umzugehen und täglich einzusetzen.

TDD ist keine “Rocket Science”

Doch man kann es übertreiben. Die ständige, gestelzte und wie ein Ritus sich selbst auferlegte “Tagesreflexionsprogramm” ist meines Erachtens nicht förderlich. Überspitzt betrachtet ist es genau dasselbe wie das Bart-Simpson-Einhämmerungs-Ritual “Ich werde keinen Zustand testen!” – repetitiv, jedoch nicht kognitiv. Wer’s mag, kann ruhig jeden Tag nicht nur Selbstreflexion betreiben, sondern auch jeden Tag ein Code Kata lösen, damit die Entwicklerseele rein wird. Ich jedenfalls werde das nicht tun.

Ich arbeite auch nach Prinzipien, löse Probleme auch mit Patterns und programmiere neben dem Tagesgeschäft ab und an auch mal Code Kata’s. Aber ich bin mir gleichermaßen bewußt, das ich jedes Mittel und Werkzeug richtig einordnen und im richtigen Maß anwenden muss, damit es mich langfristig weiterbringt.

Gleiches gilt für mich auch beim Thema TDD. Ich arbeite nun seit etwas mehr als einem halben Jahr stringent mit TDD. Zuvor habe ich es immer ab und an eingesetzt, aber nie “ernsthaft” betrachtet. Ich finde TDD (und auch BDD) sind eine besonders gute Methodik, um das V in EVA groß schreiben zu können. Es stärkt wunderbar die logischen Bestandteile der Anwendung und fördert mit der granularen Testanforderung lose Kopplung und komponentenorientiertes Design. Mittlerweile ist TDD für mich fester Bestandteil jeder Entwicklungsaufgabe.

Während der ersten Phase, in der ich TDD konsequenter eingesetzt habe, habe ich auch einiges darüber gelesen und durch das “Doing” auch vieles gelernt. So ist es z.B. überhaupt nicht schlimm, wenn man statusbehaftete Tests an den Enden der Datenverarbeitung macht. Konkret: Auch statusbasierte Tests sind ok, vor allem in Richtung DB oder UI. Ein schönes Beispiel dafür ist KataFizzBuzz als WinForms-Anwendung oder KataBlog. Natürlich ist interaktionsbasiertes Testen “schöner”, fördert die lose Kopplung und die isolierte Verifikation. Doch hier gibt es kein Schwarz oder Weiß. Es geht um den Einsatzbereich. Am Rand des Datenstroms ist man mehr statusbasiert, in der mitte eben mehr interaktionsbasiert. Außerdem ist das Thema Statustests vs. Interaktionstests ein relativ “alter Hut”. Schon mit Mocks Aren’t Stubs hat Fowler klar gemacht, dass beides in Ordnung ist.

Diese Zustands-Geschichte ist jedoch nur ein Beispiel. Es gibt da noch einige andere Klassiker: Kapselung, Verkettung, Referentielle Transparenz. Doch ungeachtet dieser Dinge, ist TDD keine Rocket Science. Im Gegenteil, TDD ist in der Kernaussage und Grundregeln so einfach, das sich die anderen “Problemstellungen” automatisch ableiten und auflösen. Gerade deswegen ist es meiner Meinung nach so wichtig, die Dinge einfach zu erklären und und diese “Leichtigkeit” auch zu transportieren. Die Code Kata’s von Dave sind ein Beispiel. Sie sagen nicht “Mach dies! Beachte das!”. Nein, sie sind eigenständige Probleme, auf deren Lösungsweg man individuell und für sich eine gute Lösung findet. Daraus ergeben sich automatisch mit der Zeit Verbesserungen und Erkenntnisse.

Fazit: Beim Verständnis und der Anwendung von Test-Driven-Development gilt, obgleich TDD ein bis Dato empirisch betrachtetes, jedoch theoretisch nicht ausreichend erforschtes Vorgehensmodell ist, das Prinzip von Ockhams Rasiermesser. Der praxisorientierte, frequentive Einsatz sowie das Erkennen der Grundtheoreme der TDD-Methodik sind das Fundament für den erfolgreichen Einsatz.

Und wenn ich das für alle diejenigen, die wie ich auch in der Kommunikation Wert auf Einfachheit legen, mal übersetzen darf:

TDD ist keine Wissenschaft!

Man kann viel darüber Lesen. Das ist auch gut. Besser ist es jedoch, TDD zu machen! Nicht viel über “dies und das” nachdenken. Die Devise lautet: “Mach es einfach, aber nicht einfacher“. Es wird von alleine gut und mit der Zeit sogar besser werden.