Base your decisions on heuristics and not on gut feeling

As a developer we tackle very often problems which can be solved in various ways. It is ok not to know how to solve a problem. The real question is: how to decide which way to go 😯

In this situations often I rather have a feeling as a concrete logical reason for my decisions. This gut feelings are in most cases correct – but this fact doesn’t help me if I want to discuss it with others. It is not enough to KNOW something. If you are not a nerd from the 80’s (working alone in a den) it is crucial to be able to formulate and explain and share your thoughts leading to those decisions.

Finally I found a solution for this problem as I saw the session of Mathias Verraes about Design Heuristics held by the KanDDDinsky.

The biggest take away seems to be a no-brainer but it makes a huge difference: formulate and visualize your heuristics so that you can talk about concrete ideas instead of having to memorize everything what was said – or what you think it was said.

Using this methodology …

  • … unfounded opinions like “I think this is good and this is bad” won’t be discussed. The question is, why is something good or bad.
  • … loop backs to the same subjects are avoided (to something already discussed)
  • … the participants can see all criteria at once
  • … the participants can weight the heuristics and so to find the probably best solution

What is necessary for this method? Actually nothing but a whiteboard and/or some stickies. And maybe to take some time beforehand to list your design heuristics. These are mine (for now):

  • Is this a solution for my problem?
  • Do I have to build it or can I buy it?
  • Can it be rolled out without breaking neither my features as everything else out of my control?
  • Breaks any architecture rules, any clean code rules? Do I have a valid reason to break these rules?
  • Can lead to security leaks?
  • Is it over engineered?
  • Is it much to simple, does it feel like a short cut?
  • If it is a short cut, can be corrected in the near future without having to throw away everything? = Is my short cut implemented driving my code in the right direction, but in more shallow way?
  • Does this solution introduce a new stack = a new unknown complexity?
  • Is it fast enough (for now and the near future)?
  • … to be continued 🙂

The video for the talk can be found here. It was a workshop disguised as a talk (thanks again Mathias!!), we could have have continued for another hour if it weren’t for the cold beer waiting 🙂

Event Storming with Specifications by Example

Event Storming is a technique defined and refined by Alberto Brandolini (@ziobrando). I fully agree the statement about this method, Event Storming is for now “The smartest approach to collaboration beyond silo boundaries”

I don’t want to explain what Event Storming is, the concept is present in the IT world for a few years already and there are a lot of articles or videos explaining the basics. What I want to emphasize is WHY do we need to learn and apply this technique:

The knowledge of the product experts may differ from the assumption of the developers
KanDDDinsky 2018 – Kenny Baas-Schwegler

On the 18-19.10.2018 I had the opportunity to not only hear a great talk about Event Storming but also to be part of a 2 hours long hands-on session, all this powered by Kandddinsky (for me the best conference I visited this year) and by @kenny_baas (and @use case driven and @brunoboucard). In the last few years I participated on a few Event Storming sessions, mostly on community events, twice at cleverbridge but this time it was different. Maybe ES is like Unit Testing, you have to exercise and reflect about what went well and what must be improved. Anyway this time I learned and observed a few rules and principles new for me and their effects on the outcome. This is what I want to share here.

  1. You need a facilitator.
    Both ES sessions I was part at cleverbridge have ended with frustration. All participants were willing to try it out but we had nobody to keep the chaos under control. Because as Kenny said “There will be chaos, this is guaranteed.” But this is OK, we – devs, product owners, sales people, etc. – have to learn fast to understand each other without learning the job of the “other party” or writing a glossary (I tried that already and didn’t helped 😐 ). Also we need somebody being able to feel and steer the dynamics in the room.


    The tweets were written during a discussion about who could be a good facilitator. You can read the whole thread on Twitter if you like. Another good article summarizing the first impressions of @mathiasverraes as facilitator is this one.

  2. Explain AND visualize the rules beforehand.
    I skip for now the basics like the necessity of a very long free wall and that the events should visualize the business process evolving in time.
    This are the additional rules I learned in the hands-on session:

      1. no dev-talk! The developer is per se a species able to transform EVERYTHING in patterns and techniques and tables and columns and this ability is not helpful if one wants to know if we can solve a problem together. By using dev-speech the discussion will be driven to the technical “solvability” based on the current technical constraints like architecture. With ES we want to create or deepen our ubiquitous language , and this surely not includes the word “Message Bus”  😉
      2. Every discussion should happen on the board. There will be a lot of discussions and we tend to talk a lot about opinions and feelings. This won’t happen if we keep discussing about the business processes and events which are visualized in front of us – on the board.
      3. No discussions regarding persons not in the room. Discussing about what we think other people would mind are not productive and cannot lead to real results. Do not waste time with it, time is too short anyway.
      4. Open questions occurring during the storming should not be discussed (see the point above) but marked prominently with a red sticky. Do not waste time
      5. Do not discuss about everything, look for the money! The most important goal is to generate benefit and not to create the most beautiful design!

