Es ist schon eine wundersame Welt. Also, in meinen Augen natürlich. Ich schreibe diesen Artikel ja auch, also kann es nur eine persönliche und subjektive Meinung sein. Aber immerhin, es ist eine Meinung, und das sogar ziemlich deutlich. Denn, ich habe den Artikel, die Kommentare und den Folge-Artikel von Golo zu seiner These “Räumliche Nähe wird überbewertet” gelesen. Das ich da anderer Meinung bin, habe ich ja schon gebloggt. Was also noch darauf rumreiten? Die Antwort ist einfach: Es ist wichtig, deswegen.

Kommunikation = Mitteilung + Wahrnehmung

Doch zunächst möchte ich in aller (nur notwendig langen) Kürze auf ein verwandtes Thema eingehen: Die Kommunikation. Besser gesagt, die zwischenmenschliche Kommunikation. Kommunikation ist eine schwierige und herausfordernde Kunst. Der eine sagt etwas, der andere versteht etwas. Ob es dann das ist, was der eine sagen wollte und der andere verstehen wollte, hängt von unheimlich vielen Faktoren und komplexen Sachverhalten ab. Doch zunächst gilt es festzuhalten: Kommunikation ist nicht nur Mitteilung, sondern auch Wahrnehmung. So geschehen auch bei der “Blog-Kommunikation” zwischen mir, Golo und dem “Publikum” (also auch Dir, lieber Leser).

Mit Golo’s Aussage fing es an: “Räumliche Nähe wird überbewertet“. Gut. Man könnte jetzt vieles wahrnehmen. Zum Beispiel könnte man wahrnehmen, dass Golo damit meint, dass ihm räumliche Nähe ein Graus ist. Oder man könnte wahrnehmen, dass Golo ein introvertierter, soziophober Alleingänger ist. Keines von dem ist der Fall. In meinen Augen ist derjenige, der so eine Wahrnehmung hat, einfach nicht aufgeschlossen und wohlwollend zu Golo’s Meinung. Dennoch – man könnte es sicherlich wahrnehmen.

Ich antwortete auf seine Aussage mit dem Artikel “Räumliche Nähe wird unterschätzt“. Gut. Man könnte jetzt vieles wahrnehmen. Zum Beispiel könnte man wahrnehmen, das ich damit “Verteilte Teams sind nicht erfolgreich” postuliere. Oder man könnte wahrnehmen, das ich ein opportunitisch-dogmatischer Agile-Fetischist bin. Keines von dem ist der Fall. In meinen Augen ist derjenige, der so eine Wahrnehmung hat, einfach nicht aufgeschlossen und wohlwollend zu meiner Meinung. Dennoch – man könnte es sicherlich wahrnehmen.

Aber jetzt mal Tacheles kommuniziert: Wer sollte denn so etwas annehmen? Ich finde so eine Wahrnehmung absurd. Ja, geradezu lächerlich. Demjenigen, der wirklich allen ernstes Golo nachsagen möchte, dass er Colocation als “schädlich” einstuft, oder aber mir den Vorwurf macht, ich würde “Colocation über Alles!” predigen, dem traue ich auch zu, dass er in “Satellite” keine Liebeshymne sieht, sondern es als öffentliche Drohgebärde einer Stalkerin zu ihrem Opfer interpretiert. Soviel dazu.

Die Mathematik der Meinung

Zurück zum Thema, der räumlichen Nähe. Ich bin nach wie vor der Meinung, dass räumliche Nähe unterschätzt wird. Unterschätzt in vielerlei Hinsicht. Ich gehe zunächst auf eine Perspektive ein, die auch schon angesprochen wurde: Effizienz und Produktivität. Golo schreibt in einem Kommentar treffend seine Motivation:

Golo: “…Es ging mir um die immer postulierte Allgemeingültig der Aussage “Colocation ist besser”. Zu zeigen, dass dem nicht so ist, genügt ein einziges Gegenbeispiel…”

Meine Meinung dazu: Ja, Richtig und Nein, Falsch. Das ist nicht logisch? Macht nichts. Ist trotzdem so.

Denn: Ja, es ist richtig, dass Golo nur ein Gegenbeispiel zeigen muss, um die Allgemeingültigkeit ad acta zu legen. Und: Nein, es ist falsch, denn meiner Meinung nach ist das gewählte methodische Werkzeug – nämlich die Anwendung der Aussagenlogik und deren Beweismethoden – völlig unangebracht. Bei allem Respekt gegenüber der Professionalität und Kompetenz von Golo bin ich etwas irritiert, das gerade der Berater für agile Methoden die Colocation nicht zu favorisieren scheint.

Doch die Motivation verstehe ich nur allzu gut – es wird öfters die “Colocation” als Heilsbringer dargestellt. Dem ist nicht immer so. Aber muss man deswegen so eine trockene, wissenschaftliche Herangehensweise wählen? Ich denke, dass es nicht unbedingt notwendig gewesen wäre, denn schließlich führt die Bool’sche Algebra hin zu einer totalitären “Schwarz-Weiss”-Wahrnehmung (wie oben geschildert). Dabei ist in Wahrheit nicht schwarz oder weiss schön, sondern alle Farben.

Leider wird für meinen Geschmack bei diesem Thema zu tief in die mathematisch-naturwissenschaftliche Logik-Kiste gegriffen. Logik & Mathematik sind mächtige Werkzeuge, die man oft und versatil einsetzen kann. Aber sie sind nicht die Weisheit für alle möglichen Systeme oder Lebenslagen. Ich meine, hier ist Logik alleine nicht das adequate Werkzeug. Vielmehr hilft meines Erarchtens hier der gesunde Menschenverstand mit dem unvergleichlichen Etwas, was uns Menschen auszeichnet: Emotion. Doch dazu komme ich gleich noch.

Handlungsfähigkeit, Produktivität und Effizienz

Fakt ist, dass Menschen, die an einem Ort, in einem Raum zusammenarbeiten, Ihre Arbeit in den meisten Fällen effizienter, effektiver und produktiver gestalten und erledigen. Abseits von Agilität und unabhängig von der eingesetzten agilen Managementmethode stellt man fest: In sehr vielen Fällen ist ein “Warroom” oder “Teamroom” für eine erfolgreichere Gestaltung des Vorhabens nicht nur hilfreich, sondern mit ausschlaggebend. Darüber hinaus entwickelt sich ein deutlich zügigerer Durchlauf des Teams durch die Tuckman-Phasen. Mit der Zeit entwicklelt man auch ein viel besseres Verständnis zu den Aufgaben anderer und vermag auch, den anderen in brenzlichen Situationen zu helfen. Und manchmal ist man auch ganz glücklich, wenn einem selbst ein wenig unter die Arme gegriffen wird.

Es gibt dabei meiner Meinung nach aber noch einen weiteren wichtigen Aspekt. Es ist die Teamaufstellung. Es ist eines der Dinge, die bei der Diskussion für mein Empfinden viel zu wenig herausgearbeitet wurde. Oder besser auf Deutsch gesagt: es wurde einfach ignoriert. Schade. Denn ein agiles Team ist nur dann ein agiles Team, wenn es interdisziplinär (bzw. “cross-functional”) ist. Warum das so ist, habe ich ja schon geschildert. Der Effekt, der dabei entsteht, ist eine wesentlich effizientere Kommunikation zwischen den einzelnen Domänen- und Fach-Experten. Darüber hinaus werden intuitiv und äußerst effizient gemeinsame Schnittstellen und eine Ubiquitous Language entwickelt.

Es gibt noch eine Menge anderer Dinge, die ein interdisziplinäre und lokale Teamaufstellung zu einer Präferenz zu anderen Teamstrategien macht. Doch der kausale Kern eines agilen Teams ist und bleibt geschäftsgetrieben. Ein agiles Team ist “im Kern” nur interdisziplinär, weil es der einzige Weg ist, ein Feature als Ganzes, also integer und abgeschlossen, umzusetzen. Das es nebenbei diese Aufgabe auch noch effektiver löst, als andere Teamaufstellungen, ist die “Sahne” auf dem Kuchen.

Mi Kasa Es Su Kasa

Ein weiterhin von Golo und anderen Kommentatoren kritisch beäugtes Merkmal von “Colocation” ist die “Minderung der Produktivität durch Störungen”. Diese Argumentation ist für Agilisten nichts Neues. In meinen Augen ein Indiz für Ängste. Man befürchtet, dass man durch “den Lärm” und “die Unterhaltungen” im Raum nicht mehr konzentriert arbeiten kann, sich jeder die Kopfhörer aufsetzt und in seine Welt entschwindet. Man befürchtet, dass man sich nicht mehr in seinem eigenen kreativen Mikrokosmos nicht mehr wohlfühlen kann. Man befürchtet, beobachtet zu werden. Man befürchtet, sich einfach nicht mehr in die Arbeit “gehen lassen” oder “eintauchen” zu können. Das sind verständliche Ängste. Besonders dann, wenn man noch nie oder erst selten mit agilen Teams – oder als Teil eines agilen Teams gearbeitet hat. Ich kann das nachvollziehen.

Doch ich kann es nicht nachvollziehen, dass manche – wohl genährt durch diese Befürchtungen – behaupten, dass es “sowieso nicht besser wäre”, oder für die einzelne Persönlichkeit und den einzelnen Charakter ungeeignet sei. Noch dazu ohne es einmal ausprobiert zu haben. In meinen Augen ist das eine lapidare und profane Argumentation. Viel zu oft gewinne ich dadurch den Eindruck, das dieser Schlag von Entwicklern ein wenig zu oft an sich selbst denkt als an andere Teammitgleider und die gemeinsame Sache.

So sind z.B. Designer und UX-Experten wesentlich intensiver mit kreativer Schaffung konfrontiert und damit auch deutlicher abhängig von ein Umfeld, in dem die “Kreativität keimen und reifen” kann. Auch Produkt Manager sind oft mit hochkonzentrierten und komplexen Denkprozessen beschäftigt, wenn es z.B. um die Entwicklung von neuen Features eines Produktes geht. Was ich damit sagen will: Jeder ist ein Mensch, nicht nur die “Coder”. Wer wünscht sich nicht gerne sein eigenes “Arbeitsreich”? Doch auch wenn man es hätte, in den meisten Fällen wäre es für die gemeinsame Sache eben nicht zielführend, das jeder sein Reich hat und sein eigenes Ding auf seine eigene Art und Weise macht.

Interessanterweise sind es aus meiner Erfahrung gerade diejenigen, die mehrheitlich Konzentrations- oder Kreativitäts-Aufgaben erledigen, am wenigsten Probleme mit der Zusammenstellung interdisziplinärer Teams in einen Raum haben. Im Gegenteil. Sie fühlen sich inspiriert und freuen sich, dass ihre Arbeit auch gesehen und bewertet werden kann. Ein guter & agiler Web-Designer z.B. freut sich über jedes frühe Feedback – von jedem. Natürlich braucht man auch seine Ruhe- und Schaffungsphasen. Jeder braucht das.

Das ist im Übrigen eines der ersten Dinge, die ein agiles Team auch lernt und gestaltet: Ruhephasen – Bibliotheksmodus – Silentio. Ein weiteres, hilfreiches Merkmal solcher “hyperproduktiven Arbeitsumgebungen” sind Fluchtpunkte. Also Ruheinseln, in denen man sich zurückziehen kann. Für Persönliches oder Privates. Oder einfach nur so, zum ausruhen. Powernap. Etwas lesen. Am Flipper eine Runde zocken und den Kopf etwas frei kriegen. Auftanken.

Ich sage nicht, das all das, was ich gerade erwähnt habe, nicht auch mit verteilten Teammitgliedern möglich wäre. Es ist auch machbar. Die Profi’s Golo & Peter sind ein gutes Beispiel dafür. Aber es ist meiner Meinung in sehr vielen Fällen ungleich schwieriger, deutlich fragiler und auch minder effizient. Mit Colocation funktioniert es natürlich auch nicht immer – aber dafür deutlich öfter, einfacher und produktiver.

Emotion. Hautnah.

Zurück zu dieser einen “ungreifbaren” Sache, die mit agilen Teams an einem gemeinsamen Ort besonders hervorstechend ist. Die Emotion. Emotion ist etwas so wichtiges und schönes. Auch für Entwickler und Nerds. Man regt sich über den langsamen SATA-Treiber auf. Man installiert gespannt die neuesten Plugin’s für Visual Studio während man sich mit dem Käsebrötchen vollkrümelt. Man lacht sich über den 3. roten Build des Tages kaputt, weil es wieder einmal ein Leichtsinnsfehler war.

