Der Open Space muss eine UNkonferenz bleiben

sonst ist es kein Open Space mehr…

 

Am Wochenende gab es den letzten Pflichttermin des Jahres, der 8. Developer Open Space im Leipzig. Es wurden schon wieder alle Rekorde gebrochen – so viele Workshops (20), so viele Teilnehmer (um die 240) und – zu meiner besonderen Freude – so viele Frauen (kenne die genaue Zahlen nicht, aber im zweistelligen Bereich), wie noch nie. Danke nochmal an @TorstenWeber für die großartige Arbeit.

Für “Kenner” – alte Open Space-Hasen – war er lehrreich und spannend, wie immer. Wie sollte es sonst sein, wenn über 200 Nerds aufeinander treffen und ihre Erfahrungen austauschen. Diesmal haben sogar die üblichen 14 Stunden Session-Zeit + gemeinsames Frühstück + gemeinsame Abendveranstaltung nicht gereicht

Es war großartig, wie immer, aber wie gesagt: für Kenner. Ich habe nicht mal den Flughafen erreicht, als eine Diskussion über das immer zahlreicheren “Folien-Sessions” – Präsentationen – entbrannt ist.

 


Die Wahrheit ist, mir ist das früher auch nicht aufgefallen, aber das lag an meiner Erfahrung, wie man richtig priorisiert. Nach so vielen Jahren Community-“Mitgliedschaft” weiß ich genau, welche Sessions wert sind, in der begrenzten Zeit, die man bei einem Open Space hat, besucht zu werden. Deshalb ignoriere ich grundsätzlich Sessions die “Ich zeige euch meine Präsentation über das geilste, hippste, usw. Framework und wie ihr alle damit das geilste, hippste, usw. Webseiten bauen könnt”.

Und da ist das Problem: nur die erfahrenen Leute wissen das, die schon immer dabei waren, auch in den Zeiten, wo das die Ausnahme war. Die Beschreibung “Unkonferenz” ist nicht von ungefähr, ein Open Space ist keine Konferenz, wo man sich hinsetzt und konsumiert! Es lebt von den Teilnehmern, nicht von den Sponsoren oder von den Speakern.

Es gab schon immer One-Man-Shows und ich persönlich habe unglaublich viel davon profitiert, ich kann und will es nicht leugnen. Aber die waren NIEMALS Verkaufsgespräche sondern einfach nur Beweise dafür, wie großartig es ist, zu einer Community zu gehören. Ich habe manche von diesen Freunden – ich glaube, ich kann euch inzwischen Freunde nennen – mal gefragt, warum sie das tun, warum sie ihre wertvolle Zeit in uns noobes investieren und die Antwort war “darum, dass ihr das dann genau so weiter macht”. Und das ist genau das, was ich tue: ich möchte was der Community zurückgeben und meine Zeit in die Zukunft, in unseren Nachfolgern investieren: anderen zeigen, wie genial ein Community Event ist, wie großartig die Leute sind, die die Community bilden.

Ergo tue ich mich sehr schwer mit Versuchen, diese Events als “Projektmarkt” zu misbrauchen. (Ein hartes Wort, ich weiß, aber ihr wisst, ich sage, was ich denke 😉 )

Also hier mein Aufruf: Besucht weiterhin die Open Spaces, meidet aber Sessions, die “ich zeige euch, wie es geht” lauten, es sei denn, ihr habt selber darum gebeten. Lasst euch nicht die Zeit klauen, um euch von einer einziger Person berieseln zu lassen, wenn ihr in dieser Zeit einen echten Erfahrungsaustausch mit ehrlichen Berichten, ohne Powerpoint-Folien, erleben könntet. Alle haben was zu bieten, das beweist schon die Tatsache, dass ihr den Weg zum Open Space gefunden habt! Und noch was: stellt ruhig alle Fragen, die ihr habt, weil eins ist sicher: Hier gibt es keine Rollenaufteilung in Sprecher / Zuhörer, Entwickler / Administrator, Softwareentwickler / Projektmanager usw. und die Themen finden sich vor Ort ganz von selbst. ( http://nossued.de/ ).

Der nächste Open Space ist die Spartakiade und danach – wahrscheinlich 😉 – der Shorty Open Space (zu finden und anmelden via Twitter) oder doch der OPEN SPACE SÜD (im Juni oder Juli in Karlsruhe) – und danach natürlich der 9. Open Space Leipzig. Lass uns also eine neue Regel etablieren: Folienverbot!

Graph databases

My second day at the Spartakiade was dedicated to the subject of graph databases.

In computing, a graph database is a database that uses graph structures for semantic queries with nodes, edges, and properties to represent and store data. A graph database is any storage system that provides index-free adjacency. This means that every element contains a direct pointer to its adjacent elements and no index lookups are necessary. General graph databases that can store any graph are distinct from specialized graph databases such as triplestores and network databases. (source: Wikipedia)

The workshop was led by Stephan (@Piratevsninja) – thank you very much! – and we used Neo4j, the most popular open source graph database. After this day of dive-in I can say I can start to create my first graph database application without asking myself all the time what the hell am I doing :)

