Coding Dojo – der Trainingsraum für Entwickler

Definition: A Coding Dojo is a meeting where a bunch of coders get together to work on a programming challenge (the Code Kata). They are there to have fun and to engage in deliberate practice in order to improve their skills.

(Quelle: http://codingdojo.org/)

The Principles of a Coding Dojo
(extracted from the Laurent Bossavit’s Blog: bossavit.com/dojo/archives/2005_02.html)

  1. The First Rule
    One important rule about the Dojo is : At the Dojo one can’t discuss a form without code, and one can’t show code without tests. It is a design training place, where it is acknowledged that “the code is the design” and that code without tests simply doesn’t exist.
  2. Finding a Master
    The master can’t be a master of every forms. I feel quite at ease with recursive functions and list processing e.g. but I think I don’t know how to create even a simple web app. Fortunately, while it’s the first time they really deal with “tail-recursion” some practionners here have done professional web apps for years!
  3. Come Without Your Relics
    Of course, you know how to do it. You know how and why this code is better than that one. You’ve done it already. The point is to do it right now, explain it to us, and share what you learned.
  4. Learning Again
    In order to learn again something, we just have to forget it. But it’s not easy to forget something when you’re alone. It’s easier when we give our full attention to someone who just tries to learn it for the first time. We can learn from others mistakes as well as from ours if we listen carefully.
  5. Slow Down
    Learning something should force you to slow down. You can go faster because you learned some tricks, but you cannot go faster and learn at the same time. It’s OK, we’re not in a hurry. We could do that for years. Some of us certainly will. What kind of deadline will we miss if we spend four more weeks on this subject rather than on four different subjects? More precisely, when we reach the next plateau, is it because we went through the previous one, or is it just because we were flying over it?
  6. Throwing Yourself In
    At some time someone begins to master a subject and wants to approach another one. Those threatened by boredom should throw themselves first into a presentation. The goal is to get back to a good motivation level, ie. an acceptable level of difficulty.
  7. Subjecting To A Master
    If it seems difficult to you, look for other practitionners who can judge your code and could easily show something new about it to you. Ask again until the matter contains absolutely no more difficulty to you.
  8. Mastering A Subject
    If it seems easy to you, to explain it to other who find it difficult. Explain it again as long as they find it difficult.

(Quelle: http://codingdojo.org/)

Seit mehreren Monaten experimentieren wir mit Coding Dojos in der Firma. Nach jedem bisherigen Dojo haben wir etwas gelernt und diese Erkentnisse bei dem nächsten Session gleich angewendet: Wir haben sozusagen die Dojo-Finding-Kata gelöst und eine gute Lösung dafür gefunden, wie wir dabei das meiste lernen können.

Es gibt 2 Levels: für Anfänger und für weniger Anfänger, mit einem gemeinsamem Punkt: alle sind Softwareentwickler. Anfänger bedeutet: neu in der Welt der Tests und/oder neu in C#. Dadurch, dass wir sowohl C# als auch JavaScript-Dojos machen, werden wir uns mal den einen mal den anderen Schuch anziehen müssen ;). Durch diese Aufteilung sind wir in der Lage, eine passende Übung durchzuführen. Die Einladung geht an alle und es bleibt jedem selbst überlassen, zu entscheiden, bei welchem Level er/sie mitmachen möchte. Diese Selbst-Verpflichtung führt automatisch dazu, dass man es ernst.

Was die Form betrifft, haben wir mehrere Varianten ausprobiert:

  • Mit oder ohne Moderator: Erkenntnis: es muss einen Moderator geben, wenn man nicht will, dass der Abend in Frust und Streit endet 😉
  • mit Coder und Driver (Randori Modus): Erkenntnis: der Coder war gleichzeitig der Driver, der andere saß nur da und wartete auf seine ReiheThumbs-down-icon
  • mit Wechsel der Paare nach einer bestimmten Zeit: Erkenntnis: das mentale Ticken einer Uhr hat teilweise zu einer kompletten Blockade geführt. Warum soll man überhaupt einen Stopper verwenden? Niemand sagt einem bei der Arbeit: du hast 5 Minuten für diese Aufgabe sonst müssen wir die Firma schließen!!Thumbs-down-icon
  • ein Dojo für alle, unabhängig von Kenntnissstand: Erkenntnis: ein guter Entwickler, der in C# noch noch nicht so bewandert ist, hat genauso gute oder gar bessere Ideen, als die anderen bzw. braucht länger um den Syntax des Lösungsweges zu verstehen. Das kann dazu führen, dass man sich unterschätztThumbs-down-icon

Nach verschiedenen Diskussionen mit anderen Entwickler, die Dojos in Unternehmen erfolgreich etabliert haben (danke nochmal Ralf und Uli) und nach diesen eigenen Erfahrungen, haben wir uns für die folgende Variante entschieden:

  • die Tastatur geht herum, und nicht der Entwickler (das hat auch immer wieder zu Störungen geführt).
  • Jeder, der dran ist, muss entweder den allerersten Test schreiben oder den vorherigen lösen: das bedeutet, er muss den Code schreiben, wodurch der Test grün wird – nicht mehr und nicht weniger. Danach muss er noch den nächsten Test schreiben, und zwar so, dass er rot ist. (Es gab Fälle, wo die nächste Anforderung – also der nächste Test – gleich mit implementiert wurde.)
  • Es gibt keine zeitliche Begrenzung und niemand muss alleine grübeln. Wenn Fragen oder Mißverständnisse im Raum stehen, sie werden sofort geklärt. Die Fragen müssen trotzdem vom Entwickler formuliert werden: der Lernprozess ist immer da.
  • Der Weg ist das Ziel: wird eine Aufgabe nicht in der Zeit erfüllt, die uns zur Verfügung steht, dann ist das auch ein Erkenntniss, aus dem man lernen kann.

Thumbs-up-icon

Wir verfolgen durch diese Trainingsstunden verschiedene Ziele:
– lernen, wie man Tests schreibt, um eine nachhaltige Qualität abzusichern,
– lernen, wie man Features gegen Code-Veränderungen schützt.
– lernen, wie man eine Anforderung interpretiert,
– lernen, wie man eine Anforderung definiert,
– lernen, wie man eine konstruktive Diskussion führt um sich auf eine Lösung zu einigen,
– lernen, wie man SOLIDen Code schreibt, Abhängigkeiten erkennt und trennt, wie man für Menschen lesbaren Code schreibt.

Die Liste der Lerneffekten solcher Übungen ist sicher viel länger, aber vorerst reicht es, wenn wir das hier schaffen :). Diese Prozesse werden sich sicherlich ändern – genauso wie wir Entwickler. Die Grundlagen aber bleiben bestehen: alles, was wir hier lernen, soll sich – wird sich –  in der täglichen Arbeit wiederspiegeln und uns zu besseren Softwareentwickler und gleichzeitig zu besseren Teamplayer machen.

Regions or no regions – this is the question

Die dnc12 ist gerade vorbei und wir könnten uns schon wieder zusammensetzen 🙂
Heute gab es auf Twitter eine kurz angerissene Diskussion, die das Zeug dazu hatte, die Gemüter aufzuheizen: soll man oder soll man nicht #regions nutzen?

 

Nach dem kurzen Tweet-Austausch wurde es klar, dass es viele Entwickler gibt, die Regions gerne nutzen. Ich habe zwar den ganzen Abend nachgedacht, habe allerdings keine Gründe gefunden, sie selbst verwenden zu wollen.

 

Ich meine, warum sollte man Code NICHT sehen wollen?

  • Geht es vielleicht um eine oder mehrere Methoden, die man ausblenden will? Das würde aber entweder bedeuten, dass man
    – die Funktionalität der ganzen Klasse ausblendet, aber dann wozu, man öffnet einfach die Klasse nicht 😉
    – nur ein Teil der Funktionen ausblendet, und dann stellt sich die Frage, warum manche Funktionen viel öfter angeschaut werden als andere? Das hat für mich irgendwie ein CodeSmell
  • Geht es vielleicht um ein Teil einer einzigen Methode, und zwar einer ganz großen, sonst würde man sie nicht teilweise ausblenden wollen? Zusammengeklappt würde man dann eine Art Kommentar sehen, was mich sofort an Martin Fowlers Hinweis bezüglich Kommentare erinnert hat: Kommentare sind ideale Namensgeber. Wenn man im Code einen Kommentar braucht, dann ist das meistens ein Smell für ein Extract Method (genauso wie die Tatsache, dass die Methode wahrscheinlich zu lang ist)

    You have a code fragment that can be grouped together.

    Turn the fragment into a method whose name explains the purpose of the method.

  • Geht es vielleicht um Regionen um Methoden, Events, Fields, Properties, also nach Sichtbarkeit und Rolle? Dafür könnte ich einen einzigen Grund vorstellen, und zwar den, dass man auf Anhieb die öffentliche Methoden und Eigenschaften sehen will. Das wäre allerdings die Aufgabe eines Interfaces, oder? Dazu kommt auch noch meine – persönliche – Vorliebe, Code wie ein Buch zu lesen, von oben nach unten, also von einer öffentlichen Methode weiter in die Details, also zu den privaten Methoden (ganz nach CCD – Single Level of Abstraction (SLA))

    Hilfreich als Analogie ist der Blick auf Artikel in der Tageszeitung: dort steht zu oberst das Allerwichtigste, die Überschrift. Aus ihr sollte in groben Zügen hervorgehen, wovon der Artikel handelt. Im ersten Satz des Artikels wird dies auf einem hohen Abstraktionsniveau beschrieben. Je weiter man im Artikel fortschreitet, desto mehr Details tauchen auf. So können wir auch unseren Code strukturieren. Der Name der Klasse ist die Überschrift. Dann folgen die öffentlichen Methoden auf hohem Abstraktionsniveau. Diese rufen möglicherweise Methoden auf niedrigerem Niveau auf, bis zuletzt die “Bitpfriemelmethoden” übrig bleiben. Durch diese Einteilung kann ich als Leser der Klasse entscheiden, welchen Detaillierungsgrad ich mir ansehen möchte. Interessiert mich nur grob, wie die Klasse arbeitet, brauche ich mir nur die öffentlichen Methoden anzuschauen. In ihnen wird die Funktionalität auf einem hohen Abstraktionsniveau gelöst. Interessieren mich weitere Details, kann ich tiefer einsteigen und mir die privaten Methoden ansehen.

Was meint ihr, übersehe ich da was? (Notiz an mich: bei #nossued das Gespräch fortsetzen!)

Design copy-paste

www.codekicker.de
Irgendwann Anfang Februar habe ich von Marco Parrillo (Neue Mediengesellschaft Ulm mbH) eine Empfehlung für: “codekicker.de – Die deutschsprachige Entwickler-Community | Machen Sie mit!” bekommen. Ich finde so was immer super und habe die E-Mail sofort an meinen Kollegen weitergeleitet (die Empfehlung kam ja von einer seriösen Gesellschaft).

Ich hatte in der Arbeit keine Zeit, also habe ich die Seite erst am Abend geöffnet :
www.stackoverflow.com

Oh, dachte ich, super: eine deutsche Tochter von stackoverflow!

Auf den ersten Blick konnte man das nirgendwo sehen, also habe ich alles durchsucht: Impressum, Kontakte, sonstige Infoseiten, aber gar nichts… Danach habe ich einfach die Suchfunktion benutzt, aber das einzige Ergebnis eine Frage zu einem Stackoverflow-Exception war.

Durch googeln bin ich fündig geworden: die Seite ist gar keine Tochterseite von stackoverflow, sie wurde einfach nur kopiert! Auf die Suchbegriffe stackoverflow + codekicker habe ich folgende Diskussion bei stackoverflow gefunden:

In germany a Stackoverflow-like site was created, that is very, very similar to Stackoverflow in the mechanics of reputation and badges etc. That is so similar, that I think they could use the same software. Did you sell it to them? Or are they using a very similar clone-software? The Community I have in mind is Codekicker.

Das war ernüchternd (und gleichzeitig komisch, da es offensichtlich eine Diskussion auf codekicker über das Thema gibt, aber irgendwie doch nicht gefunden wird).
Als ich dann die Antworten der Betreiber der Seite gelesen habe, wurde ich richtig enttäuscht:

Vielen Dank für deine Anteilnahme an unserem Projekt 😉 Du darfst uns gerne auf unserer Feedbackseite gründlich deine Meinung sagen. Per Mail oder Telefon bin ich heute den ganzen Tag zu erreichen.

Gruß,
Marvin

Irre ich mich, oder waren die 2 Studenten sogar stolz auf ihre copy-paste Fähigkeiten? Und kann es wirklich sein, dass alle das ok finden und keine daran was auszusetzen hat? Ich meine, sogar die Logos sind ganz ähnlich. Und auch, wenn stackoverflow den Code nicht patentiert hat, jemand hat sich ja richtig viel Mühe gemacht, das Design auszudenken, angefangen mit den Farben bis zum Gesamtbild.

Die Antworten variierten zwischen “das macht ja nichts, Hauptsache ist es auf Deutsch” und “wenn es dir nicht passt, dann nutze es nicht!” – was für mich erst Recht keine Antwort ist.

Ich überlege nun seit ein paar Wochen, ob ich das hier ansprechen soll, aber ich möchte eure Meinung wissen:

  1. Bin ich wirklich die einzige, die diese Tatsachen stören? Wäre es wirklich zu viel gewesen, irgendwo auf der Seite ein Dankeschön an stackoverflow auszugeben?
  2. Auch wenn das von 2 Studenten OK wäre, ist es auch in Ordnung, dass nun mehrere renommierte Zeitungen ihren guten Namen dazu geben?
  3. Ist es dann auch in Ordnung, dass diese Zeitungen mit einer kopierten Seite Geld machen wollen – da sie ja kräftig Werbung dafür machen? Und diesen Satz habe ich gar nicht verstanden: “mit codekicker.de ist am 1. Februar 2011 die neue deutschsprachige Community-Plattform für Entwickler gestartet”? Die Seite gibt es ja schon seit Juli 2009.

Eins ist sicher: ich empfinde großen Respekt gegenüber Jeff und Joel und die anderen von stackoverflow und ich finde, sie leisten großartige Arbeit (auch, wenn sie dies sicher nicht umsonst tun). Genauso einen Respekt habe hatte ich auch vor den Redakteuren dieser Zeitungen. Durch sie aber – da ich ihre Empfehlung weitergeleitet habe – habe ich nun auch eine Sache unterstützt, deren Betreiber es meiner Meinung nach nicht verdient haben. Mein Fehler, wird so bald sicher nicht wieder passieren.

Recht auf benutzerfreundliche Software

Bei den letzten DNUGKöln-Treffen habe ich einen verblüffenden Satz gehört:

Jeder Bürger hat ein streitbares Recht auf benutzerfrendliche Software.

Die Grundlage wird durch die Bildschirmarbeitsverordnung (BildschirmarbV, Dezember 1996) geliefert. Die Liste der Anforderungen an den Bildschirmarbeitsplätzen beinhaltet folegende Punkte:

21.
Bei Entwicklung, Auswahl, Erwerb und Änderung von Software sowie bei der Gestaltung der Tätigkeit an Bildschirmgeräten hat der Arbeitgeber den folgenden Grundsätzen insbesondere im Hinblick auf die Benutzerfreundlichkeit Rechnung zu tragen:
21.1
Die Software muß an die auszuführende Aufgabe angepaßt sein.
21.2
Die Systeme müssen den Benutzern Angaben über die jeweiligen Dialogabläufe unmittelbar oder auf Verlangen machen.
21.3
Die Systeme müssen den Benutzern die Beeinflussung der jeweiligen Dialogabläufe ermöglichen sowie eventuelle Fehler bei der Handhabung beschreiben und deren Beseitigung mit begrenztem Arbeitsaufwand erlauben.
21.4
Die Software muß entsprechend den Kenntnissen und Erfahrungen der Benutzer im Hinblick auf die auszuführende Aufgabe angepaßt werden können.

Das erste, was mir – und ich bin sicher, nicht nur mir – in Sinn gekommen ist, war: wie zum Teufel konnte Windows dieser Verordnung entsprechen?? Ich denke dabei vor allem an Punkt 21.3 …

Am Ende des vorher erwähnten Satzes, gab es allerdings noch eine Bemerkung: “es weißt nur keiner“.

Also jetzt schon.

Off Topic: In dieser Liste gibt es noch einen letzten Punkt:

22.
Ohne Wissen der Benutzer darf keine Vorrichtung zur qualitativen oder quantitativen Kontrolle verwendet werden.

Und jetzt frage ich mich, ob all die Konzerne (Deutsche Bahn, Telekom und wie die alle heißen), die ihren Mitarbeiter ausgespitzelt haben, wirklich dieser Anforderung entsprechen…