Doch Emotion ist nicht nur für einen selbst wichtig. Emotion ist auch für andere wichtig. Die Sprache ist nur ein Teil der Kommunikation. Manche Streiten sich darüber, ob nur 7% unserer gesamten Kommunikation verbal ist. Fakt ist, Sprache ist nicht alles. Den Satz “Ich verstehe.” von einer langfährigen, erfahrenen Web-Designerin zu hören – flüsternd, mit glasigen Augen und zittrigen, schweißgebadeten Händen, die sie vergebens versucht hinter ihrer großen Pop-Art-Teetasse zu verstecken – oder aber “Ich verstehe.” mit resoluter Stimme wahrzunehmen – gefolgt von einer gekonnten Seitwärtsdrehung, die ihre zum Pferdeschwanz gebundenen Haare durch die rapide Rotationskraft zu einem Duftkatalysator ihres Luxusparfums entarten lässt und mit der Registrierung ihrer kalten Schulter abrupt endet. Ein und das selbe Wort – doch zwei Nachrichten, die gegensätzlicher kaum sein könnten. Natürlich gibt es noch tausende von andere Bedeutungen des Satzes “Ich verstehe“, aber ich denke Du verstehst, was ich meine. ;)

Für einige mag das jetzt zu weich, unlogisch, konstruiert oder unwissenschaftlich sein. Aber das ist mir egal. Denn das ist es, was ich am Anfang dieses Artikels mit “es ist wichtig” gemeint habe und was ich zum Ausdruck bringen will: Agile Teams, die gemeinsam an einem Ort arbeiten sind sicherlich nicht perfekt. Aber sie sind in der deutlichen Vielzahl der Fälle produktiver, effektiver, handlungsfähiger, änderungswilliger, offener, respektvoller und: emotionaler.

Das Ergebnis ist eine gewisse Energie, eine gewisse Magie, die bei agilen Teams mit Colocation öfter und schneller entsteht. In dem letzten Slide meines Enthusiasmus-Vortrags über Scrum beim Webmontag in München sieht man eine Band im Sonnenuntergang zusammenspielen. Das spiegelt die Energie & Magie ein wenig wider: die Emergenz des Teams. Das Ganze ist mehr als die Summer der einzelnen Teile.

Und damit dieses ach so kindische “aber du sagt das ist toll und alles andere ist blöd”-Fingerpointing nach diesem Artikel hoffentlich keinen Nährboden findet, nochmal ein klarer Disclaimer: Ich habe die Weisheit nicht gepachtet. Ich bin kein Klugscheißer und Besserwisser, und ich will es auch nicht sein. Aber ich habe eine Meinung. Ob sie Dir gefällt, lieber Leser, musst Du schon selbst wissen.

Für mich ist klar: wer wirklich agile Software-Entwicklung betreiben möchte, der wird versuchen, ein Team an einem gemeinsamen Ort arbeiten zu lassen. Wenn es nicht möglich ist, dann eben mit Hilfsmitteln verteilt. Alles andere ist in meinen Augen weder agil, noch fortschrittlich, noch wirklich produktiv. Ob das für Dich, lieber Leser, auch so ist, musst Du schon selbst wissen.

Ich bevorzuge es, wenn ich meinem Kollegen auf die Schulter klopfen kann, wenn er einen genialen Integrationstest geschrieben hat. Oder dem Web-Designer in sein kritisches Gesicht zu blicken, wenn er wieder einmal den Usability-Prototyp der UX-Designerin begutachtet und währenddessen sich die Komplementärfarben im Pantone-Fächer zurechtsucht. Es ist für mich eine Ehrensache, dem gestressten Produktmanager beim sortieren und formulieren der neuen User Stories zu helfen, weil er in einer Stunde ein wichtiges Meeting mit dem Marketing hat. Und: es baut mich auf, wenn meine Teammitglieder mich anlächeln, weil ich ein Feature mit einem Kollegen fertiggestellt habe und wir uns nach dem grünen Build in den Armen liegen, als wäre der FC Bayern gerade Championsleague-Sieger geworden.

Ich bevorzuge agile Teams an einem Fleck, an einem Ort, in einem Raum.
Gemeinsam für die gemeinsame Sache.
Räumliche Nähe wird unterschätzt.

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“ :-)

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…

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!

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.

Thomas stellt zur Debatte, ob man aus Repository-Methoden ab und zu auch mal null zurückgeben darf/kann/soll. So z.B. bei so einer Methode:

User GetUserByName(string name);

Mache das Unmögliche möglich?!?

Einige Leute finden das garnicht besonders gut. Sie bevorzugen lieber soetwas wie einen “nicht-existenten” User zurückzugeben. Also eine Instanz einer Klasse, die eigentlich garnicht möglich wäre (weil sie ja die nicht exsistierende Instanz darstellt). Programmtechnisch ist das sicherlich recht einfach lösbar – oftmals mit einer statischen Property, die sich wiederum eines privaten Konstruktors bedient. In dem obigen Beispiel könnte eine derartige Implementierung ungefähr so aussehen:

public User GetUserByName(string name)
{
  if (!repository.UserExists(name))
    return User.NotExistent;

  //user laden und zurückgeben
}

Eine zweite, nicht minder bevorzugte Alternative zur Rückgabe von NULL ist die beliebte Exception. Falls also kein Benutzer unter dem angefragten Namen existieren sollte, dann soll eine Ausnahme signalisiert werden. Ganz einfach implementiert:

public User GetUserByName(string name)
{
  if (!repository.UserExists(name))
    throw new UserNotFoundException(name);

  // user laden und zurückgeben
}

Beides sind sicherlich mögliche und sogar gute Alternativen zu der Implementierungsvariante, die Thomas zur Diskussion gestellt hat:

public User GetUserByName(string name)
{
  if (!repository.UserExists(name))
    return null;

  // user laden und zurückgeben
}

Um es kurz zu fassen: Alle drei Varianten sind möglich, alle drei Varianten sind gut, alle drei Varianten sind schlecht. Es kommt auf den Anwendungsfall an. Die beliebte “It-Depends”-Weisheit streckt das Thema mit geballter Kraft nieder. Dennoch ist es eine Untersuchung wert, denn ungewöhnlicherweise wird die NULL-Variante kategorisch als falsch und “böse” bewertet.

Nullbivalenz

NULL ist ein besonderer Wert. Er ist der Wert, der eigentlich nicht zugewiesen werden kann. Genauer genommen ist er kein Wert, sondern nichts anderes als die knapp in vier Buchstaben formulierte Aussage “Ein für eine bestimmte Werteklasse belegter Ort wurde mit keinem Wert belegt”. Ergo: Null ist kein Wert. Ja, aber ist das denn nicht genau das, was GetUserByName ausdrücken und zurückgeben muss, wenn es keinen Benutzer für den gegebenen Namen findet?

Schaut man sich die erste Alternative zu NULL an (also das User.NonExistent-Konstrukt), dann kann man sagen: Joa, ok – ist aber das Gleiche. User.NonExistent ist sicherlich expliziter als NULL. NULL ist aber schon da und genau für solche Dinge gedacht. Die Aufgabe von NULL ist ja genau die, keinen Wert darzustellen.

Und wie sieht es mit Alternative Zwei – der UserNotFoundException aus? Die Excpetion ist auch explizit. Mehr noch, die Exception ist flexibel und rigoros gleichermaßen. Flexibel, weil sie jederzeit aus dem Nichts auftauchen kann. Rigoros, weil sie eine Fülle von Informationen über den Kontext sammeln und mitgeben kann. Die Exception sagt hier klar und deutlich: “Es gibt keinen Wert, weil der Benutzer {name} nicht gefunden wurde.”. Scheinbar ein Vorteil gegenüber den anderen Varianten. Im Ergebnis ist es jedoch nicht wesentlich von den anderen Herangehensweisen unterscheidbar.

Null Sicherheit

Nun, offensichtlich ist die sprechendere Variante der Exception vorteilhaft und damit dem NULL vorzuziehen. Doch beim zweiten Blick entpuppt sich der Vorteil als nicht so deutlich als zunächst vermutet. Denn in der Praxis kann sich die “unklare” und “unexplizite” Art von NULL wieder als erwünscht erweisen.

So muss man bei Exceptions, um den Mehrwert zu kennen, auch deren Typ genau kennen. Man muss also Wissen, das es sich um eine UserNotFoundException handelt. Erst dann kann man auch erfahren, welcher ominöse Benutzer unauffindbar ist. Das kann durchaus problematisch werden, wenn man also im höheren Callstack wissen muss, um welche Exception es geht, denn schliesslich schafft man sich dadurch eine Abhängigkeit auf den niedrigeren Code.

Null ist also eine unsichere, uninformative, aber immer verfügbare und unabhängige Variante, dem Aufrufer zu sagen: “Es gibt keinen Wert für das, was Du von mir verlangst”. Wenn man sich mit der Anwendung von NULL jahrelang auseinandergetzt hat und auch ein wenig die ungeliebten Interna von Speichermanagement & Datenstrukturen hineinblickt, dann wird NULL schnell zu einer praktikablen Lösung für schwierige Situationen.

Doch vor Allem bei NULL stellt man immer wieder fest: praktikabel und elegant sind zwei verschiedene paar Schuhe. Denn NULL ist genauso nichtssagend wie vielseitig. NULL zwingt den Aufrufer zum Abwägen: Soll ich das Ergebnis gleich auswerten oder lieber überprüfen? Ein wunderbares Beispiel dafür ist sicherlich der “if (x != null)”-Check – die Null-Prüfung. Das wird vor Allem dann zum Problem, wenn man mit (gewollt oder ungewollt) unbekannten Komponenten arbeitet. Im Interface oder in der Typsignatur steht es jedenfalls sehr selten erkennbar drin, ob nun in Einzelfällen NULL zurückgeliefert wird oder nicht.

Null ist nicht gleich Null

Für mich gibt es beim Umgang und bei der Anwendung von Null keine Faustregel. Ich gebe in einigen Methoden NULL zurück. Meistens genau dann, wenn ich wirklich damit ausdrücken möchte, dass etwas katastrophales passiert ist. Ich finde es sehr schwerwiegend, NULL als Zuweisung oder Rückgabe stehen zu lassen – aber ich mache es manchmal ganz bewusst. In einer Anwendung, in der ich z.B. Benutzer über einen Authentifizierungsdienst identifizieren muss, bevor ich überhaupt etwas anderes machen kann, kann die folgende Signatur NULL zurückliefern:

interface IAuthenticationService
{
  Account SignIn(string user, string password);
}

Es kann alles mögliche passiert sein – keine Verbindung zum Server, falscher Server, Verbindungsfehler, Connection Timouts, Benutzer nicht gefunden, Benutzer gesperrt, Passwort abgelaufen, falsches Passwort – all dies würde ich versuchen über Exceptions oder Return-Codes zu erledigen. Die meisten der Exceptions gibt es ja schon frei Haus vom Framework. Aber für das mich Unbekannte und Unerwartete gibt es immer noch eine Rückgabe, und die heisst NULL.

Null-Summen-Spiel

Generell kann ich für mich nur sagen, dass ich gelernt habe mit NULL sehr vorsichtig umzugehen. Ich vermeide es so gut wie möglich. Exceptions sind ein gutes Mittel – allerdings setze ich sie auch nicht sehr oft ein. Die Bürde der Abhängigkeit ist schon da – obwohl es natürlich in der Contract-Assembly definiert ist. Bei Repositories habe ich (fast) immer Ergebnisse die nicht NULL liefern. Andererseits setze ich NULL als Rückgabe auch öfter ein, wenn ich nur eine “schwere” Ausnahme in meinem Code feststelle.

Im obigen Beispiel hätte ich wohl NULL als Rückgabe toleriert, vor Allem, wenn ich davon ausgehen kann, dass es oft – oder sehr oft – dazu kommen kann und diese Tatsache ein schwerwiegendes Problem darstellt. Ein schönes Beispiel sind immer wieder die Brute-Force und DOS-Attacken auf Webportale.

Ich hätte wahrscheinlich nicht NULL zurückgegeben, sondern eine Exception ausgelöst, wenn ich das Ganze als wiederverwendbare, allgemeine Kompontente entwickeln würde.

So oder so – beides ist machbar und beides hat seine Berechtigung. Klar und deutlich soll aber abschließend erwähnt sein: NULL zu vermeiden ist eine gute Sache. Es macht den Code expliziter, offensichtlicher und lesbarer.

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!

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!

Nun, vor genau 10 Jahren (Frühjahr 2000) habe ich erstaunlich vielschichtiges getan. Da bin ich selbst schon überrascht. Ich habe z.B. einen HTML-Editor (versucht) in VB6 zu programmieren. Und habe ich einen PDF-Scanner in C geschrieben (um Bilder bzw. 2D-Polygone aus dem PDF zu “extrahieren”). Doch beides möchte ich hier nicht vorstellen, sondern ein ganz anderes Programm, mit vorerst letztem CVS-Commit am 15.03.2000: ScanDirNavian.

ScanDirNavian ist ein kleines Ameisenprogramm in VB6. Es durchforstet einen gesamten Verzeichnisbaum auf bestimmte Dateien (mit bestimmten Patterns im Dateinamen) und listet diese in einer Logdatei auf. Als Zusatzfeature kann es nicht nur die Dateiinformationen loggen, sondern auch einfache Transformationsaufgaben erledigen. Z.B. “Nehme die ersten 3 Zeichen des Dateinamens, falls es eine Zahl ist, stelle Sie an das Ende des Dateinamens.”