Also: what is a graph database?

On a very high level we can split the databases into two types: RDBMS and NoSQL. In other words: into relational and nonrelational storages.

NoSQL databases – called by Martin Fowler Not Only SQL have the main focus on the data model and not on the relations between the data. Mostly there isn’t any relation between the entities. They can be differentiated based on the data model they use. Here some examples: Key-value storages (Redis, CouchDB, etc.), Document DBs (Lotus Notes, MongoDB, etc.), Column based DBs (Cassandra, HBase, etc.).

Relational databases (RDBMS) store the data denormalized and define the relations between the data types (also ALL the entries of one type). I don’t think I have to give examples for our plain old databases: if you can join and distinct data you are in the world of relational databases.

Graph databases combine both worlds: they are relational databases with the main focus on the relations between the data (not between the data model) – or like Stephan formulated it: they put data in the context of relationships.

Nodes and relations
Emil knows Ian (source: neo4j.com)

How you define the content ?

A graph database contains nodes (instances like “Emil” and “Ian”) and relations between these nodes (“knows”). One node is defined through some properties and can be grouped through labels. They often have aliases to be easier to work with them:

Emil:Person {name:"Emil", age:"20"}, Ian:Person {name:"Ian"}

One relation is defined through a name, the nodes it connects and the direction of this connection. Relations can also have properties but they should be very carefully chosen. They must describe the relation and not the nodes.

(Emil)-[:KNOWS {certainty:100}]->(Ian)

Now is clear to see what is the difference between a “plain” relational and a graph database: for the former you care always about the data. For the latter the data means nothing without the relation to some other data.

Movies and actors

 

Fine, I can set actors in relations. So what?

The most important point is: think around a corner. The fact that I can report that Ian knows Emil and Johann knows Emil too can be interesting but I don’t think there are any new business ideas in the domain of social connections which weren’t evaluated yet. What about the information that only 20% of the Swedish tourists who visit Germany and are between 18 and 25 do not speak German? This is surely a VERY interesting to know if you sell German dictionaries in the near of Universities…
I just invented this idea – I have no idea how many Swedish guys between 18 and 25 are speaking German 😉 – but this is what I mean with think around a corner!

What else remains to do?

After giving a good thought to the design: the relations and the connected data – like ids and oder characteristics but only if they are must-have – there are only a few things to do. Neo4j just like all the other graph databases have some kind of API to create, insert, update and query data. You only have to save the data across your application and create a UI (or use the one from Neo4j which is one of the coolest UI I ever saw) to create reports. Put this reports in front of the business analyst and you are done!

Spartakiade – Marathonlauf für Entwickler

Am Wochenende von 21-22. März hat im Berlin die vierte Spartakiade stattgefunden. Die Idee der Veranstaltung ist einfach: eine Open Space-(Un)Konferenz, die ausschließlich aus Workshops besteht.

Ich habe bisher noch nie geschafft, die Spartakiade zu besuchen. Bis jetzt. Mein Urteil: volle Punktzahl. Diese zwei Tage machen zusammen mit den anderen Open Space Events (Developer Open Space in Leipzig, Open Space Süd in Karlsruhe und Shorty Open Space, der immer spontan via Twitter organisiert wird ) die Sache rund.

Wir waren über 100 Teilnehmer, die in den 2 Tagen 19 Workshops besucht haben. Unsere Coaches genau so wie die Organisatoren sind really most valuable persons der Community, die mehr als unseren Dank verdienen: ein großer fetter Dank von mir nochmal an euch alle (ich hätte Angst, dass ich jemanden vergesse, deshalb schreibe ich hier keine Namen. Aber sie sind alle auf der Homepage der Spartakiade zu finden).