Tips for the Storming:

  • “one person, one sharpie, one set of stickies”: everybody has important things to say, nobody should stay away from the board and the discussions.
  • start with describing the business process, business rules, eventual consistent business decisions aka policies, other constraints you – or the product owner whom the business “belongs” – would like to model, and write the most important information somewhere visible for everybody.
  • explain how ES works: every business relevant event should be placed on a time line and should be formulated in the past tense. Business relevant is everything somebody (Kibana is not a person, sorry 😉 ) would like know about.
  • explain the rules and the legend (you need a color legend to be able to read the results later).
  • give the participants time (we had 15 minutes) to write every business event they think it is important to know about on orange stickies. Also write the business rules (the wide dark red ones) and the product decisions (the wide pink ones) on stickies and put them there where they are applied. The rules before the event, the policies after one event happened.
  • start putting the stickies on the wall, throw away the duplicates, discuss and maybe reformulate the rest. After you are done try to tell the story based on what you can read on the wand. After this read the stickies from the end to the start. With these methods you should be able to discover if you have gaps or used wrong assumptions by modelling the process you wanted to describe.
  • mark known processes (like “manual process”) with the same stickies as the policies and do not waste time discussing it further.
  • start to discuss the open questions. Almost always there are different ways to answer this questions and if you cannot decide in a few seconds than postpone it. But as default: decide to create the event and measure how often happens so that later on you can make the right decision!
    Event Storming – measure now, decide later


    Another good article for this topic is this one from @thinkb4coding

At this point we could have continued with the process to find aggregates and bounded contexts but we didn’t. Instead we switched the methodology to Specifications by Example – in my opinion a really good idea!

Specifications
Event Storming enhanced with Specifications by Example

We prioritized the rules and policies and for the most important ones we defined examples – just like we are doing it if we discuss a feature and try to find the algorithm.

Example: in our ticket reservation business we had a rule saying “no overbooking, one ticket per seat”. In order to find the algorithm we defined different examples:

  • 4 tickets should be reserved and there are 5 tickets left
  • 4 tickets should be reserved and there are 3 tickets left
  • 4 tickets should be reserved and all tickets are already reserved.

With this last step we can verify if our ideas and assumptions will work out and we can gain even more insights about the business rules and business policies we defined – and all this not as developer writing if-else blocks but together with the other stake holders. At the same time the non-techie people would understand in the future what impact these rules and decisions have on the product we build together. The side-effect having the specifications already defined is also a great benefit as these are the acceptance tests which will be built by the developer and read and used by the product owner.

More about the example and the results can you read on the blog of Kenny Baas-Schwegler.

I hope I covered everything and have succeeded to reproduce the most important learning of the 2 days ( I tend to oversee things thinking “it is obvious”). If not: feel free to ask, I will be happy to answer 🙂

Happy Storming!

Update: we had our first event storming and it was good!

Unfortunately we didn’t get to define the examples (not enough time). Most of the rules described above were accepted really well (explain the rules, create a legend for the stickies, flag everything out of scope as Open Question). Where I as facilitator need more training is by keeping the discussion ON the board and not beside. I have also a few new takeaways:

  • the PO describes his feature and gives answers, but he doesn’t write stickies. The main goal ist to share his vision. This means, he should test us if we understood the same vision. As bonus he should complete his understanding of the feature trough the questions which appear during the storming.
  • one color means one action/meaning. We had policies and processes on the same red stickies and this was misleading.
  • if you have a really complex domain
    (like e-commerce for SaaS products in our case) or really complex features start with one happy path example. Define this example and create the event “stream” with this example. At the end you should still add the other, not so happy-path examples.

Kollegen-Bashing – Überraschung, es hilft nicht!