Ich bin mir nicht mehr sicher, welchen Zweck ich damit eigentlich bedient habe. Ich kann mich vage daran erinnern, dass ich tausende von Logdateien (von Linux, Raytracern und diversen anderen Programmen) irgendwie umstrukturieren bzw. in andere Verzeichnisstrukturen überführen wollte. Ein Codeschnipsel gefällig? Bitte gerne:

Private Sub CommandScan_Click()
    Dim StartDirectory As String
    Dim ScanTimeString As String
    AllFileCounter = 0
    AllScanTime = 0

    StartDirectory = DirSource.Path
    LabelInfo.Caption = "Scanning Directory" & vbCrLf & vbCrLf & _
        StartDirectory & vbCrLf & vbCrLf & _
        "Please wait until scan is complete."
    TabLog.Tabs(3).Selected = True
    FormMain.MousePointer = 11
    TimerScanDuration.Enabled = True
    DoEvents

    If InStr(TextHeader.Text, LogTypeCommand(7)) > 0 Then
        TextHeader.Text = _
            Left(TextHeader.Text, _
            InStr(TextHeader.Text, LogTypeCommand(7)) - 1) & _
            DirSource.Path & _
            Right(TextHeader.Text, Len(TextHeader.Text) - _
            InStr(TextHeader.Text, LogTypeCommand(7)) - _
            Len(LogTypeCommand(7)) + 1)
    End If
    If InStr(TextHeader.Text, LogTypeCommandShortCut(7)) > 0 Then
        TextHeader.Text = _
            Left(TextHeader.Text,
            InStr(TextHeader.Text, LogTypeCommandShortCut(7)) - 1) & _
            DirSource.Path & _
            Right(TextHeader.Text, Len(TextHeader.Text) - _
            InStr(TextHeader.Text, LogTypeCommandShortCut(7)) - _
            Len(LogTypeCommandShortCut(7)) + 1)
    End If

    If Len(TextLog.Text) = 0 And Len(TextHeader.Text) > 0 Then _
        TextLog.Text = TextHeader.Text & vbCrLf & _
        String(Len(TextHeader.Text), "-") & vbCrLf & vbCrLf

    ScanDirectory DirSource.Path, TextOutput.Text
    DirSource.Path = StartDirectory
    TimerScanDuration.Enabled = False

    FormMain.MousePointer = 0
    ScanTimeString = Trim(Str(AllScanTime / 10))
    If Left(ScanTimeString, 1) = "." Then ScanTimeString = "0" & ScanTimeString
    LabelInfo.Caption = "Scan complete !" & vbCrLf & vbCrLf & _
        "Successfully passed through " & Trim(Str(AllFileCounter)) & " files." & _
        vbCrLf & "Elapsed time: " & ScanTimeString & " seconds."
End Sub

Oh je, da habe ich mich nicht gerade mit Ruhm bekleckert :-) Funktioniert hat es – Ja. Aber lange zufrieden war ich auch nicht damit. Immerhin hat es seinen Zweck erfüllt.

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! :-)

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.

Ich möchte gleich mal eine provokante Aussage in den Raum werfen: Bugtracking für Software-Projekte ist sinnlos. Jedenfalls in den meisten Fällen. Mehr noch, Bugtracking sollte soweit wie nur irgend möglich vermieden werden!

Was will ich damit sagen? Man betrachte einmal das mittlerweile so “selbstverständliche” Tooling bei Software-Projekten: Man nehme ein SCM (z.B. SVN oder git), ein CI-System (z.B. TeamCity oder CruiseControl) und einen IssueTracker (z.B. Bugzilla oder Trac). Man kann das ganze natürlich auch als Gesamtpaket haben, z.B. mit TFS. So, damit hat man die Eckpfeiler einer Software-Entwicklungsumgebung parat und kann frisch und fröhlich programmieren. Ich denke allerdings das dieses Toolset nicht ganz so glücklich gewählt ist.

Bugtracking ist Zeitverschwendung

In einer Zeit, in der viel getan wird, um einen sauberen Code zu produzieren ist meiner Meinung nach die jetzige “Methodik des Bugtrackings” nicht mehr adequat. Entwickler versuchen mit agilen Methoden (teilweise krampfhaft) mehr Qualität und Stabilität in ihre Produkte zu bringen. Ein aktuelles Beispiel ist die Beachtung und Anwendung der Prinzipien der Clean Code Developer Bewegung, die Ihre Kernaussage aus der Craftsmanship-Ideologie von UncleBob schöpft. Darüber hinaus beschäftigt sich die gesamte Softwareentwicklungsindustrie seit Jahren mit Themen wie z.B. Continuous Integration oder Test-Driven-Development, die mitunter das Ziel haben, die Qualität des Softwareproduktes schon während der “Produktionsphase” stetig hoch zu halten. Flankiert wird das ganze auch noch mit agilen Managementmethoden wie z.B. Scrum oder Kanban, die auch einen besonderen Anspruch auf stetige, hohe Qualität legen.

Nichtsdestotrotz findet man in jedem Tool-Setup den altbekannten “Bugtracker” wieder. Wieso? Auf der einen Seite strebt man nach dem “Zero-Defect”, nach hochqualitativer Software. Aber mit dem gleichen Atemzug gibt man sich dennoch geschlagen, indem man von vornherein mit Bugs rechnet. Denn einen Bugtracker zu betreiben ist in den allermeisten Fällen nichts anderes als ein Geständnis. Undzwar das Geständnis sich selbst gegenüber, doch nicht alles “hundertprozentig” zu machen. Es ist ein Widerspruch in sich. Jaaaa, Clean Code, TDD, BDD, DDD und noch eine handvoll anderer bewährter Methoden, von mir aus noch Pair Programming, Continuous Integration / Deployment und Scrum. Aber: Ein Bugtracker muss auf jeden Fall auch her.

Bugtracker ist nicht gleich Liste und schon garnicht Archiv

Man mag mir entgegenbringen, dass mit einem “Issue Tracking”-System nicht nur Bugs verwaltet werden, sondern auch Feature-Requests und ähnliches. Featurelisten sind eine wunderbare Sache, vor Allem wenn man sie priorisieren kann. Aber dazu braucht man keinen Bugtracker. Im Allgemeinen reichen einfachere Tools aus.

Das am meisten erwähnte Gegen-Argument ist wohl, das man mit dem Bugtracker die Bugs “verwalte”, um sie ja nicht zu vergessen und Ihnen angemessene Priorität zu geben. Lächerlich! Eine Farce, denn in der professionellen (wirtschaftlich orientierten) Softwareentwicklung ist solch ein Ansatz absolut kontraproduktiv. Erstens schafft es einen weiteren Verwaltungs- und Organisationsapparat, den es erst mal zu bewältigen gilt. Zweitens mutiert es mit der Zeit zu einer Halde (ich will schon fast sagen Müllhalde) von unwichtigen Bugs und Feature-Requests, die man irgendwann einmal angehen will. Drittens stellt es automatisch und implizit ein Konkurrenzsystem zur Roadmap dar. Warum?

Na ganz einfach: wenn ein Bug wirklich ein wichtiger Bug ist, dann wird er sofort gefixed. Alles andere ist entweder nicht wichtig oder wird dann erst wichtig, wenn die wichtigeren Dinge schon erledigt sind. So einfach ist das.

Außerdem: Gefühlt implementiert nahezu jeder, der was auf sich hält seine Software mit agilen Methoden und Praktiken. Scrum und XP sind schon längst angekommen; und mit TDD und Clean Code wir bewegen uns auf einem hohen Niveau, oder nicht? Unsere Grundmotivation ist es doch, fehlerfreie Software auszuliefern, oder nicht? Ok, 100%ig gibt es nie, aber wir streben doch zumindest die three nines der “High Quality” an, oder nicht? Ich denke schon – zumindest ist das mein Verständnis. Wenn dem so ist, warum brauchen wir dann ein Bugtracking-Tool?

Bugreporting ist wichtig, Bugtracking jedoch unwichtig

Ich möchte mit meiner provokanten Aussage nicht erreichen, das man grundsätzlich das Issue Management anzweifelt. Es ist eher das Gegenteil der Fall. Ich stärke sogar die Wichtigkeit & Effizienz, zumal nach wie vor ein richtiges Bugreporting und eine Bug Triage entscheidend sind, um die richtige Entscheidung treffen zu können. Mein Augenmerk gilt der Bugverwaltung an sich, also der zentralisierten Auflistung, Verwaltung und Archivierung von Fehlerprotokollen. Im Lean Management sind zentrale Prozesspunkte ein “rotes Tuch”. Statt dem sternförmigen Kommunikations- und Prozessmodell wird dort das, Netzmodell favorisiert. Dieser Ansatz ist meiner Meinung nach besonders auf das Issue Management anwendbar.

Natürlich kann ich nicht generell sagen, dass ein Bugtracking-Tool sinnlos ist. Es gibt immer wieder Situationen und Rahmenbedingungen, die auch ein Bugtracking-Tool und eine zentrale Fehlerverwaltung rechtfertigen. So ist es z.B. bei einem Produkt, bei dem die User-Gemeinde aktiv die Bugs berichten und einsehen kann sicherlich sinnvoll, ein Bugtracking-System einzusetzen. Allerdings ist es nur in den seltensten Fällen wirklich notwendig.

Man könnte ein Bugreporting auch derart gestalten, dass man sich beim Reporter für den Bericht bedankt und ihm verspricht, das Problem zu analysieren. Dann schaut man sich den Fehler an. Ist er wichtig genug, wird er sofort gefixed – und der Benutzer ist glücklich. Ist er nicht wichtig genug (also ist entweder ein anderer Bug oder ein anstehendes Feature wichtiger), so wird der Report weggeworfen. Der Benutzer wird benachrichtigt dass der Fehler momentan nicht korrigiert wird. Ehrlich, sachlich, klar. Der Berichterstatter kann nun nochmals (mit Vehemenz) darauf pochen, den Fehler behoben zu wissen. So kann man z.B. bei benutzerorientierten Produkten auch ein Voting einsetzen (wie z.B. bei Codeplex). Erhöht sich das Voting (die Priorität) nicht, wird der Bug nicht gefixed und weggeworfen. That’s it.

Es gibt nur ein Go oder Nogo für einen Bugfix

Ich bin der festen Überzeugung das diese Verfahrensweise vor Allem dann effizient ist, wenn man in der Software-Entwicklung agile Methoden anwendet. Für mich sind Software Craftsmanship, TDD, XP und all die weiteren modernen Methoden einfach nicht mit dem veralteten Zentralverwaltungs-Muff “Bugtracking” vereinbar. Statt dessen sollte man ein leichtgewichtiges Bugreporting etablieren und die Entscheidung über den Fix oder No-Fix des Bugs schnell herbeiführen. Nur so kann man sich selbst dazu erziehen, von Anfang an in der Software-Entwicklung das Qualitätsbewusstsein zu schärfen und die Qualität konstant adequat hoch zu halten. Denn nur mit dieser “KO-Entscheidung” über den Fix eines Bugs kommt man (leidend, aber relativ schnell) zu der Erkenntnis, dass man wenn man wirklich das Produkt stetig weiterentwickeln möchte auch immer sich zum Ziel setzen muss, ein möglichst fehlerfreies Produkt auszuliefern.

Die Erkenntnis, Bugs nicht zu verwalten und sofort zu entscheiden, ob es gefixed werden soll oder einfach ignoriert werden soll ist meiner Meinung nach ein wichtiger Bestandteil für qualitative, agile Software-Entwicklungs-Methoden.

Ergo: Bugtracking ist sinnlos!

Dabei hatte das Münchner Dojo viel “Event-Konkurrenz”: Der Joint-Launch von Microsoft, der Twittwoch und das unnachahmliche Herbstwetter mit 25 Grad!. Um so erfreulicher, das sich die Teilnehmer nicht davon abhalten liessen mit mir zur Feierabendzeit noch eine geistige Trainingseinheit im Dojo hinter sich zu bringen. Ich bin als Master kurzfristig für den erkrankten Pete eingesprungen – an dieser Stelle Gute Besserung! Ich hoffe ich konnte einen adequaten Ersatz darstellen.

Zum Dojo: es gab drei Code Kata’s zur Auswahl: Minesweeper, der im Experten-Dojo gelöste Taschenrechner und das mittlerweile beliebte FizzBuzz, jedoch reinkarniert als Windows-Forms-Anwendung.

Die Teilnehmer entschieden sich für FizzBuzz im Windows-Forms-Gewand. Vorlage für diese Übung war die iPhone-Implementierung. Eine gute und herausfordernde Wahl, wie sich im Nachhinein herausstellen sollte.