Ich meine, es ist schon großartig, dass wir die Workshops unter traumhaften Bedingungen, in den Räumlichkeiten von Immobilienscout24 haben dürften. Aber einen vollen Kofferraum Gadgets zu besorgen um das Workshop “Smart Things” vorzubereiten, oder neben der Arbeit sich in das Thema Graphdatenbanken einzuarbeiten UND die Präsentation an die 15 oder so “ausgehungerten” Entwickler vorzustellen –  nur um zwei von den Workshops zu erwähnen – , das macht man nicht mal so. Genauso wenig, wie für das Mittagessen mal 1 bis 3 Stunden im verregneten und kalten Berlin neben dem Grill auf der Straße zu stehen und für den zweiten Tag sich einen Burger-Wagen auszudenken, dann ist das schon viel viel mehr, was man normalerweise tun muss. Sowas entsteht nur durch voller Hingabe.

Ich habe hier keine Details über die Workshops, die ich besucht habe, genannt, weil sie auf jedem Fall eigene Blogposts verdienen. Ich kann nur eine Bemerkung eines Kollegen zurückgeben: “die Kosten, die durch dieses Wochenende entstanden sind, sind peanuts im Vergleich dazu, wie viel wir gelernt haben und wie viel return-of-investment aus dieser Investition entstehen wird!”

Wie gesund ist eigentlich mein Code?

 

software quality metric: A function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which software possesses a given attribute that affects its quality.

 Definition nach IEEE Standard 1061 – [Quelle: Wikipedia]

Jede Software, deren Code länger als ein paar hundert Zeilen ist, wird irgendwann den Punkt erreichen, dass man den Code auf Anhieb nicht mehr verstehen kann. Die meisten von uns schreiben Code, der älter als ein paar Monate ist und noch ganz viele Jahre erhalten bleiben soll. (Alle, die das nicht wollen, können hier aufhören zu lesen).

Das Problem, das man früher oder später bekommt, ist die Komplexität unter Kontrolle zu halten. Jeder neuer Kollege hat das Problem, unbekannten, vorhandenen Code so schnell wie möglich zu verstehen. Für beide Fälle ist es sehr hilfreich, wenn man Tools zur Hand hat, die zum Beispiel die Zusammenhänge und Abhängigkeiten visualisieren können.

Als ich bei dem Open Space Karlsruhe die Frage gestellt habe, was die .NET-Community zu diesem Zweck nutzt,war die einstimmige Antwort : NDepend.  Code Metriken sind wichtig, sie sind aber nicht allmächtig. Wenn man allerdings wissen möchte, wie gesund sein Code ist, was sich verschlechtert hat und welche Baustellen aufgeräumt wurden, dann ist NDepend das de facto Standardtool, welches benutzt wird.

Was macht das Tool eigentlich?

Um all die Features zu beschreiben, die NDepend hat, würde man sehr viel Platz und Zeit benötigen – und zum Glück ist dies gar nicht nötig: auf deren Webseite findet man alles, was man braucht: Bilder, Erklärungen, weiterführende Links.

Ich würde hier nur zwei wichtige Funktionalitäten herausheben:

  • Visualisiert

MVC-Runtime Dependency Graph
Abhängigkeiten im MVC-Runtime

 

Auf diesem Bild sieht man, dass man gar nichts sieht 😀

Stellt euch mal vor, ihr müsstet ab sofort an MVC weiterentwickeln. Wo würdet ihr anfangen? Ich würde hiermit beginnen und immer mehr reinzoomen.

Alle Verwender von DotNetOpenAuth.OpenId

 

  • Erklärt

Das coolste für mich bei NDepend ist eigentlich nicht die Tatsache, dass es mir Statistiken und Grafiken liefert, sondern, dass es sie mir Diese auch  erklärt!

 

Interne Abhängigkeiten von DotNetOpenAuth.OpenId

 

Genau so läuft es auch mit den Metriken. Ich will nicht wissen, wie diese berechnet werden – eventuell später –  aber ich will wissen, was es bedeutet, wenn ein Wert zu hoch oder zu klein ist. Und das Tool erklärt dies alles oder leitet mich gezielt dahin weiter, wo es erklärt wird. Und so, ohne es zu merken, habe ich etwas gelernt, was meine Codequalität höchstwahrscheinlich erhöhen wird. Ich kann dadurch ein besserer Programmierer werden.