Bei allen Konferenzen, die meinen Kollegen und ich besuchen, poppt frĂŒher oder spĂ€ter das Thema Team-Kultur auf, als Grund von vielen/allen Problemen. Wenn wir erzĂ€hlen, wie wir arbeiten, landen wir unausweichlich bei der Aussage “eine selbstorganisierte crossfunktionale Organisation ohne einen Chef, der DAS Sagen hat, ist naiv und nicht realistisch“. “Ihr habt irgendwo sicher einen Chef, ihr wisst es nur nicht!” war eine der abgefahrensten Antworten, die wir unlĂ€ngst gehört haben, nur weil der GesprĂ€chspartner nicht in der Lage war, dieses Bild zu verarbeiten: 5 Selbstorganisierte Teams, ohne Chefs, ohne CTO, ohne Projektmanager, ohne irgendwelche von außen eingekippte Regeln und Anforderungen, ohne Deadlines denen wir widerspruchslos unterliegen wĂŒrden. DafĂŒr aber mit selbst auferlegten Deadlines, mit Budgets, mit Freiheiten und Verantwortung gleichermaßen.

Ich spreche jetzt hier nicht vom Gesetz und von der Papierform: natĂŒrlich haben wir in der Firma einen CTO, einen Head of Development, einen CFO, sie entscheiden nur nicht wann, was und wie wir etwas tun. Sie definieren die Rahmen, in der die GeschĂ€ftsleitung in das Produkt/Vorhaben investiert, aber den Rest tun wir: POs und Scrum Master und Entwickler, gemeinsam.

Wir arbeiten seit mehr als einem Jahr in dieser Konstellation und wir können noch 6 Monate Vorlaufzeit dazurechnen, bis wir in der Lage waren, dieses Projekt auf Basis von Conways-Law zu starten.

“Organizations which design systems [
] are constrained to produce designs which are copies of the communication structures of these organizations.” [Wikipedia]

In Umkehrschluss (und freie Übersetzung) heißt das “wie deine Organisation ist, so wird auch dein Produkt, dein Code strukturiert sein”. Wir haben also an unserer Organisation gearbeitet. Das Ziel war, ein verantwortungsvolles Team aufzubauen, das frei zum TrĂ€umen ist, um ein neues, großartiges Produkt zu bauen, ohne auferlegten Fesseln.

Wir haben jetzt dieses Team, wir leben jetzt diesen Traum – der natĂŒrlich auch Schatten hat, das Leben ist schließlich kein Ponyhof :). Der Unterschied ist: es sind unsere Probleme und wir drĂŒcken uns nicht davor, wir lösen sie zusammen.

Bevor ihr sagt “das ist ein GlĂŒcksfall, passiert normalerweise nicht” wĂŒrde ich widersprechen. Bei uns ist es auch nicht nur einfach so passiert, wir haben (ungefĂ€hr 6 Monate) daran gearbeitet, und tun es weiterhin kontinuierlich. Der Clou, der SchlĂŒssel zu dieser Organisation ist nĂ€mlich eine offene Feedback-Kultur.

Was soll das heißen, wie haben wir das bei uns erreicht?

  • Wir haben gelernt, Feedback zu geben und zu nehmen – ja, das ist nicht so einfach. Das sind die Regeln
    • Alle Aussagen sind Subjektiv: “Gestern als ich Review gemacht habe, habe ich das und das gesehen. Das finde ich aus folgenden GrĂŒnden nicht gut genug/gefĂ€hrlich. Ich könnte mir vorstellen, dass so oder so es uns schneller zum Ziel bringen könnte.” Ihr merkt: niemals DU sagen, alles in Ich-Form, ohne vorgefertigten Meinungen oder Annahmen.
    • Alle Aussagen mit konkreten Beispielen. Aussagen mit “ich glaube, habe das GefĂŒhl, etc.” sind Meinungen und keine Tatsachen. Man muss ein Beispiel finden sonst ist das Feedback nicht “zulĂ€ssig”
    • Das Feedback wird immer konstruktiv formuliert. Es hilft nicht zu sagen, was schlecht ist, es ist viel wichtiger zu sagen woran man arbeiten sollte: “Ich weiß aus eigener Erfahrung, dass Pair-Programming in solchen FĂ€llen sehr hilfreich ist” z.B.
    • Derjenige, die Feedback bekommt, muss es anhören ohne sich zu recht fertigen. Sie muss sich selber entscheiden, was sie mit dem Feedback macht. Jeder, der sich verbessern möchte, wird versuchen, dieses Feedback zu Herzen zu nehmen und an sich zu arbeiten. Das muss man nicht vorschreiben!
  • One-and-Ones: das sind Feedback-Runden zwischen 2 Personen in einem Team, am Anfang mit Scrum Master, solange die Leute sich an die Formulierung gewöhnt haben (wir haben am Anfang die ganze Idee ausgelacht) und spĂ€ter dann nur noch die Paare. Jedes mal nur in eine Richtung (nur der eine bekommt Feedback) und z.B. eine Woche spĂ€ter in die andere Richtung. Das Ergebnis ist, das wir inzwischen keine Termine mehr haben, wir machen das automatisch, jedes Mal, wenn etwas zu “Feedbacken” ist.
  • Team-Feedback: ist die letzte Stufe, lĂ€uft nach den gleichen regeln. Wird nicht nur zwischen Teams sondern auch zwischen Gruppen/Gilden gehalten, wie POs oder Architektur-Owner.