Zum “Warmwerden” haben wir zunächst das klassische Kata gelöst. Diesmal ging es etwas zügiger von der Hand als beim ersten Mal, was unter Anderem auch an den Wiederkehrern lag. Anschliessend ging es an die UI.

Test-Driven UI-Entwicklung. Geht das überhaupt?

Doch Halt! Wie soll denn das jetzt mit purem Test-Driven-Development gehen? Die Einsteiger waren ein wenig vor den Kopf gestossen, denn die Frage im Raum war klar: Wie kann ich Test-First eine UI für ein Programm entwickeln? Die Antwort war jedoch alles andere als deutlich.

Tom – der als einziger Experte im Einsteiger-Dojo mit dabei war, was mich besonders gefreut hat – half den Einsteigern ein wenig, indem er sagte: “Eine UI ist nicht ohne Weiteres testbar.” Die Teilnehmer vertrauten der Aussage des Profis und zuckten mit den Schultern, als es darum ging, eine Testklasse für das Windows-Form zu schreiben. Nach der von Tom im Kern korrekten Anspielung auf UI-Tests habe ich versucht, den Fokus etwas zu verschieben.

Ich stellte folgenden provokanten Satz in den Raum: “Die Benutzeroberfläche ist nicht testbar. Gut. Aber ist denn wirklich nichts testbar? Ich meine, wie ist es z.B. mit der Interaktion? Ist die Interaktion testbar?”

Dazu habe ich nochmal die Referenz-Anwendung gestartet und gezeigt, mit der Bitte, sich die Interaktionselemente der Anwendung – vielmehr die Interaktion mit der Benutzeroberfläche – nochmals genau anzusehen.

Im Wesentlichen besteht das “Spiel” aus drei Eingabefeldern (Buttons). In der Mitte wird die Zahl dargestellt, für die es die “FizzBuzz-Frage” zu beantworten gilt. Klickt man auf die Zahl, ist die Zahl die Antwort. Oben drüber und unten drunter werden die Antwortmöglichkeiten “Fizz” und “Buzz” dargestellt. Klickt man darauf, so ist selbiges die Antwort.

Abstraktion der Benutzeroberfläche zu Interaktionsanforderungen

Am Anfang war deutlich zu spüren, dass es schwer ist, eine konrektes User Interface soweit zu abstrahieren, dass man nur noch in “Interaktionen” zwischen dem Benutzer und dem Programm denkt. Auf die Frage wie denn die erste Testmethode heissen soll, “verirrten” sich einige Male ein paar Teilnehmer wieder in die konrekte UI (z.B. mit Antworten wie “ClickOnFizzButtonWhenThreeIsDisplayed”).

Doch mit ein paar kleinen Hilfen und gemeinschaftlicher Denkleistung konnten die Teilnehmer aus o.g. Interaktionsanforderungen heraus tatsächlich Tests formulieren. Genau diese Momente waren es, der dem Dojo die richtige Würze in Sachen Lerneffekt gab. So schreibten wir ohne die UI oder etwas anderes implementiert zu haben z.B. folgende Tests:

        [Test]
        public void IncrementsNumberWhenAnswered()
        {
            FizzBuzzGame fizzBuzzGame = new FizzBuzzGame();

            fizzBuzzGame.Start();
            fizzBuzzGame.Answer("1");

            Assert.AreEqual(2, fizzBuzzGame.CurrentNumber);
        }

        [Test]
        public void CorrectAnswerReturnsTrue()
        {
            FizzBuzzGame fizzBuzzGame = new FizzBuzzGame();

            fizzBuzzGame.Start();
            bool isCorrect = fizzBuzzGame.Answer("1");

            Assert.AreEqual(true, isCorrect);
        }

Deutlich erkennbar ist natürlich, dass nach wie vor die UI ansich (also das WinForm, die Buttons etc) natürlich nicht testbar sind. Aber das ist ja auch nicht der Sinn der Sache! Denn das Ziel und der Zweck von Test-Driven-Development ist nicht die Verifikation, sondern die eigentliche Entwicklung des Codes! Schnell fand die Gruppe heraus, dass die Implementierung der FizzBuzzGame-Klasse sich um ganz andere Verantwortlichkeiten kümmert, als die FizzBuzz-Klasse (der eigentliche Algorithmus).

Die Abstraktion der Interaktionen führte zur Implementierung einer Klasse mit der Eigenschaft CurrentNumber sowie den Methoden Start und Answer. Schnell waren die wichtigen Tests geschrieben und die Klasse implementiert, so dass man sich der Verknüpfung der “Interaktionsklasse” zur eigentlichen UI widmen konnte. Das Verbinden erwies sich als wunderbar einfach:

        private void buttonFizz_Click(object sender, EventArgs e)
        {
            bool isCorrect = this.game.Answer("Fizz");

            if (!isCorrect)
            {
                MessageBox.Show("Wrong answer", "Ooops!", MessageBoxButtons.OK);
            }

            this.buttonNumber.Text = this.game.CurrentNumber.ToString();
        }

        private void buttonBuzz_Click(object sender, EventArgs e)
        {
            bool isCorrect = this.game.Answer("Buzz");

            if (!isCorrect)
            {
                MessageBox.Show("Wrong answer", "Ooops!", MessageBoxButtons.OK);
            }

            this.buttonNumber.Text = this.game.CurrentNumber.ToString();
        }

Natürlich kann man hier noch wunderbar refaktorisieren und den überschüssigen doppelten Code eliminieren. Aber für’s erste soll das Mal genügen, denn jeder wollte ja sehen, ob das Spiel denn wirklich auf Anhieb spielbar war. Also schnell kompiliert und gestartet.

Tatsächlich! Es funktioniert! Die Begeisterung der Teilnehmer war förmlich aus den Gesichtern zu lesen, als wir fröhlich das FizzBuzz-Spiel Zahl für Zahl spielten… “Zwölf ist Fizz”… “Dreizehn ist Dreizehn”… “Vierzehn ist Vierzehn”… Oh! Halt. Für die Fünfzehn muss ich ja “FizzBuzz” antworten, wie soll denn das gehen?

Schnell wurde wieder die IPhone-Referenz-Anwendung gezückt und durchgespielt… “Zwölf ist Fizz”… “Dreizehn ist Dreizehn”… “Vierzehn ist Vierzehn”… und “Fünfzehn ist Fizz und Buzz”. Aha! Die “FizzBuzz” Antwort besteht also aus einem Klick auf “Fizz” gefolgt von einem Klick auf “Buzz”! Klar. Doch wie lässt sich das in unserer Anwendung lösen?

Verwirrung machte sich breit: “Wieso ist uns das beim ersten Mal nicht aufgefallen!?!” fragte man sich. Nun sei’s drum, die Beantwortung mit Hilfe von zwei aufeinanderfolgenden Klicks ist das derzeitige Problem das es zu lösen gilt. Unter anderem kam der Vorschlag, man müsse einen Timer im Form einführen, der bei dem Klick auf “Fizz” gestartet wird und auf den nächsten Klick wartet, so dass man die “FizzBuzz”-Antwort abgeben kann. Viele Teilnehmer konzentrierten sich darauf, diese Besonderheit in der UI bzw. im Code-Behind des Forms zu lösen.

Test-Driven-Development als Wegweiser

Nach einigen Minuten angeregter Diskussion kam ein Einwand von Kai: “Wir haben für die ersten Interaktionen doch Tests geschrieben, dann sollten wir das doch für diesen Fall auch können oder?”. Der Vorschlag fand sofortige Zustimmung. Also auf in die Testklasse und kräftig überlegt, wie man diese Interaktion testen kann. Das Ergebnis waren eine Reihe von Tests, die sich um den “zweistufigen” Antwort-Prozess kümmerten. Auszug:

        [Test]
        public void FizzBuzzIsAnsweredInTwoSteps()
        {
            FizzBuzz fizzBuzz = new FizzBuzz();
            Dictionary values = fizzBuzz.Count();

            FizzBuzzGame fizzBuzzGame = new FizzBuzzGame();
            fizzBuzzGame.Start();

            for (int i = 1; i <= 14; i++)
            {
                fizzBuzzGame.Answer(values[i]);
            }

            fizzBuzzGame.Answer("Fizz");
            fizzBuzzGame.Answer("Buzz");

            Assert.AreEqual(16, fizzBuzzGame.CurrentNumber);
        }

Es folgte die Implementierung der Anforderung in der FizzBuzzGame-Klasse - so wie es davor auch der Fall war. Die Lösung der Problemstellung war an und für sich trivial: Es wurde in der Klasse ein Antwort-Status eingeführt, mit dessen Hilfe man erkennen konnte, ob eine zweistufige Antwort notwendig ist und natürlich ob die zweistufige Antwort korrekt gegeben wurde.

Doch das entscheidende an dieser Herausforderung war nicht die Implementierung selbst, sondern wiederum die Erkenntnis, das uns TDD wieder einmal den Weg in die richtige Richtung gezeigt hat. Statt der ad-hoc Vorschläge, einen Timer im Form zu haben oder irgendwie den Status innerhalb des Codebehinds des Forms zu implementieren, half uns TDD, die Anforderung gekapselt in der FizzBuzzForm-Klasse umzusetzen.

Das Resultat: Keine einzige Änderung im Codebehind des Forms! Und trotzdem eine Änderung des Interaktions-Verhaltens des Spiels! Ergo: eine rundum saubere Sache: klare Verantwortlichkeiten, eine jederzeit austauschbare View (das Form), ein vollends getesteter Presenter (die FizzBuzzGame-Klasse) sowie das ebenfalls in TDD entwickelte Model (die FizzBuzz-Algorithmus-Klasse). TDD hat es den Einsteigern (wohlgemerkt keine langjährigen Entwicklungsprofis!) ermöglicht, ein gängiges und äußerst hilfreiches Pattern in der Windows-Forms-Entwicklung anzuwenden, ohne jegliche Kenntnis vom Design Pattern zu haben.

Fazit: Ein Super Dojo! Ich war wirklich begeistert, dass es uns im Einsteiger-Dojo gelungen ist, das Fundament von TDD zu vermitteln: Nicht testen um zu verifizieren, sondern testen um zu entwickeln! Gleichzeitig war das Windows-Forms-Kata ein Paradebeispiel für Seperation of Concerns und der "intuitiven" Entwicklung der Grundzüge des MVP-Patterns. Vielen Dank an alle Teilnehmer, es war Klasse!

Ich freue mich schon heute auf das nächste .NET Coding Dojo für Experten am 21. Oktober!. Das wird bestimmt wieder ein besonderer Spass. Seid dabei!

Ich hatte mir für das erste Experten-Dojo zwei Dinge auf der Agenda. An erster Stelle stand nochmals die Implementierung des FizzBuzz-Katas auf dem Programm. Nach dem Dojo hatte ja auch schon Ralf das FizzBuzz Code Kata implementiert. Also dachte ich mir, zum aufwärmen ist das bestimmt eine gute Aufgabe.

Wir haben uns an die Aufgabe im Modus “Randori” herangewagt. Ich muss sagen, für diesen allerersten Versuch, eine Code Kata per Randori zu lösen lief es erstaunlich gut. Schnell haben alle Teilnehmer festgestellt, dass es eine Übereinstimmung über die Herangehensweise der Implementierung geben muss. Die Tests waren trivial und dementprechend weniger Gegenstand der Diskussion.

Darüber hinaus war es interessant zu beobachten, dass auch bei der geballten Ladung an Kompetenz und Erfahrung die Implementierungsgeschwindigkeit sich nicht daramatisch verkürzt. (Zum Vergleich: Im Einsteiger-Dojo wurde FizzBuzz in ca. 2 Stunden gelöst, die Experten Runde hat knapp 1 Stunde gebraucht). Der Grund dafür sind vorrangig weiche Faktoren wie Teamfindung und -bildung. Aber auch fachliche Bremsspuren waren zu beobachten: Die Teilnehmer haben sich z.T. bei der Implementierung um Designfragen gekümmert – wohl mit den Gedanken der Wierderverwendbarkeit und Generalisierung im Hinterkopf. Dieser Hauch von “Design-Upfront” wurde aber schnell erkannt und ausgeräumt.

Nach einer kurzen Denk- und Verschnaufpause haben wir uns an das zweite Code Kata “RPN Calculator” herangewagt. Dabei geht es um die Simulation eines Taschenrechners, welches mit umgekehrt polnischer Notation arbeitet.

Nach der Vorstellung des Kata und der dazu gehörigen Akzeptanzkriterien ging es wieder mit Schwung los. Unterschied zum ersten Mal: Es wurde nicht sofort mit den Tests losgelegt, sondern in der Runde eine grundsätzliche Einigung über das Verständnis der Aufgabe und damit “grobe” Design der Implementierung herbeigeführt. Erst dann ging es los mit dem klassischen TDD. Test – Rot – Implementieren – Test – Grün – Refaktorisieren – Test – Grün.