Es gibt noch sehr viele Gründe, wofür man NDepend ausprobieren bzw. nutzen sollte. Spätestens, wenn ein Team sich für gemeinsame Regeln einigen möchte, sollte man die Einhaltung durch Tools wie dieses und StyleCop and co. absichern. Dadurch wird irgendwann egal, wie ungesund unserer Code heute ist, morgen wird es ihm auf jedem Fall besser gehen – und uns auch.

Are you nerd enough to code with us?

Ich habe lange überlegt, ob ich durch diesen Artikel mein Blog oder mich selbst korrumpieren würde. Ich meine, ich habe ganz klare Vorstellungen davon, ob man Webseiten kopieren darf, oder dass man Werbung, die man als Artikel tarnt, niemals versuchen darf, der Community zu verkaufen. Diese Prinzipien sind für mich nicht verhandelbar.
Ich habe mich entschieden, dass dieses “Stellenangebot” hier diese Prinzipien nicht verlezt: cleverbridge, die Firma für die ich arbeite und für die meine Kollegen und ich seit Monaten nach ein paar guten Codern suchen, entscheidet nicht, wen wir einstellen. WIR eintscheiden das – also auch ich. Das ist ein wahnsinns Gefühl, die Freiheit zu haben, es zu entscheiden mit wem man arbeitet und mit wem nicht. Wir machen uns ganz große Mühe, jemanden zu finden, der zu unseren Anforderungen und zu unseren Firmenkultur passt, also jemanden wie wir. Und wenn ich das will, dann muss ich es erzählen, wie es ist, bei cleverbridge zu arbeiten.  Betrachtet also diesen Artikel als “Bedienungsanleitung” zu uns cleverbridge-ler.
Unsere Kunden sind Softwarehersteller, Leute wie wir. Unsere Teams haben den Auftrag, ihre Anforderungen mit zu gestallten und sie zu erfüllen, ohne dass wir unsere Enduser, die durch unser E-Commerce-Portal das Produkt kaufen, als Betatester nutzen.
Das bedeutet, wir haben nicht nur die Aufgabe sondern auch die volle Unterstützung des Unternehmens, uns und unseren Code ständig zu verbessern. Wir – Entwickler UND Unternehmen – sind aktiv in der Community, veranstalten öffentliche Events wie UserGroup-Treffen und Scrumtisch, sponsern Konferenzen, wie die dotnet Cologne, reisen zu Open Spaces und andere Konferenzen, organisieren Dojos und Community of Practice-Sessions.
Warum? Dieses Unternehmen hat es verstanden, was für eine Verantwortung auf jedem einzelnen liegt. Wir sind schon mal eine der Top E-Commerce-Firmen der Welt. Das bedeutet arbeiten mit Geld ⇒ Verantwortung. Das bedeutet, wir sind rund um die Uhr, 7 Tage die Woche von allen Kontinenten  vergleichsweise gleich schnell erreichbar. Konkret heißt das um die 99%/Jahr, mit einer ca. doppelt so großen Geschwindigkeit, als unsere Konkurrenten ⇒ Verantwortung. Eine Verantwortung, die wir allerdings alle Teilen: beim Eintritt eines Problems wird niemals der Schuldige sondern immer eine Lösung gesucht.
Wir suchen Leute, die mit dieser Verantwortung umgehen können, sie sogar brauchen, und die die damit verbundene Freiheit schätzen.
  • Wir suchen Leute wie ihr und ich, die weiter als euren Tellerrand schaut, Nerds mit umfangreichem c#-Wissen und mit der einen und anderen Erfahrung schon auf dem Buckel.
  • Wir suchen keine Zertifikats-Besitzer, sondern Macher und Könner.
  • Wir suchen keine Stars sondern Peers, die lernen und lehren wollen.
  • Wir suchen Teamplayer, die wissen, wann und wobei man Kompromisse machen kann und wobei nicht.
  • Wir suchen Leute die Fehler machen können und daraus lernen.
  • Wir suchen Leute, die dies hier wollen: Clean Code, SOLID, TDD, Pair Programming, Teamkollegen Leiten und Begleiten.
Das ist sicherlich sehr viel, aber sonst wäre es doch einfach, oder? Und eins ist klar: bei uns wird die Arbeit niemals einfach, niemals langweilig, niemals monoton und immer geschätzt. Und wenn man mal eine Pause braucht: eine Runde Mario Kart oder Tischtennis-Spiel ist auch immer eine Option.