Das war’s. Ich habe seit ĂŒber einem Jahr nicht mehr SĂ€tze gehört, wie “die Teppen von dem anderen Team waren, die alles verbockt haben” oder “Die kriegen es ja sowieso nicht hin” oder “Was kĂŒmmert es mich, sie haben ja den Fehler eingecheckt” Und diese ArbeitsatmosphĂ€re verleiht FlĂŒgel! (sorry fĂŒr die copy-right-Verletzung 😉 )

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.

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.

File provided for Reference Use Only By Microsoft Corporation (c) 2007

Seit ein paar Wochen, wenn ich mit Resharper zu der Implementierung von manchen Microsoft-Funktionen navigieren will, bekomme ich die ganze dll heruntergeladen und danach den ganzen Code zu sehen:

// ==++==
//   Copyright (c)  Microsoft Corporation.  All rights reserved.
// ==--==
namespace System.Globalization {
    using System.Security.Permissions; 
    using System.Runtime.Serialization; 
    using System.Text;
    using System; 
    //
    // Property             Default Description
    // PositiveSign           '+'   Character used to indicate positive values.
    // NegativeSign           '-'   Character used to indicate negative values. 
    // NumberDecimalSeparator '.'   The character used as the decimal separator.
    // NumberGroupSeparator   ','   The character used to separate groups of 
    //                              digits to the left of the decimal point. 
    // NumberDecimalDigits    2     The default number of decimal places.
    // NumberGroupSizes       3     The number of digits in each group to the 
    //                              left of the decimal point.
    // NaNSymbol             "NaN"  The string used to represent NaN values.
    // PositiveInfinitySymbol"Infinity" The string used to represent positive
    //                              infinities. 
    // NegativeInfinitySymbol"-Infinity" The string used to represent negative
    //                              infinities. 
    // Property                  Default  Description
    // CurrencyDecimalSeparator  '.'      The character used as the decimal
    //                                    separator.
    // CurrencyGroupSeparator    ','      The character used to separate groups 
    //                                    of digits to the left of the decimal
    //                                    point. 
    // CurrencyDecimalDigits     2        The default number of decimal places. 
    // CurrencyGroupSizes        3        The number of digits in each group to
    //                                    the left of the decimal point. 
    // CurrencyPositivePattern   0        The format of positive values.
    // CurrencyNegativePattern   0        The format of negative values.
    // CurrencySymbol            "$"      String used as local monetary symbol.
    // 

    [Serializable] 
    [System.Runtime.InteropServices.ComVisible(true)] 
    sealed public class NumberFormatInfo : ICloneable, IFormatProvider
    { 

        // invariantInfo is constant irrespective of your current culture.

        private static NumberFormatInfo invariantInfo;
...

Das ist wunderbar, es ist großartig zu sehen, wie die Klassen Random or DateTime aufgebaut sind. Obwohl ich keine Ahnung habe, warum das passiert… Ich hoffe allerdings, dass es kein Bug ist, und ich weiterhin den Code statt irgendeine Dokumentation sehen werde, auch wenn komischerweise am Ende der meisten Klassen der Titel dieses Artikels steht: File provided for Reference Use Only By Microsoft Corporation (c) 2007 😉

Das alles ist cool, aber noch nicht wirklich ein Grund fĂŒr einen Blogeintrag. Den folgenden Kommentar wollte ich euch aber nicht vorenthalten:

        // READTHIS READTHIS READTHIS 

        // This class has an exact mapping onto a native structure defined in COMNumber.cpp

        // DO NOT UPDATE THIS WITHOUT UPDATING THAT STRUCTURE. IF YOU ADD BOOL, ADD THEM AT THE END. 