Nach der Implementierung der Grundfunktionalität (die Addition und Subtraktion waren funktional korrekt), ging es ans Refaktorisieren. Hier wurden zur Beseitigung von Code-Redundanz in mehreren Methoden einer Klasse zwei Lösungsansätze verfolgt.

Template Methode

Der zweite Lösungsweg war im Gegensatz zum ersten ein ein äußerst effektiver: Die Übergabe einer Lamda-Funktion auf eine private “Template Methode”. Im Endeffekt die selbe Lösung, halt funktional statt orientiert an der “reinen” OO-Lehre:

...
public void Add()
{
    this.Calculate((x, y) => x + y);
}

private void Calculate(Func<decimal, decimal, decimal> op)
{
   /* get x somewhere */
   /* get y somewhere */

   decimal result = op(x, y);

   /* put result somewhere */
}
...

Ich möchte jetzt nicht zu sehr ins Detail eingehen – jedoch war deutlich erkennbar, dass die Teilnehmer für beide Lösungswege offen waren – abhängig vom gegebenen “realen” Kontext würde man die eine oder andere Verfahrensweise bevorzugen.

Abschliessend kann ich nur sagen, war dieser erste .NET Coding Dojo für Experten ein gelungenes Event – nicht zuletzt wegen der regen und aktiven Beteiligung der Teilnehmer. Ich finde diese Art des Lernens, Informationsaustausches und “Networkings” zunehmend attraktiv und spannend. Das macht Lust auf mehr!

Ich freue mich schon auf das nächste .NET Coding Dojo! Hier nochmal die nächsten Termine für die Dojo’s in München: am 7. Oktober das .NET Coding Dojo für Einsteiger und am 21. Oktober das .NET Coding Dojo für Experten! Auf geht’s: jetzt anmelden via Ning oder Xing! Ich bin dabei!

Besonders gut fand’ ich persönlich das Pete am Anfang besonderen Wert auf die Unit Tests gelegt hat. Dies hat allen gezeigt, wie gut und produktiv testgetriebene Entwicklung funktionieren kann. Ein weiterer dicker Pluspunkt war die Offenheit der Teilnehmer – alle waren von Anfang an bei der Lösungsfindung dabei. Es war wirklich interessant festzustellen, wie verschiedene Ansätze zum lösen der Aufgabe gesucht und gefunden wurden.

Nachdem die Grundfunktionalität des “FizzBuzz”-Generators implementiert war, hat Pete den 2. Gang eingelegt und uns alle zu ein wenig mehr OO-Design aufgefordert. Die Anforderung, “schreibe den Generator so, dass beliebig viele Bedinungen hinzugefügt werden können” hat am Anfang schon ein wenig Kopfschmerzen verursacht. Dennoch war das Team schnell auf der richtigen Fährte und hat die einzelnen Bedingungen in eigene Filter-Klassen refaktorisiert.

Ach was soll ich sagen, es war ein gelungener Coding-Abend, vor allem weil die Atmosphäre gestimmt hat und das Thema immer spannend blieb.

Danke an alle Teilnehmer, er hat wirklich Spass gemacht! Hoffentlich auf Bald in einem der nächsten Dojo’s, am 23. September 2009 Meijin für Experten oder am 07. Oktober 2009 Shinzan für Einsteiger! Ich freue mich schon auf das erste Experten-Dojo.

Let’s Code In Dojo!

Dabei sind es meist die Unternehmen, die sich schon bei der formalen Prozessadaption schwer getan haben. Eine kleine Matrix verdeutlicht dieses Dilemma:

Sowohl agile Propzesse als auch geführte Prozesse liefern gute Projektergebnisse, wenn sie verstanden sind und nicht ad-hoc oder bürokratisch umgesetzt werden. Das Problem ist hierbei allerdings, das gerade Unternehmen, die die “neuen” agilen Prozesse adaptieren, in der Transitionsphase besonders unter der limitierten Prozessfähigkeit leiden.

Genau in dieser Phase empfindet man beide Vorgehensmodelle als nicht zielführend. die Arbeitsabläufe sind chaotisch & bürokratisch gleichermaßen. Abhilfe schafft da nur die Konzentration auf ein Vorgehensmodell und die konsequente Stärkung der Prozesskenntnisse. Nur dadurch erreicht man die gewünschte Qualität & Effizienz.

Steve Sanderson beantwortet diese Fragen in seinem Unit Test Best & Worst Practices Artikel äußerst anschaulich. Ich möchte hier dennoch einen kurzen Abriss über die Fragestellung und seine Antworten geben.

Zunächst einmal sollte die Eingangsfrage geklärt werden: Wozu Unit Tests? Ganz einfach: Um konsequent stabile Software entwickeln zu können. Bei Unit Tests geht’s also nicht um Fehlerfindung (jeglicher Art), sondern um eine Entwicklungsmethode, von vornherein Komponenten einer Software funktional korrekt und technisch stabil zu entwickeln. Unit Tests helfen auch deutlich bei der Verwaltung und Veränderung von Komponenten (z.B. durch Extensions oder Refactoring), um Instabilitäten während Refactorings zu erkennen und zu beheben.

Gute und schlechte Unit Tests

Damit kommt man auch unweigerlich zur nächsten Problemstellung. Wie kann ich Unit Tests anwenden, dass Sie mir dabei helfen, stabile Software zu entwickeln? Einfacher grafragt Was sind “gute”, und was sind “schlechte” Unit Tests? Steve beantwortet diese Frage aus der TDD-Sicht. Für ihn sind Unit Tests besonders dann gut, wenn sie ausschliesslich eine funktionale Beschreibung der Software-Komponente abbilden. Das kann man natürlich besonders dann gut machen, wenn man nichts über die Art und Weise der Implementierung der Funktionalität kennt, also klassisches TDD Test-First betreibt.

Ein ebenso guter Test (welches man mit Unit Testing Werkzeugen abbilden kann) ist ein echter Integrations-Test. Bei dieser Art von Tests wird nicht die Software in ihren einzelnen Bestandteilen (Klassen, Komponenten) betrachtet, sondern als Ganzes aus der Sicht des Benutzers. Es werden funktionale Bereiche getestet, ohne die Implementierung der Software zu kennen. Diese Integrations-Tests sind besonders hilfreich Regressionen des Systems festzustellen.

Damit ist auch beantwortet, welche Unit Tests nun schlechte sind: alle anderen. Im Alltag spiegelt sich das durch Tests wieder, die zu sehr auf die Implementierung eingehen (z.B. ein *Returns_Not_Null Test), auf die technischen Elemente (z.B. ein *Db_User_Created Test) oder eine komische Mischung aus reinem Unit Test und Integrations-Test sind.

Unit Tests sind Katalysator für komponenten-orientierte Software

Die Beurteilung über schlechte und gute Unit Tests ist im täglichen Einsatz von Unit Tests immer wieder in den Vordergrund zu rücken, denn dadurch lässt sich auch einiges über das System-Design und die Software-Architektur sagen. Ein System, welches das schreiben und verwalten von Unit Tests leicht ermöglicht, bei dem die Unit Tests reine Funktionalitäten testen, bei dem Unit Tests nicht von anderen Tests oder sogar der Laufzeitumgebung abhängig sind ist ein deutlich auf den Grundkonzepten der Objekt- und Komponentenorientierung aufgebautes System. Die Kohäsion ist im Mikro-System sehr hoch, um Makro-System sehr niedrig. Ein Austausch einer Komponente ist problemlos, aber funktional immer wirkend.

Sind die Symptome jedoch, dass man für die Erstellung der Unit Tests schon Zielbereiche suchen muss, das Unit Tests nur rudimentäre fachliche Aussagen treffen oder das Verwalten der Test Suite mit zunehmender Test-Anzahl immer aufwendiger und schwieriger wird, dann kann man daraus ableiten, dass das System-Design der Software tendenziell nicht auf Komponentenorientierung ausgelegt ist. Überdies lässt sich weiter schlußfolgern, dass das System mit hoher Wahrscheinlichkeit die Prinzipien “Single Responsibility” und des “Divide & Conquer” missachtet.

Schmerztherapie Unit Tests

Besonders bei existierenden Systemen, bei denen die Weiterentwicklung strategisch wichtig ist und die ökonomische Effizienz gesteigert werden soll, sind echte, gute Unit Tests ein mittelfristig starkes Werkzeug, um das gesamte System effizienter und stabiler zu gestalten. Damit ist nicht nur die Funktionalität (Integrity) oder Defekt-Quote (Defect Rate) gemeint, sondern im Besonderen der Verwaltungsaufwand (Maintenance), die Weiterentwicklungskosten (Features) und die hochgelobte niedrige Reaktionslatenz zum Markt (Time To Market). Manchmal ist es schwer Unit Tests zu schreiben, weil man grundlegende Systemkomponenten anders aufbauen und strukturieren muss, um diese testbar zu machen.

Manchmal ist es schwer, Tests für Dinge zu schreiben, deren Implementierung nicht bekannt ist. Manchmal ist es schwer, die geänderte Grundfunktionalität in dutzenden Tests nochmals zu adaptieren. Doch am Ende wird man belohnt mit schnellerer Feature-Entwicklung und einer besonders vertrauenswürdigen, stabilen Software.

Unit Testing tut gut, auch wenn es weh tut.

Der Hands-On-Aspekt – also wenn es um das klassische “Learning by Doing” geht – ist hier leider nicht immer gegeben. Besonders .NET Einsteiger tun sich schwer und probieren Sachen zu Hause so lange aus, bis es für sie zu passen scheint. Aber auch eingefleischte .NET Cracks brauchen den Austausch mit anderen, um ihr Toolset und den Methodenraum zu erweitern.

Nach einigem hin und her, Gesprächen mit Freunden und Kollegen haben wir uns nun entschlossen, die .NET Community mit einem .NET Coding Dojo zu bereichern. Wir werden ab September jeden 1. und 3. Mittwoch von 19-21 Uhr Coding Dojos für .NET – im speziellen mit C# – veranstalten. Dabei wird der erste Mittwoch des Monats zugeschnitten sein für “Learners”, also Leute mit wenig C# und .NET Erfahrung. Der dritte Mittwoch im Monat ist der “Masters” Dojo, in dem komplexere Themen, Patterns und Toolsets behandelt werden. Bei beiden Dojos geht es natürlich um die Entwicklung in .NET und C#, halt nur auf einem anderen Level.

Übrigens, die Dojo’s wurden von uns absichtlich für extreme Levels ausgelegt. Wir sind der Meinung das gerade Anfänger die praktische Erfahrung brauchen, um sich mit der Sprache und den Tools auseinanderzusetzen und Sicherheit im Umgang mit dem .NET Framework zu haben. Gleichermaßen denken wir, dass besonders hocherfahrene .NET Entwickler den gleichen “Bedarf” an praktischem Austausch haben, um sich mit Ihren Tools und Methoden im Exzellenz-Bereich zu verbessern.

Die Dojo-Veranstaltungen werden in den Räumen von AutoScout24, Rosenheimer Strasse 143d, durchgeführt. Vielen Dank an dieser Stelle nochmal an Matthias Patzak von AutoScout24, der uns die Räume und organisatorischen Grundlagen zur Verfügung stellt.

Die erste Veranstaltung findet am 9. September statt und ist das erste Beginners Dojo, geleitet von Pete. Für Anmeldung zu den Veranstaltungen, Kontakt, Austausch von Code & Anregungen einfach zur MucNetDojo Group oder eine Email an die Gruppe schicken.

Auf einen Blick, Fragen & Antworten

F: Was ist ein Coding Dojo?
A: Ein coding Dojo ist eine Session, in der alle gemeinsam eine Programmieraufgabe lösen. Siehe: http://codingdojo.org

F: Wann findet das .NET Coding Dojo in München statt?
A: Jeden 1. und 3. Mittwoch. Der 1. Mittwoch für “Starter” (Unerfahrenere), der 3. Mittwoch für “Master” (Experten)

F: Wo kann ich mich anmelden?
A: Viele Wege führen zum Ziel

• Einfach Kommentar auf diesen Artikel schreiben, oder
• über die Google Gruppe http://groups.google.com/group/mucnetdojo (Gruppenverteiler), oder
• über die XING-Event Liste
  Starter: https://www.xing.com/events/net-coding-dojo-munchen-starter-386036
  Master: https://www.xing.com/events/net-coding-dojo-munchen-master-386038

F: Wo und wann ist die erste Coding Dojo
A: Mi, 9. September 2009, AutoScout24, Rosenheimer Strasse 143d

Also, Spread the word und auf geht’s!

Dark-G-Blue

Am Arbeitsplatz verliere ich leider die Settings immer wieder durch das Hopping von Rechner zu Rechner. Da hilft nur eines – konsequent nachinstallieren bzw. die Settings immer griffbereit haben.

Letztens war es wieder einmal soweit – das grell-weisse Visual Studio hat meine Augen zu sehr penetriert. Also Farbschema laden und – endlich! Ruhe am Screen. Kurzerhand habe ich gleich mal ein paar kleine Optimierungen an den Farben vorgenommen – so habe ich auch das Highlighting und debugging verbessert.