You never code alone!

Meine letzte Woche in der Arbeit würde ich gerne the cleverbridge-University-Woche nennen, so großartig war sie. Wir haben 3 von 5 Tagen damit verbracht, unseren Code, unsere Prozesse, unseres Miteinander zu analysieren, zu sezieren, zu verbessern:

  • Dienstag hatten wir fast einen ganz Tag Architektur-Workshop um die Vision und die Strukturen für unseren Code zu definieren.
  • Den Freitag haben wir gemeinsam bei der dotnet-cologne 2014 verbracht.

Das wichtigste hat allerdings am Donnerstag stattgefunden: wir haben uns einen ganz Tag Zeit genommen, um von Ilker, meinem TDD-Mentor, so viel wie möglich über Specs, Tests, Teams und Kommunikation zu verstehen.

Es geht nichts über Verstehen!

from requirement to specifications
Wie schafft es ein Team, das und nur das zu bauen, was der Kunde braucht?

  1. Findet alle zusammen – product owner, Entwickler, Tester – das richtige Wording, die “ubiquitous language” heraus, die die Anforderung beschreiben
  2. Versteht alle zusammen, worum es geht.
  3. Definiert zusammen das Feature
  4. Schreibt zusammen die Akzeptanzkriterien

Wie werden eigentlich eine paar Menschen zu einem Team?

Dies ist wahrscheinlich das Problem aller Firmen weltweit, die sich weiterentwickeln möchten. Und das zu Recht: stell dir vor, du bist ein C#-Entwickler mit zum Beispiel Schwerpunkt Web, hast JavaScript warscheinlich noch nie als Programmiersprache betrachtet und von der Arbeit der anderen C#-Entwickler weißt nichts, außer dass sie existiert und sie irgendwann später erfolgen wird, nachdem du deine Aufgaben schon längst erledigt hast. Einen Abteilungsleiter hast natürlich auch und deine Entscheidungsgewalt beschränkt sich auf “soll ich foreach oder lieber LINQ verwenden?”

Das ist allerdings nicht alles: deine Aufgaben überschreiten niemals die Grenzen deiner Abteilung, genauso wenig wie dein Verständnis über die Anforderungen. Und das stört dich seit langem und nicht nur dich sondern auch den JavaScript-Typen und die Frontend-Entwicklerin und wenn du Glück hast, dann auch deinen Abteilungsleiter. Wenn das der Fall ist, dann hat deine Firma Glück: ihr seid offen für ein Crossfunktionales Team. Ihr musst nur diese Frage bejahen:

Bin ich bereit, jede Rolle in diesem Team zu erfüllen?
Auch mit der Gefahr, dass ich das nicht kann? Wenigstens noch nicht, oder noch nicht gut genug…

Jedes Team braucht noch ein paar Zutaten:

  1. Ein Ziel
  2. Eine Partizipation – eine gemeinsame “Teilhaberschaft”
  3. Den Respekt der Individualität
  4. Die gemeinsame Verantwortung

oder wie Ilker sagt “oder mindestens 3 davon plus jemanden, der die anderen die ganze Zeit daran erinnert”.

 

Ich will nicht behaupten, dass wir bereits alles darauf haben – aber wir sind auf dem besten Wege dahin. Und was das Wichtigste ist: wir werden diesen Weg sicherlich nicht verlassen.

Create class from JSON

Ich habe vor einem Jahr bei einer katastrophalen MSFT-Veranstaltung über ein super Feature in VS2012 erfahren, das ich – brownfield-bedingt – noch nie ausprobieren konnte. Heute hat es mir allerdings mindestens eine halbe Stunde Arbeit und eine große Menge Frust erspart!

Das Feature ist sehr schnell erklärt: wenn man ein Objekt, das als JSON oder XML serialisiert vorliegt – also einen string 😉 – in Zwischenspeicher hat, dann kann man das direkt als Klassenmodel abspeichern. Tatata..Fertig :)
Edit/Paste Special

Open Space – agiler geht es nicht

Letztes Wochenende war wieder Hightide für Entwickler: es war “Open Space Süd Time” in Karlsruhe. Es gab viele bekannte und viele unbekannte (= neue) Gesichter. Es gab sogar ich glaube fünf weibliche Teilnehmer und auch noch einen Hund 😀