        // ALSO MAKE SURE TO UPDATE mscorlib.h in the VM directory to check field offsets. 

        // READTHIS READTHIS READTHIS

        internal int[]  numberGroupSizes = new int[] {3};
...
        internal bool m_useUserOverride=false;    // NEVER USED, DO NOT USE THIS! (Serialized in Everett)
...

😆

communicare ergo sum

Wie ich schon in dem Artikel ĂŒber NOS SĂŒd erwĂ€hnte, eines der interessantesten Themen, worĂŒber wir in Karlsruhe debattiert haben, ist das Berufsbild des Softwareentwicklers. In einem Punkt waren wir uns alle einig:  der Softwareentwickler muss ein kleines Kommunikations-Genie sein!
Er muss sich in der Lage seines GesprĂ€chspartners versetzen können, um Antworten auf noch nicht gestellten Fragen auszusprechen zu können; er muss seinem GegenĂŒber diplomatisch den rechten Weg zeigen, vor allem da dieser meistens ĂŒberhaupt keinen blassen Schimmer von dem hat, was alles in einem Softwareprojekt möglich ist bzw. beachtet werden muss.

In den letzten Tagen habe ich den Eindruck bekommen, dass die Sommerhitze viele dazu gebracht hat, ihr sonst immer vorhandenes Talent im Bereich der Kommunikation zu vergessen. Alle diese Leute sind hochqualifizierte IT-Professionals, die, wenn sie sich zusammentun wĂŒrden, alles schaffen könnten, was sie sich nur in den Kopf setzen. Ich habe bisher von ihnen wahnsinnig viel gelernt und das wird sich sicher niemals Ă€ndern.
Ich hĂ€tte allerdings diese Diskussion etwas anders gefĂŒhrt, und zwar nach diesen Regeln:

  1. Niemals in der Hitze des Gefechts antworten: das ist wahrscheinlich das Schwierigste, und in den heutigen digitalen Welt, wo man schnell und von ĂŒberall antworten kann, ist es fast unmöglich diesem Drang zu wiederstehen.  In der  Twitter- und Blog-Welt verlĂ€uft die Kommunikation nicht mehr nur zwischen den einzelnen Beteiligten, sondern vor der “versammelten Mannschaft”. Dies fĂŒhrt unweigerlich dazu, dass jedes Wort schwerwiegender ist und die Folgen eines falsch gewĂ€hlten Ausdruckes viel gravierender sind.
  2. Niemals jemanden öffentlich Beleidigen: auch wenn jemand einen Fehler gemacht hat, hat es gar keinen Sinn, ihn in eine Situation zu bringen, bei der er mit dem RĂŒcken zur Wand steht. In 90% der FĂ€llen wĂŒrde aufgrund des Prinzips “Angriff ist die beste Verteidigung” einfach nur zurĂŒck-beleidigt werden, wahrscheinlich auf einer noch schlimmeren Art, um seine “StĂ€rke” zu beweisen. Die Leute, die trotzdem objektiv bleiben und ihre eventuelle Schuld eingestehen sind sehr, sehr selten. Und noch seltener die, die sich nach eine Beleidigung öffentlich entschuldigen.
  3. Dem Anderen immer eine Wahl lassen: das Ziel sollte doch immer ein Konsens sein, sonst wĂŒrde man einfach nur Befehle erteilen und dies ist bekanntlich keine Kommunikation. Also bevor man ein GesprĂ€ch beginnt, muss man sich im klaren sein, was er von dem Anderen erwartet und ob das ĂŒberhaupt fair bzw. machbar ist.
  4. Niemals einen verlorenen Kampf beginnen: wenn es mir klar ist, dass der GesprĂ€chspartner niemals meinem Wunsch entsprechen wĂŒrde, wozu dann eine Diskussion anfangen? Man muss nicht immer alles durchsetzen, es geht ja hier nicht um Leben und Tod.
  5. Ich entschuldige mich bei den Lesern, die sich jetzt berechtigt fragen, um welche Diskussion es hier geht. Dies ist unwichtig, “vergangen sei vergangen und Zukunft ewig fern … “, es ist viel wichtiger, dass man endlich den gewĂŒnschten Konsens findet.
    Diese Community ist noch sehr jung und sehr empfindlich, es wĂŒrde uns allen schaden, sie teilen zu mĂŒssen.
    Ich bin derselbe Meinung wie Mike, unser Ziel ist lernen und lehren mit Freude und Leidenschaft.