Das Farbschema zum Download: Dark-G-Blue Visual Studio 2008 Color Scheme.

PS: Jep, nach langen Wochen wieder ein Blog-Eintrag. Ich habe mir eine etwas längere Pause gegönnt – schliesslich sind Geeks auch Menschen. Die Pause ist vorbei und ich freu’ mich schon wieder auf .NET, Entwicklung, Architektur und die restlichen digitalen Finessen :-)

Genauer gesagt ist es Uncle Bob, der mit seinem provokanten Satz “Craftsmanship over Crap” auf der Agile’08 die Diskussion angestoßen hat. Natürlich spielt da auch sein Buch Clean Code eine besondere Rolle. Im Prinzip regt sich Uncle Bob darüber auf, das heutzutage immer mehr Agile Software-Entwicklung mit “schnell fertigstellen”, “mal ändern” und “iterativ ausbauen” gleichgesetzt wird, ohne wirklich qualitativ wertvolle Ergebnisse abzuliefern.

Er spricht mir aus der Seele. Wie oft habe ich schon einfach runtergerotzten Code gesehen, wo nichts anderes zu erkennen war außer einem Haufen zusammengelegter Klassen und Methoden. Wie oft habe ich diesem bescheuerten Satz “das wurde mit der heißen Nadel gestrickt” gehört, wo ich mir selbst die Frage stellte, ob ich nun in einer Arbeitsgemeinschaft für Strickpulli-Anfänger gelandet bin oder ich doch noch in der Software-Branche bin.

Das erschreckende ist ja nicht nur, dass diese “agilen” Software-Produkte nicht nur durch den Druck von Geschäftsleuten, Produktmanagern oder sonstigen “Stakeholder”n getrieben wird. Mittlerweile ist die niedrige Qualität schon in das Innere von Software-Entwicklern vorgedrungen. Es gibt Kollegen, die kümmern sich einen feuchten um qualitativ hochwertige Ergebnisse, sondern verfolgen stur das, was man Ihnen vor die Nase legt. Erstaunlicherweise ist es meist dieser Typus Entwickler, der sich dann auch noch als “State-of-the-Art”-Developer verkauft, weil er “business-minded” und “agile” ist. Das Fass zum überlaufen bringt dann meistens die Argumentation, dass man heutzutage ja “iterativ” und “test-driven” entwickelt, und dabei wirklich nur das notwendigste implementiert.

Also nicht, das man mich jetzt falsch versteht: das soll jetzt keine Hommage an den alten Wasserfall werden. Mittlerweile ist es klar, das man Software-Entwicklung iterativ wesentlich besser vorantreiben kann. Auch viele Patterns und Practices beschäftigen sich mit der Verbesserung der Entwicklung und der Qualität. Fakt ist allerdings auch, dass durch die rasante Entwicklung der Methoden, der Branche, des “Businesses” durch das Web und nichtzuletzt durch die zahlreichen Tools die eigentliche Schule der Entwicklung von Software immer mehr vernachlässigt wird.

Da kommt meiner Meinung nach die von Uncle Bob initiierte Bewegung genau zur richtigen Zeit. Mit vielen anderen Software-Entwicklern, die noch die Fahne der Kunst hochhalten, hat er das “Manifesto for Software Craftsmanship“ ausgearbeitet. Es ist eine Analogie – oder besser ein Addendum – zum klassischen Agile Manifesto:

• Es geht nicht nur um funktionierende Software, sondern auch um gut entwickelte Software
• Es gilt nicht nur Änderungen zu verarbeiten, sondern auch um stetige Wertsteigerung
• Es verlangt nicht nur Austausch von jedem Einzelnen, sondern auch Zusammengehörigkeit durch Gruppenbildung von Profi’s
• Es braucht nicht nur Kundenkommunikation, sondern auch eine produktive Partnerschaft

Genau diese Werte sind es, die einen Software-Entwickler zu einem guten Software-Entwickler machen. Naja, ganz neu sind diese Wertvorstellungen ja nicht, zumal man ja schon vor Jahren relativ formal mit Hilfe der ISO 9126 Qualitätsrichtlinien einen Ansatz gefunden hat, eine “Qualitäts- und Professionalitätsethik” abzuleiten. Noch einen Schritt weiter geht da die (mittlerweile auch schon einige Jahre alte) Definition der Code Of Ethics in Software Engineering von ACM.

Nichtsdestotrotz ist die neue Craftsmanship-Bewegung notwendig und wichtig. Dem tragen auch Ralf Westphal und Stefan Lieser Rechnung, in dem sie auf ihrer neuen Website clean-code-developer.de ein an Uncle Bob angelehntes Wertesystem beschreiben. Dieses Wertesystem beinhaltet eine Reihe von guten Regeln und Vorschlägen, wie man als Software-Entwickler sein Werk und Tun verbessern kann. Ich persönlich finde das von Westphal & Lieser propagierte “Grad-System” (ähnlich wie bei Judoka) nicht zielführend. Es ist vielmehr irreführend und transportiert implizit das “ich habe den blauen Grad, also bin ich besser als Du” Gefühl, obwohl dies bestimmt nicht so gemeint ist. Also ich werde sicherlich kein “Clean Code Developer”, ich sehe mich eher als ein “Software Craftsman”. Nichtsdestotrotz findet man auf der Website gute Ratschläge.

Was für mich zählt, ist die Tatsache, das ich immer versuche, eine bessere Arbeit abzuliefern als je zuvor. Ich bin stolz auf meine Arbeit und meinen Beruf.

Session 1: Steve Teixeira über Multi-Core Software-Entwicklung

Steve Teixeira ist Program Manager beim Parallel Developler Tools / Visual Studio Team in Redmond und hatte in seiner Session neben der grundlegenden Einführung der neuen API für Multithreading auch einige Neuigkeiten über die nächste Visual Studio Version zu berichten. Doch alles der Reihe nach. Zunächst einmal schilderte Steve, wieso man sich eigentlich Gedanken über Parallele Ausführung von Code machen sollte. Der Grund ist natürlich bei der Hardware-Entwicklung vergraben, denn mittlerweile gelangt man an die Leistungsgrenzen im CPU-Design mit einem Kern. Der Hauptgrund ist die inzwischen fast unkontrollierbare Wärmeleistung, die die Chips von sich geben. Der Trend ist zu Multi-Core-CPU’s ist eindeutig auch im Alltag angekommen.

Das wiederum macht es erforderlich, die Software auf die neuen Gegebenheiten anzupassen. Steve zeigte ein schönes Beispiel mit Hilfe von PLINQ um die Unterschiede zwischen sequentiellem und parallelisiertem Code deutlich zu machen. Was heißt das für den “Alltags-Entwickler”, wie ich es z.B. bin? Nun, zunächst einmal bedeutet es eine Schärfung der Coder-Sinne auf das Thema Performance. Ich fühle mich zwar in diesem Thema schon heute gut aufgehoben, aber es dürfen ruhig noch ein wenig mehr Details sein.

Unterstützt wird dies im Besonderen durch das neue Visual Studio 2010. Es kommt mit neuen Tools wie Performance und Concurrency Profilern, die deutlich, graphisch anschaulich zeigen, wieviel Zeit die Software für bestimmte Aktionen verbraucht und mit welchen Ressourcen diese Leistung erreicht wurde. Auffällig dabei sind auch die Optionen, die das neue Performance-Tool bietet: CPU-basiertes Sampling, komplette Instrumentation, also Analyse aller Zeiten und Zyklen von Methodenaufrufen und das schon eben erwähnte Concurrency Profiling, mit dem man in der Lage ist zu erkennen, wie die Threads mit den Aufgaben ausgelastet sind.

Eine “Performance Debugging Suite” also, die im neuen Visual Studio verankert sein wird. Voraussetzung ist jedoch die Installation auf Windows Vista oder Windows 2008, da die Monitoring-Tools intern eng mit der seit Vista erweiterten Windows Eventing API (ETW) zusammenarbeiten.

Für so passionierte .NET-Entwickler wie mich ist die Verwendung der neuen API einfacher als erwartet. So lassen sich z.B. LINQ-Abfragen elegant mit dem “Anhängsel” .AsParallel() parallelisieren. Mindestens genauso einfach lassen sich auch Codebestandteile für die Parallel-Ausführung trimmen. Eine einfache for-Schleife ist mit Parallel.For() im Nu für die Parallelisierung umgesetzt. Die Nebeneinanderausführung von separaten Codeteilen mit Parallel.Invoke() ist zügig definiert und intuitiv. All diese Dinge sind fest im neuen .NET Framework 4.0 verankert. Interessant in diesem Zusammenhang ist, das Steve explizit auf deutliche Verbesserungen “unter der Haube” hingewiesen hat. So ist z.B. die ThreadPool-Klasse intern mit neuen Strategien wie dem Work Stealing ausgestattet worden, um die Verteilung der Aufgaben in Multi-Core Umgebungen zu optimieren.

Ein helles Ohr hatte ich auch bei den vielen kleinen Anekdoten und Anmerkungen von Steve. So ging er flüchtig auf die Entwicklung von Visual Studio ein und verriet, das der Visual Studio Code mehrheitlich in C++ und C# geschrieben ist und derzeit mehr als 45 Millionen Codezeilen umfasst. Interessant ist auch die Tatsache, dass das Visual Studio Team bei der Entwicklung von neuen Komponenten und UI verstärkt WPF im Einsatz hat. Steve begründet das mit der schlichten Tatsache, das WPF schnell genug ist und eine wesentlich effizientere UI-Entwicklung ermögliche als mit der klassischen GDI.

Fazit: Ein absolutes Highlight – Visual Studio 2010 in Aktion und Insider-Wissen. VS10, Parallels & .NET 4.0, ich warte auf euch…

Session 2: Holger Schwichtenberg und AJAX Services

AJAX ist nicht nur in aller Munde sondern heutzutage schon fast auf jeder Website in irgendeiner Form im Einsatz. Das man AJAX auch in ASP.NET einsetzen kann, ist spätestens nach dem .NET Framework 3.5 keine besondere Neuigkeit mehr. So auch der Inhalt der Session von Holger. Er machte einen knapp einstündigen Rundflug über die Möglichkeiten des AJAX-Einsatzes in ASP.NET, darunter das berüchtigte UpdatePanel (aka. AJAX für Arme), das AJAX Control Toolkit (aka. Atlas) und die kleinen Tools, die mit den ADO.NET Data Services einhergehen.

Auf AJAX-Spezifische News für .NET 4.0, den JQuery-Support mit ASP.NET 4.0 oder Visual Studio 2010 ging Holger garnicht oder nur am Rande mit einem Keyword aus einem Slide ein. Schade, aber aus meiner Sicht eine sehr schwache und fachlich “äußerst überschaubare” Session. Besonders die Argumentationen von Holger für so manche Technologie sind in meinen Augen etwas zu oberflächlich. So geschehen bei einer Frage eines Zuhörers:

Zuhörer: Bei den ADO.NET Data Services verzichten Sie auf eine gewohnte 3 bzw. N-Tier Architektur. Dies wurde lange als “Best Practice” vermittelt und nun wird das mißachtet. Was meinen Sie?

Schwichtenberg: Nun, ich sage Ihnen ja nicht, das eine N-Tier Architektur nicht empfehlenswert ist. Aber – mit ADO.NET Data Services ist der Betrachtungswinkel ein anderer. Während “klassische” Web Services nur die Daten und Funktionen herausgeben, die wirklich benötigt werden – also praktisch die Daten schon serverseitig Filtern – wird bei den ADO.NET Data Services zunächst der gesamte Datenbestand im Web Service angeboten. Der Client kann nun über die REST-Query entscheiden, was er konkret benötigt. Aus meiner Sicht ist diese Herangehensweise ein Produktivitätsgewinn.

Na, das ist ja eine feine Aussage! Sichereitsbedenken scheint Holger nicht zu haben, wenn er alle Daten frei verfügbar macht. Des Weiteren ist die Konstellation AJAX + ADO.NET Data Services + Entity Framework sehr wohl eine “Tiered Architecture”, Das Entity Framework löst den klassischen Data Layer ab. Die Data Servies können als “Business Layer” durchgehen (man kann ja selbst noch einiges dazu entwickeln und der Zweck eines “Data Providers” kann in meinen Augen auch als “Business” definiert werden). Zu guter letzt ist AJAX bzw. die Website die UI bzw. das Frontend. Naja, vielleicht habe ich es auch nicht richtig kapiert, was Holger damit gemeint hat.

Fazit: Eine der schwächeren Sessions, die fachliche Tiefe und vor Allem Neuigkeiten bzw. Best Practices vermissen ließ.

Session 3: Dariusz quatscht hessisch, und zwar “Windoos Äschär”