Wegen den vielen neuen Teilnehmer war es nach mehreren Jahren wieder notwendig, die Prinzipien zu erklären, die bei einem Open Space gelten:

Regeln

Im Open Space gibt es vier Prinzipien (eigentlich eher Beobachtungen, wie sich die Welt zeigt)

  1. Wer auch immer kommt, es sind die richtigen Leute – einer oder 25 ist egal, und jeder ist wichtig und motiviert.
  2. Was auch immer geschieht, es ist das Einzige, was geschehen konnte – Ungeplantes und Unerwartetes ist oft kreativ und nützlich.
  3. Es beginnt, wenn die Zeit reif ist – wichtig ist die Energie (nicht die Pünktlichkeit)
  4. Vorbei ist vorbei – Nicht vorbei ist Nicht-vorbei – wenn die Energie zu Ende ist, ist die Zeit um.

und ein Gesetz:
Gesetz der zwei Füße

Das Gesetz der zwei Füße ist Ausdruck der Freiheit und Selbstverantwortung: Der Teilnehmer bleibt nur so lange in einer Gruppe, wie er es für sinnvoll erachtet, also solange er etwas lernen und/oder beitragen kann.
(Wikipedia)

Es gibt auch eine Beschreibung der Teilnehmer:

Teilnehmer

Bei Open Space gibt es nicht den richtigen oder falschen Teilnehmer. Jeder ist willkommen, der oder die sich direkt betroffen und motiviert fühlt, etwas verändern zu wollen. Es sollen möglichst unterschiedliche Menschen eingeladen werden (Berufsgruppen, Verantwortungsbereiche, Alter, aber auch Kunden, Nachbarn, etc.), darunter die wesentlichen Meinungsmacher und Multiplikatoren.

Nach diesem letzten Open Space würde ich diese Definition erweitern:
jeder, der teil nimmt muss zu einem offenem Gespräch bereit sein. Das bedeutet, er muss nicht nur neugierig auf die Meinung der anderen sein, sondern muss bereit sein, seine Ansichten zu revidieren, wenn er sich geirrt hat.

Kommt jemand hin, um etwas zu präsentieren anstatt zu diskutieren: dafür ist Open Space nicht geeignet. Das ist keine Konferenz, wo die Leute bezahlen und hoffen, dass es sich lohnt 😉
Andererseits kommt jemand ohne irgendwelche Ansichten dahin, hat er die Möglichkeit, sie hier zu formen, die Meinung der anderen an zu hören und seine eigenen Schlussfolgerungen zu ziehen.

Was hat das alles mit Agilität zu tun? Schauen wir mal, was während diesen 2 1/2 Tagen immer wieder – in Zyklen sozusagen – passiert:

  1. – wir beschreiben Probleme oder Angebote und schmeißen sie in die Runde. Es werden die Interessenten gezählt und auf die Karte notiert => hört sich wie Planungsmeeting an, oder?
  2. – wenn das Bord voll ist – wie ein Backlog – , muss die zeitliche und räumliche Reihenfolge definiert werden, und zwar nach Sinn und Machbarkeit => genau wie in einem Priomeeting?
  3. – jetzt kommt die größte Herausforderung: welchen Session soll ich besuchen? Welcher hat für MICH die höchste Prio? Wie organisiere ich meine Zeit so, dass mein “Backlog” auch abgearbeitet wird?

Die ganzen Zeit stellen wir Fragen gestellt und Antworten überlegt: Anforderungen an andere definiert und selbst welche erfüllt. Wenn diese Anforderungen sich geändert haben – siehe spontane Coding Dojo von 18 bis fast 20 Uhr am Samstag Abend – dann wird vom Team sofort eine Entscheidung getroffen: passt es noch in diesem oder erst im nächsten Sprint (also am zweiten Tag).

Wir versuchen ununterbrochen durch die richtige Kommunikation die Lücken zu schließen, die wegen den Unterschiede in Erfahrung, Ausbildung, Alter, Geschlecht, Herkunft usw. existieren. Wir haben eine zeitliche Vorgabe – jeder Timeslot ist 45 Minuten lang – den wir zwar wahrnehmen aber uns damit nicht unter Druck setzen lassen.

Und jeden Abend wird der wichtigste Teil eines agilen Prozesses zelebriert: die Retrospektive – bei einem kühlen Bier :)

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