Der Name ist Programm: Dariusz wagt sich in die neue blaue Windows-Welt: “Windoos Äschär” – so meint er könnte man es zumindest versuchen, die neue Service-Familie auszusprechen. In wohl bekannter Manier stieg er fröhlich in die Thematik mit einem Überblick ein.

Da wären zunächst die .NET Services “Access Control”, “Service Bus” und “Workflow”. Der Access Control Dienst so etwas vergleichbares wie ein etwas besserer, Claims-basierter Single-Sign-On Service mit Authorisierungsmanagement. Über eine Claims-Challenge können sich Nutzer und Dienste gleichermaßen authentifizieren. Dabei kann man aus der gewohnten Variabilität der Authentifizierungsart wählen – ob nun UserNamePassword, Zertifikate, Windows Live ID – Claims bleibt Claims. Der Service Bus ist der aus größeren Unternehmen bekannte ESB portiert auf die “Cloud”. Mittelfristig soll mit dem Service Bus eine “orchestrierte” Gemeinde von Diensten zur Verfügung gestellt werden. Das Pattern ist jedenfalls nicht neu. Der dritte im Bunde ist der Workflow Dienst. Basierend auf der WF kann er als “Schaltzentrale” verwendet werden. Momentan ist dieser Baustein noch sehr rudimentär, soll aber weiter ausgebaut werden.

Eine weitere Service-Gruppe ist die “SDS” – die SQL Data Services. Gleich zu Beginn klärt Dariusz hier den Unterschied zwischen “Azure Storage” und den “echten” SQL Diensten. Während die Storage eher eine “einfache, sqlfähige Datenablage” ist, sollen die SDS mittel- bis langfristig wesentlich mehr Features anbieten wie z.B. Reporting, Data Mining oder ETL Dienste. Gewöhnungsbedürftig bei den SDS ist die Organisation der Daten: Man hat nicht mehr die klassischen, relationalen SCHEMA TABLE ROW Strukturen. Statt dessen befinden sich die Daten in sog. “Containern” (vergleichbar mit Datenbanken oder Schemata). Die Daten wiederum sind als “Entities” strukturiert. Eine Entity hat mindestens einen Typ (also den Entity-Namen), eine EntityID und den EntityKind, welche Aussage über die Art oder Klasse der Datenstruktur geben soll. Weitere Felder sind frei definierbar. Die Feldtypen beschränken sich derzeit nur auf einfache Datentypen.

Auf weitere Dienst-Gruppen ist Dariusz nicht eingegangen – wie sollte er auch – er hatte während der Session mit anderen Problemen zu kämpfen. Jede zweite Demo ging nicht oder brach mit irgendwelchen Exceptions ab. Tja, er musste selbst zugeben, das “Äschär” noch nicht ganz fertig ist und an der einen oder anderen Stelle die notwendige Reife für den produktiven Einsatz vermissen ließ.

Der erste Eindruck den Windows Azure und die “SOA-Diensten” hinterlassen ist das Interesse an Neuem mit einer großen Portion Skepsis. Auch wenn irgendwann einmal Azure stabil und schnell wird bleibt abzuwarten, ob die Plattform attraktiv und intuitiv genug ist, um echte Anwendungen darauf laufen zu lassen.

Fazit: Mal sehen was daraus wird!

Session 4: Dirk Primbs schreibt effizienten Code in C# 3.0

Dirk ist eines der bekanntesten Gesichter auf Konferenzen – kein Wunder, schließlich ist er seines Zeichens Developer Evangelist bei Microsoft. Die heutige Session hatte die Überschrift “Effizienter Code in C# 3.0″ – das hörte sich vielversprechend an. Also dachte ich mir, wenn ich schon nicht in die Session von Berndt gehen kann (er war leider nicht anwesend und wurde durch Dariusz vertreten), dann höre ich mir mal an, was Dirk mir über Effizienz mit C# 3.0 zu erzählen hat.

Leider war nicht ganz in dem Paket drin was draufstand. Dirk verbrachte über die Hälfte der Zeit damit, die Geschichte von .NET und C# zu erzählen. Angefangen bei C# 1.0, über C# 2.0 bis zum aktuellen C# 3.0. Die aktuelle 3.0-Version kam dabei für meine Begriffe viel zu kurz. Dirk vermittelte in seiner Retrospektive über C# 2.0 sehr gut, was Generics, Anonymous Methods und Discrete Property Accessors sind. Doch besonders prickelnd war es nicht gerade, mittlerweile gängige Konstrukte nochmals vorgekaut zu bekommen. Mit C# 3.0 hatte das wenig zu tun, und mit effizientem Code auch nicht.

Wahrscheinlich habe ich mir unter dem Titel “Effizienz” etwas anderes vorgestellt als Dirk. Er ging auf Syntax und “eleganten” Code ein, wo ich eher Effizienz-Vergleiche zwischen konkrekten und anonymen Typen erwartet hätte. Dennoch war es nicht langweilig – wer Dirk schon öfter erleben durfte, der weiß warum.

Es blieb am Ende doch noch eine gute Viertelstunde übrig, um auf neue Sprachkonstrukte und Features von C# 3.0 einzugehen. Type Inference und das var Keyword, Object Initializer und Automatic Properties. Wie zu erwarten war, wurde die Verwendung des var Keywords “angeregt” diskutiert. Ich hatte mich in einem Post ja schon über den Sinn und Zweck von var geäußert. Äußerst bedauernswert fand ich allerdings, das kein Sterbenswörtchen über C# 4.0, die DLR, das dynamic keyword oder Duck Typing verloren wurde. Zumindest ein Ausblick und ein kurzer Rundflug wäre schön gewesen.

Fazit: Eine Mischung aus “Basics Workshop”, Human FxCop und OpenSpace Talk – locker, bekömmlich, bekannt.

Soviel zum ersten Tag. Mal sehen, was der zweite bringt… :-)

Meine Session-Auswahl für den ersten Tag:

• Bringing out the best in Multicore Systems, Steve Teixeira
• AJAX-Live im Services Zeitalter, Holger Schwichtenberg
• Software-Entwicklung mit Windows Azure, Dariusz Parys
• Parallel Extensions für Microsoft .NET, Bernd Marquardt

Mal sehen, welche Erkenntnisse bis zum Abend gewonnen werden können.

Aber bevor man sich dem “Management” einer Sache annimmt, sollte man definieren was diese Sache – also das Projekt – überhaupt ist. Da wären zum einen eine Reihe von formalen, klassischen Definitionen. Die gängigste ist wohl die des PMI:

“Ein Projekt ist ein zeitlich begrenztes Vorhaben, das unternommen wird, um ein einmaliges Produkt, eine Dienstleistung oder ein Ergebnis zu erzeugen.”

Project Management Body of Knowledge (PMI)

Um es also in deutlicheren Worten zu sagen: Ein Projekt ist prinzipiell alles, um ein bestimmtes Ziel in einer bestimmten Zeitspanne mit bestimmten Mitteln zu erreichen. Aus der “Entwickler-Brille” betrachtet kann also ein Projekt alles mögliche sein: Ein Bug-Fix, ein Change-Request, eine Komponente, ein Mini-Tool, eine Website, ein Framework oder eine super-duper Mega-Anwendung. Das ist für meinen Geschmack (und den vieler anderer) etwas zu schwammig, denn wenn alles ein Projekt wäre, müsste man alles auch managen – das ist offensichtlich zuviel des Guten.

Also müssen weitere Kriterien herangezogen werden, um ein “Vorhaben” und die damit verbundenen Maßnahmen als “Projekt” zu rechtfertigen. In der Software-Entwicklung gibt es eine einfache Faustregel, um Vorhaben & Aufgaben nach einer bestimmten “Komplexität” für ein Projekt auszusieben:

Die “3 mal 1 Projekt-Regel”

Alle Vorhaben oder Aufgaben, die offensichtlich

• länger als einen Tag andauern können, oder
• mehr als eine einzelne Aktion erfordern, oder
• mehr als eine Person beschäftigt

sind Projekte.

Dieser sehr groben Faustregel ist natürlich nicht strikt zu folgen, sondern eher als richtungsweisende Orientierungsregel zu verstehen und hat sich eigentlich gut bewährt. Das Fatale an dieser Regel ist natürlich, dass es potenziell viele kleine Mini-Projekte verursacht – aber das sei für’s Erste mal ausser acht gelassen. Prinzipiell gilt: Ein Projekt hat eine Zielvorgabe, eine Zeitvorgabe und natürlich die Personen & Mittel, die diese Vorgabe in der “gegebenen” Zeit umsetzen sollen.

Hat man nun ein Projekt definiert – also sich ein Ziel gesetzt, welches man bis zu einem bestimmten Datum erreicht haben will, geht es um das Management des Projektes. Auch hier gibt es wieder eine Menge an trockenen Definitionen dafür, was Projektmanagement eigentlich ist. Hier die Definition nach DIN-Norm:

“Projektmanagement ist die Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Abwicklung eines Projektes.”

DIN 69901

Eine in meinen Augen äußerst “harte” Defintion. Demnach braucht ein Projektmanager eigentlich nichts anderes zu tun, als alle Projektbeteiligten und das Projekt selbst zu “führen”. Ein Projektmanager ist also für ein Projekt eine Führungskraft. Meiner Meinung nach ist da mehr dahinter – oder besser gesagt, eigentlich etwas ganz anderes. Intuitiv stellt man sich dabei nämlich die Frage: Was muss man denn eigentlich bei einem Projekt alles “verwalten” ?

Was macht eigentlich ein Projektmanager ?

Genau hinter dieser Frage versteckt sich das eigentliche Dilemma des Projektmanagements. Abhängig von der Größe, der Dauer, der Inhalte, der Umsetzung, des Teams, der Investitionen und vielem Anderen mehr kann oder muss man besonders viele oder besonders wenige Verwaltungs- und Organisationsmaßnahmen durchführen. Das gesamte Betätigungsfeld eines Projektmanagers ist dermaßen variabel und abhängig vom Projekt, dass man es kaum greifen kann.

Trotz dieser ausgesprochen hohen Variabilität versucht man beim Projektmangament, alles mögliche zu organisieren, zu strukturieren, zu planen oder gar zu reglementieren. Das macht man natürlich nicht aus Spaß, sondern primär um die Zielvorgabe des Projektes zu realisieren – also ein Projekt erfolgreich durchzuführen. Im “klassischen” Projektmanagement gibt es da verschiedene Leitfäden, wie z.B. das Magische Dreieck, die Projektumfeldanalyse oder das sagenumwobene Teufelsquadrat.

Ich möchte noch ein klein wenig bei der bis dato sehr allgemeinen und abstrakten Betrachtungsweise des Projektmanagements bleiben, bevor ich die Dinge auf die Software-Entwicklung konkretisiere. Denn aus meiner Sicht kann man ganz allgemein unter Projektmanagement einfach die Aufgaben verstehen, allen Beteiligen

• die benötigten Informationen zu liefern,
• die notwendigen organisatorischen Maßnahmen (bzgl. Meetings, Listen, Dokumente) zu übernehmen,
• bei der Bewältigung von technischen, sozialen oder anderweitigen Problemstellungen zu helfen,
• den Überblick über das Projektgeschehen zu haben und zu vermitteln.

Betrachtet man meine obige “naive” Beschreibung des Projektmanagements näher, stellt man fest, dass die Aufgaben sich stark dem Aufgabenbereich z.B. eines Sekretärs oder einer ähnlicher Bürokraft annähern. Insofern ist die Aussage für mich zulässig, dass ein Projektmanager für ein Projekt und alle Beteiligten im positiven Sinne nichts anderes als eine Hilfskraft darstellt.

Ich möchte keineswegs den Berufsstand oder die Kompetenzen des “Projektmanagers” dadurch mindern – aber dennoch klar feststellen, das Projektmanagement in erster Instanz nichts mit Mitarbeiter- oder Teamführung zu tun hat.

Projektmanagement in der Software-Entwicklung

Vielmehr beschäftigt sich ein Projektmanager mit Kennzahlen, Analysen oder Rahmenbedingungen wie z.B. Zeit-, Ressourcen- und Budgetplanung. Das ist vor Allem in der Software-Entwicklung eine nicht zu unterschätzende Aufgabe, schließlich ist Software ein “weiches”, während der Konstruktion schwer greifbares Produkt.

Hier kommt ein in meinen Augen ganz wesentlicher Aspekt, den jeder Software-Projektmanager im Fokus haben sollte: Die Arbeit am Produkt und das Produkt so gut wie möglich “greifbar” zu machen. Greifbar nicht nur im Sinne von Metriken für Fortschritt, Dauer, Leistung, Fehlerquote oder ROI. Nein, ich meine überdies andere Dinge, wie z.B. die Visualisierung des Produktes in Form von Continuous Build / Integration, Test- oder Betaversionen, klare Anforderungs- und Informationskanäle mit geeignetem und auf das Team abgestimmten Toolset, leicht verständliche, einfache Prozesse zur Organisation der Arbeitsabläufe oder konkrete Koordinationsunterstützung mit Hilfe von Meetings, Zusammenfassungen und Dokumentationen.

Leider ist es oftmals der Fall, das Projektmanager aber auch andere Dinge tun. Ein besonderes Steckenpferd scheint dabei das Mitwirken bei technischen Entscheidungen zu sein. Manchmal geht das sogar soweit, das der Projektmanager die Richtung geradezu vorgibt. Man mag argumentieren, das in der Software-Entwicklung öfters Projektmanager schon eine “Entwickler-Vergangenheit” nachweisen können. Das alleine rechtfertigt eine technische Mitbestimmung meiner Meinung nach noch lange nicht.

Im Gegenteil, es wird dadurch für Entwickler und Manager nicht einfacher – während der Entwickler dem Manager mangelnde Detailkenntnisse entgegenwirft, entgegnet der Manager dem Entwickler seine Einschätzung zu Aufwendungen und Vorgehensweisen. Ich bin mir sicher, das viele Entwickler schon die Sätze “Der Bugfix dauert niemals so lange”, “Das kann man doch einfach runter programmieren” oder “In PHP ist das ganz easy” aus dem Munde des Projektmanagers gehört haben. Diese Aussage sollte nicht missverstanden werden – jeder Projektmanager darf und kann aus einer “Entwickler-Vergangenheit” Vorteile und Erfahrungen in seine jetzige Aufgabe einbringen – nur das “Wie?” ist entscheidend.

Abgesehen davon legen manche Projektmanager besonderen Wert darauf, die anstehenden Aufgaben den Entwicklern zuzuweisen und aktiv an der Arbeitsaufteilung mitzuwirken. Der Projektmanager hat zugegebenermaßen den “Überblick”. Aus seiner Perspektive ist er also im Idealfall wie ein Schachspieler, der das Spielfeld bzw. die Spielsituation überblickt und entscheidet, welche Spielfigur für den nächsten Zug eingesetzt wird und wie sich dadurch die Spielsituation verändert.

Die Fehleinschätzung dabei ist aus meiner Sicht schlicht und einfach die Tatsache, das man Software-Entwicklung nicht mit Schach vergleichen kann. Im Schach gibt es einen Gegner, kein Zeitdruck, keine Korrektur des Spielzugs, keine variable Leistung der Spielfiguren, keine äußeren Einflüsse und ein festes Reglement.

In der Software-Entwicklung jedoch gibt es all dies nicht. Dafür spielen andere Faktoren eine große Rolle. Das Know-How jedes einzelnen Entwicklers, die technologische Plattform, die Anforderungen und Wünsche des Kunden und vieler Abteilungen, die Altlasten, Fehler und Wartungsmechanismen, das Teamwork der Entwickler. Insofern ist es geradezu eine Überheblichkeit, das ein Projektmanager sich selbst zumutet, die Einschätzung über Aufgabenverteilung zu übernehmen oder zu steuern.

Aliges Software-Management: Rettung oder Untergang ?

Nun, mittlerweile ist in nahezu jeder professionellen Software-Entwicklung das Thema “Agile Software-Entwicklung” angekommen und wird auch schon breit praktiziert. Methoden wie Scrum oder Crystal bringen neue Denk- und Arbeitsweisen ins Management. Das interessante an den agilen Ansätzen ist die latente Ignoranz der klassischen Projektmanager-Rolle gegenüber. So ist z.B. in Scrum weit und breit kein Projektmanager in Sicht. Statt dessen gibt es Scrum Master und Product Owner. Es liegt die Schlußfolgerung nahe, das man ja eigentlich gar keinen Projektmanager benötigt.

Die Wahrheit liegt wie so oft in der Mitte. Obwohl es bei agilen Managementmethoden wie Scrum keine “echten” Projektmanager gibt, gibt es sie doch. Die “Reinkarnation” des Projektmanagers kommt dabei in vielschichtigen Formen. Der Scrum Master ist so eine Reinkarnation – er übernimmt klassische technische und soziale Teamaufgaben und hilft bei Koordination und Organisation. Der Product Owner kümmert sich um das “geschäftliche”, also Kunden, Anforderungen, Budgets und zeitliche Abläufe. Die übrigen Aufgaben des Projektmanagements werden auf das gesamte Team verteilt. Doch der Projektmanager als Person ist von der Bildfläche verschwunden.

Wenn man diese “reine Scrum-Lehre” in größeren Projekten oder Organisationen umsetzt und lebt, stellt man schnell fest, das Scrum kein einfaches Management-Modell ist. Die “Eliminierung” des Projektmanagers aus dem Vorgehensmodell bürdet den bleibenden Rollen automatisch Teilaufgaben eines Projektmanagers auf. Nach einigen Monaten spürt jeder in einem Scrum-Team, das das managen von Projekten keine leichte, erquickende Aufgabe ist. Obgleich es eine gute Idee ist, die Verantwortung des Projektes auf mehrere Schultern zu verteilen und das Team durch das gemeinschaftliche Verantwortungsbewusstsein zu stärken, ist deren Umsetzung ungleich schwerer.

Master oder Owner, das ist hier die Frage

An dieser Stelle möchte ich nicht zu tief in die Unwegsamkeiten und Potenziale von Scrum eintauchen und den Blick wieder auf den klassischen Projektmanager und dessen Aufgaben fokussieren. Einem Projektmanager bleibt in agilen Projekten und Modellen wie z.B. Scrum eigentlich nur die Wahl, sich für eine der Rollen (Scrum Master oder Product Owner) zu entscheiden. Die meisten wählen den Pfad des Scrum Masters – auf den ersten Blick scheint der Scrum Master mehr mit einem Projektmanager gemein zu haben als der Product Owner.

Die Entscheidung, ob der originäre Projektmanager ein Scrum Master oder Product Owner werden soll, ist meiner Meinung nach eine Frage des menschlichen Charakters und der Fähigkeiten. Die essentielle Entscheidungsgrundlage ist dabei die Erkenntnis eines wichtigen Unterschieds zwischen Scrum Master und Product Owner: Während der Scrum Master ein “Projektbegleiter” ist, ist der Product Owner ein “Projektführer”. Der eingangs erwähnte klassische Anspruch, das ein Projektmanager “Führungsaufgaben” übernimmt, wird in Scrum eher dem Product Owner zugeschrieben. Der Scrum Master allerdings ist der “Begleiter”. Er deckt die Sicht des Entwicklers auf den Projektmanager, worin dieser wie schon beschrieben nur “Miittel zum Zweck” oder eine Hilfskraft darstellt.

Ist also ein Projektmanager stark in den Disziplinen Kundenkontakt, Analyse, Steuerung, Budgetierung und hat das “Führungs-Gen”, dann sollte er sich mit der Rolle des Product Owners anfreunden. Ist er jedoch stark bei technischer Kenntnis, sozialem Umgang, Hilfsbereitschaft, Metriken und Dokumentation (siehe Servant Leadership), ist für Ihn wohl eher der Scrum Master ein geeignetes Tätigkeitsfeld.

Einsichten & Erkenntnisse

Aus all diesen Gedanken heraus erschließt sich für mich die Erkenntnis, das die klassische Rolle des Projektmanagers ausgedient hat – ja sogar mittel- bis langfristig zum Aussterben verurteilt ist. Denn für Software-Unternehmen ist es entscheidend, Projekte und deren Durchführung stetig zu verbessern – also besser steuern, kontrollieren und hervorsagen zu können. Die “Zertrümmerung” der Aufgaben, Wirkungsbereiche und Verantwortlichkeiten eines klassischen Projektmanagers in verschiedene, spezialisierte “Unter-Rollen” ist dabei für mich eine normale, evolutionäre Entwicklung. Die Dezentralisierung des Managements parallelisiert die Durchführung der Aufgaben, beschleunigt die Teilumsetzung bei gleichzeitiger Optimierung durch Spezialisierung.

Natürlich bleibt die Gefahr des Scheiterns bei diesem agilen Modell, ist aber durch die Diversifikation der Aufgaben auf die einzelnen Rollen im Vergleich zum klassischen Modell minimiert. Besonders herausfordernd sind die Bereiche Kommunikation und Koordination. Nur durch eine abgestimmte Kommunikation und einfache, prägnante Koordinationsregeln kann aus der Aufgabenteilung ein direkter positiver Effekt erreicht werden.

Für den “klassischen Projektmanager” heisst das nicht, das er schwere Zeiten vor sich hat. Im Gegenteil, Projektmanager können und sollten diese Entwicklung für sich nutzen und sich für die einzelnen Teilaufgaben spezialisieren. Zumindest gilt das für die operative Ebene. Für besonders kompetente und erfahrene Projektmanager tut sich ein neues Tätigkeitsfeld auf, denn durch die Dezentralisierung der Aufgaben entsteht der Bedarf des koordinierten Bündelns und Steuerns der operativen Teile aus der strategischen Ebene heraus.

Ich als Entwickler freue mich für meine Kollegen, denn für die Entwickler bedeutet dieser Schritt zur Optimierung des Managements mehr Verständnis und aktive, effektive Unterstützung auf Entwicklungsebene. Die Informationskanäle werden durch Konsolidierung geringer und man kann sich besser auf seine Aufgaben konzentrieren. Des Weiteren wird der Entwickler mehr in die Verantwortung für seine Tätigkeit genommen. In den meisten Fällen geht das einher mit einer gesteigerten Anerkennung der Leistung des Entwicklers bei gleichzeitiger Professionalisierung im Sinne von Mitwirkung, Kommunikation und Detailplanung.

Es bleibt spannend!

Anfangs war ich vom Einsatz und den Möglichkeiten, die durch var entstehen sehr angetan. Ehrlich gesagt bin ich das heute noch. Aber mein Enthusiasmus ist doch deutlich gedämpft, jetzt wo ich es im Einsatz sehe und selbst einsetze. Mein “Problem” (wenn man das so überhaupt sagen kann) mit var ist nicht die Typ-Inferenz die es ermöglicht, sondern eher der zuweilen exzessive Einsatz.

Besonders betrübt bin ich, wenn ich z.B. in populären Blogs wie dem von Jeff Adwood lesen muss, das var das Allheilmittel schlechthin ist und so oft wie nur irgendmöglich eingesetzt werden sollte. Bei solchen Aussagen liegt bei mir die Vermutung nahe, das Jeff gerade nicht sehr große Projekte in C# stemmt. Schließlich wurde var nicht erfunden um die Deklarations- bzw. Konstruktionssyntax in C# zu verschönern, sondern dient einem dedizierten Zweck.

Umso erfreulicher ist es, das ich mich mit meiner Meinung in bester Gesellschaft vorfinde. So erklärt z.B. Richard sehr gut, das es beim var Keyword nicht um die Verkürzung von Codezeilen geht sondern bei exzessivem Einsatz eher in die Kategorie Programmierfaulheit einzustufen ist. Ich persönlich befürworte vollständig seine Meinung, wonach var dort eingesetzt werden sollte, wo es benötigt wird, und nicht überall wo es möglich ist.

Setzt man var überall ein, wo es möglich wäre, kommt solcher Code zustande:

public object GetMatchingCode(object[] codes, string matchPattern, bool ignoreInvalid)
{
  var bestMatch = FindBestMatch(matchPattern);
  var blackList = codelists.GetBlackList(codes);

  foreach(var c = in blackList.GetConfirmedCodes())
  {
    var matchPoint = bestMatch.CompareCode(c, ignoreInvalid);
    matchPoint.Combine(c.ParentCode);
    if (matchPoint.IsUnique(bestMatch)) return matchPoint;
  }

  return null;
}

Du als Leser dieser Codezeilen hast kein Visual Studio und keine Intellisense. Weißt Du, worum es bei diesen Codezeilen eigentlich geht? Ich wüßte es jedenfalls nicht.

Zugegeben, das Beispiel mag überspitzt sein. Jedoch übertreibe ich nicht, wenn ich sage, das ich “echten” Code schon lesen (und verstehen) musste, der mindestens den gleichen Grad von “konsequentem var Einsatz” aufwies wie obiges Beispiel.

Auf der anderen Seite ist var natürlich auch notwendig und äußerst sinnvoll. Die Paradedisziplin dabei ist sicherlich LINQ:

var persons =
  from customer in db.Customers
  where customer.State = 1
  select new { Id = customer.Id, Name = customer.Name };

Ich für meinen Teil finde var und Typ-Inferenz eine gelungene, sogar notwendige Bereicherung in C# – aber nur dort, wo es wirklich gebraucht wird. Obwohl Soren in seinem Blog mit “the C# keyword var is evil” sicherlich übertreibt, ist es eine besonders empfehlenswert seinem Beispiel zu folgen und die geradezu unsinnige “Benutze immer var”-Funktion im ReSharper einfach abzuschalten.

Mein Fazit: var ist nur dann cool, wenn ich es wirklich brauche – ansonsten bleibe ich bei expliziter Typdeklaration und dem mächtigen Visual Studio Intellisense/Autocomplete.