20
Oct 14

The abuse of “Thank you”

As a Scrum practitioner, how often do you use (or hear) phrases like

  • “Thank you for attending this meeting”
  • “Thank you for being on time for the Sprint Review”
  • “Thank you for providing feedback on the proposal”
  • “Thank you for the constructive atmosphere”

Attending a mandatory meeting is part of the job. Being on time is basic courtesy. Providing constructive feedback is what you are here for. IMHO, there’s absolutely no need to thank anybody for these trivial matters (*).

Au contraire, the inflationary use of “Thank you” waters down your message when it’s time to really thank someone (**). How about

  • “Thank you for going the extra mile to clean up module XYZ”
  • “Thank you for staying late to make up for the time we lost due to unforeseen circumstances”
  • “Thank you for helping me debugging this problem of mine”
  • “Thank you for explaining XYZ to me, I didn’t get it in the first place”

(*) If you need to convey a subtle message, you can always use “I’m really happy to see all of you on time”

(**) You already guessed it, I’m leaning heavily towards “Silence is praise enough”


20
Oct 14

Der inflationäre Gebrauch von “Danke”

Wie oft nutzen (und hören) wir als praktizierende Scrum-Adepten Versatzstücke wie

  • Vielen Dank, daß Sie an diesem Meeting teilnehmen
  • Vielen Dank für Euer pünktliches Erscheinen
  • Vielen Dank für den Feedback
  • Vielen Dank für die konstruktive Atmosphäre

Für mein Dafürhalten sind dies leere Floskeln. Die Teilnahme an Meetings ist Teil des Jobs. Soweit ich informiert bin, ist Pünktlichkeit eine Eigenschaft, die einem die eigenen Eltern beigebracht haben (sollten) (*). Auf Höflichkeit hat bereits die eigene Mutter bestanden. Nach meinen Informationen steht in den gängigen Arbeitsverträgen auch nichts über unsachliches Rumschreien.

Der inflationäre Gebrauch des “Danke” verwässert die Botschaft, wenn es wirklich angebracht / notwendig (**) ist, jemandem zu danken. Wie wäre es statt leerer Worthülsen mit

  • Vielen Dank, daß Du gestern am späten Abend noch das Modul XYZ aufgeräumt hast
  • Vielen Dank, daß Du heute morgen früher gekommen bist, um die rauchende Build-Maschine wieder zum Laufen zu bringen
  • Vielen Dank, daß Du mir beim Debuggen meines Problems geholfen hast, ich habe den Wald vor lauter Bäumen nicht gesehen
  • Vielen Dank, daß Du vorige Woche die Initiative ergriffen hast und den Kollegen die Architektur des Moduls XYZ am Beamer erklärt hast

(*) Falls man eine subtile Botschaft rüberbringen muß, paßt auch ein “Ich freue mich, daß ausnahmsweise wirklich alle pünktlich erschienen sind”.

(**) Ihr habt es geahnt: Ich bin ein Anhänger der “Ned g’schmipft is’ g’nug g’lobt” – Theorie.


07
Nov 13

Ein Tag im Leben des agilen Entwicklers Erwin L.

Vor langer Zeit, in einem Paralleluniversum. Eine völlig unrealistische Geschichte – Science-Fiction.

Jede Ähnlichkeit mit lebenden Personen oder Entwicklungsmethoden ist nicht nur nicht beabsichtigt sondern auch ausgeschlossen.

9:58 Uhr

Erwin Lindemann betritt kurz vor Beginn der Kernarbeitszeit leicht überhastet aber voller Elan das Büro. Wieder einmal war die Buslinie aufgrund einer Dauerbaustelle unpünktlich. Nach Ablage seines Jacke fährt er seine zwei Rechner hoch, um das Tagwerk zu beginnen. Merkwürdig, das Hochfahren seines MacOS Rechners mit diversen automatisch startenden Applikationen dauert doch ein ganzes Weilchen. Erwin Lindemann bespricht sich mit dem auch bereits anwesenden Kollegen Hugo B. und sie beschließen gemeinsam, durch Booten von einer Knoppix-DVD das Dateisystems des Macs einer genaueren Prüfung zu unterziehen. Knoppix prüft.

10:15 Uhr

Gerade als Erwin zur Kaffeemaschine strebt beginnt unglücklicherweise das Daily Scrum.

10:30 Uhr

Das Daily Scrum endet glücklicherweise pünktlich. Unglücklicherweise setzt der Productowner & Scrummaster in Personalunion (die Geschichte spielt sich bekanntermaßen in einem Paralleluniversum ab, in dem so etwas möglich ist und nicht mit dem Tode bestraft wird) unter völliger Überschreitung seiner Kompetenzen gleich noch eine Viertelstunde Backlogpflege-Workshop an. Erwin’s Koffeinspiegel sinkt lebensbedrohlich ab.

10:45 Uhr

Nach der gemeinsamen, harmonischen Backlogpflege – Kollege V. hat wieder einmal mit seinen “das braucht maximal 2 Storypoints” Schätzungen geglänzt – strebt Erwin mit stierem Block erneut der Kaffeemaschine zu, um seinen Koffeinspiegel auf ein halbwegs lebenserhaltendes Niveau zu bringen. Leider stürzt diese bei der Zubereitung des Heißgetränkes nach weniger Sekunden mit einer kryptischen Fehlermeldung ab – der Kaffee ist alle. Beim Nachfüllen bemerkt Erwin, daß die Kaffeevorräte insgesamt zur Neige gegangen sind. Er pilgert durch’s Büro, um den Kaffeeverantwortlichen zu finden und diesen auf diesen eklatanten Missstand aufmerksam zu machen. Hugo V., der Kaffeeexperte, berichtet gerade seinem Freund und Kollegen Karl Y., wie er es letzte Nacht im Online-Rollenspiel World of Witchcraft trotz erheblicher Widerstände eines als Mitspieler getarnten amerikanischen NSA-Analysten geschafft hat, auch die letzte Bastion der Unix-Elfen zu erstürmen. Da Erwin auch ein großer Freund von World of Witchcraft ist, klinkt er sich in das Gespräch ein und berichtet begeistert über das letzte Wochenende, als er World of Witchcraft bei einer LAN-Party des Karnevalsvereins in der örtlichen Mehrzweckhalle installierte. Alle Gesprächsteilnehmer sind sich nach eingehender Diskussion einig, daß aufgrund der Performance-Vorteile nur Ubuntu das Betriebssystem der Wahl sein könne, obwohl natürlich auch Gentoo wegen der aktuelleren Sicherheitsupdates in die engere Wahl gezogen werden müsse.

11:00 Uhr

Mit einer nun vollen Kaffeetasse bewaffnet kehrt Erwin voller Tatendrang an seinen Rechner zurück. Seine Story wurde beim Sprint Planning mit genügend Zeit beschätzt und er brennt darauf, die Story zu erledigen. Er läßt erst einmal einen svn update (die Geschichte spielt bekanntermaßen vor langer Zeit) und einen kompletten Build des gesamten Systems laufen, um auf den neuesten Stand des Quellcodes zu kommen. Sicher ist sicher. Eine solide Basis für den Tag.

Der Build dauert ein paar Sekunden und Erwin wirft einen Blick auf seinen Mac – Knoppix meldet keine Beschädigungen auf der Bootplatte. Nochmal den ausgewiesenen Experten Hugo B. kontaktiert. Dieser kratzt sich ausgiebig am Kopf und wirft die Frage auf, ob Erwin nicht mit einer SSD als Bootplatte besser bedient wäre. Eine gute Idee, denkt Erwin, und schaut gleich mal bei arlt.de nach den aktuellen Preisen. Arlt.de bietet eine Sandvox GTI 3000 für 129€ oder eine Alligator Vertex 2 für 149€ an, beide erscheinen ihm als geeignete Kandidaten. Erwin ist sich allerdings ob der angegeben Firmwareversionen unsicher und prüft auf dem bekannten Forum technik-freaks.de, ob bereits Erfahrungswerte mit dieser Firmware vorliegen. Siehe da, diverse Forumsmitglieder widersprechen dem detaillierten Testbericht der Alligator Vertex 2 und berichten von enormen Performance-Einbußen im Nanosekundenbereich bei Schreiboperationen für große Mengen von Dateien mit weniger als 0.5KB Größe. Der Experte Hugo B. ist sich nicht sicher, ob das Formusmitglied nicht “Nano” mit “Mikro” verwechselt hat und empfiehlt, nochmals beim konkurrierenden Forum hardware-für-dummies.de vorbeizuschauen. Aber die dort zahlreich vorgetragenen Argumente überzeugen Erwin nicht. Er entscheidet sich nach reiflicher Überlegung dafür, bei nächster Gelegenheit eine Sandvox GTI 3000 vorzuschlagen.

12:00 Uhr

Ein Blick in seinen Mailer offenbart Erwin, daß die Builds mal wieder nicht durchgelaufen sind. Naja, einer muß sich ja zuständig fühlen. Eine genauere Analyse zeigt, daß die periodisch erscheinenden Updatemeldungen des Betriebssystems das Buildscript zum Abbrechen bewogen haben. Gründlich wie er ist, installiert Erwin die neuesten Patches auf allen 4 Buildrechnern und startet die Builds erneut. Leider bricht der Build nun sofort mit kryptischen Fehlermeldungen ab. Eine Befragen von google.de und das Durchforsten diverser Foren ergibt, daß die im Buildsystem verwendete Version der Scriptsprache nicht mehr mit dem letzten Betriebssystem-Patch kompatibel ist. Erwin lädt seufzend die aktuellen Sourcen und übersetzt die Laufzeitumgebung der Scriptsprache neu. Endlich, die Buildscripts starten wieder. Daumen drücken.

13:00 Uhr

Mailer schließen und kurz in die Entwicklungsumgebung geschaut. Das am Vormittag gestartete svn update & der komplette Build brauchten wohl keine 5 Minuten. Ein Glück, daß Erwin bevorzugt auf einem Windows-Rechner arbeitet, auf dem solche kurzen Turnaround-Zeiten die Regel sind.

Leider ist das Frühstück heute morgen ausgefallen, es meldet sich ein Hungergefühl. Erwin bereitet sich in der Küche ein Mittagessen zu. Gerade die Kombination von Rohkost mit Quark ist wegen der fettlöslichen Vitamine für ein effizientes Arbeiten unerlässlich. Während er sein verdientes Mittagessen vor seinem Rechner zu sich nimmt, informiert Erwin sich auf heise.de über die neuesten Nachrichten aus dem IT-Sektor. Unglaublich, Roland Profalla von der CDU fordert eine Internetsperre für alle über 18-jährigen, damit der aktuellen Abhöraffäre um das Handy seiner Scheffin wirkungsvoll begegnet werden könne. Noch unglaublicher, was für inkompetente Kommentare andere Leser zu diesem Artikel abgeben. Erwin beschließt, diesen Internet-Trollen mit einem wohlformulierten Forumseintrag ein für alle Mal zu zeigen, wo der Hammer hängt.

13:30 Uhr

Erwin räumt sein Geschirr vorschriftsmässig in die Küche. Die Nahrungsaufnahme und der Anblick der Toilettentüre haben Erwin’s Verdauung in die Gänge gebracht. Er verschwindet auf der Toilette und liest den zufälligerweise in der neuesten c’t enthaltenen mehrseitigen Testbericht zu SSDs, der ihm allerdings auch bei genauestem Studium keine neuen Erkenntnisse bringt.

13:50 Uhr

Tatendurstig erscheint Erwin wieder aus den Niederungen seiner Verrichtung. Als er am Scrum-Raum vorbeikommt, sieht Erwin, wie der leicht gestresste Scrum-Master das Board umorganisiert. Hilfsbereit wie er ist, unterstützt Erwin den Scrum-Master, druckt die 100 neuen Kärtchen aus und heftet diese zusammen mit dem Scrum-Master an die Wand. Der Scrum-Master ist wieder entspannt.

14:15 Uhr

Zurück vor seinem Rechner will Erwin gerade tatendurstig mit der Bearbeitung seiner Story starten, als sich zwischen zwei Kollegen eine technische Diskussion um die Implementierung eines anderen Tasks entspinnt. Da die beiden Kollegen nicht wirklich weiterkommen, abgesehen sowieso eine gewisse Planlosigkeit bei generischer Programmierung offenbaren und zuguterletzt auch Erwin tangential betroffen ist, schaltet er sich in die Diskussion ein. Diese driftet kurz darauf in theoretische Spekulationen über mögliche Performance-Implikationen völlig unbekannter und nie geahnter Implementierungsvarianten ab. Da es schon 14:50 Uhr ist, entscheidet die Runde auf den Scheff zu warten, der jede Minute eintrudeln sollte, um diesem eine Entscheidung abzuringen.

15:00 Uhr

Der Scheff betritt gehetzt das Büro und wird von der immer noch beieinander sitzenden Runde sofort kassiert.

15:10 Uhr

Der Scheff hat wie nicht anders zu erwarten auch keinen Plan (auch in Paralleluniversen vor langer Zeit ein weitverbreitetes Phänomen) und flüchtet sich in Allgemeinplätze wie “Da ist was falsch” oder “Das müßt Ihr anders machen”. Nach kurzem Nachdenken trumpft er dann mit einem “Was sagt denn eigentlich der Debugger? Schon mal reingeschaut?” auf. Verdammt – daran hatte natürlich niemand gedacht. Die Runde entscheidet sich, das Thema erst genauer am Rechner zu analysieren bevor man weiterdiskutiert. Als ausgewiesener ÖPNV-Jünger macht Erwin L. den Scheff noch dankenswerterweise darauf aufmerksam, daß die aktuelle Webcam für die Umgehungsstraße einen Bautrupp zeigt, der seit 11:00 Uhr gerade beide Fahrbahnen aufreißt und offensichtlich seit 2h nicht in die Pötte kommt, weil die Biervorräte zur Neige gegangen sind. Ein Ende wäre nicht abzusehen, da der örtliche Bioladen aufgrund eines Lieferengpasses aus Oberbayern kurzfristig auch keine Starkbiervarianten mehr anbieten könne. Der Scheff möge bei der späteren Heimfahrt vorsichtig sein.

15:15 Uhr

Erwin wendet sich wieder seinem Rechner zu. Wo war er stehen geblieben? Ah, seine Story. Genau. Noch schnell ein svn update – man ist ja paranoid – und Erwin beginnt mit der Bearbeitung. Erstaunlich – ein Kollege, der vor ihm am fraglichen Teilsystem arbeitete, hat bereits Tests für die fragliche Klasse entwickelt, obwohl aufgrund der externen Abhängigkeiten zu einer SQL-Datenbank sowie einem Regensensor eigentlich eine testgetriebene Entwicklung von vorneherein ausgeschlossen scheint. Erwin startet also seinen Tag mit dem Erstellen eines Tests für seine neue Funktion. Was könnte man denn testen? Hmm. Ah. CHECK(container.size() == 0);

15:20 Uhr

Noch schnell den neuesten Codestand aus dem svn besorgt und Erwin startet erwartungsvoll den Build, um den Code für seinen Test auszuprobieren. Oha, das Übersetzen dauert wohl mehr als fünf Sekunden, da hatte jemand doch noch eine größere Menge Code in der Zwischenzeit… Erwin beschließt, nicht auf das Ende des Übersetzungsvorgangs zu warten und wendet sich wieder seinem Browser zu. Oha, da ist ja noch der Reiter mit dem heise.de Forums-Thread zu Roland Profalla offen. Unfassbar, schon wieder über 30 Einträge aufgelaufen. Komplett planlos, diese Leute von der CDU. Und zuviel Zeit haben sie auch noch. Erwin beschließt seufzend, noch einen letzten Versuch zu starten und schreibt den Trollen nochmal sehr deutlich was er von ihnen und insbesondere der Heldenverehrung des Franz Josef Strauß in der bayrischen Geschmacksrichtung der CDU hält.

15:35 Uhr

Befriedigt wendet sich Erwin wieder seiner Entwicklungsumgebung zu. Der Build war inzwischen erfolgreich und dauerte nur 30sec – Erwin nutzt schließlich einen schnellen Rechner der neuesten Generation. Erwin ist begeistert, der Code für seinen ersten Test läuft auf Anhieb. Er schreibt einen weiteren Test, der schon eine etwas anspruchsvollere Lösung erfordert. Erwin bittet daher zwei andere Kollegen, die seit mehreren Minuten enthusiasmiert den gestrigen Champions-League Abend auf Sky Revue passieren lassen, ihr Gespräch im Besprechungszimmer fortzusetzen – er müsse sich konzentrieren. Abgesehen davon wäre er der Meinung, daß das von Jürgen Klopp favorisierte 4:2:3:1 System gerade gegen stärkere Mannschaften aus dem ehemaligen Ostblock zu gefährlich sei, weil aufgrund der fehlenden Überzahlsituation an der vorderen rechten Eckfahne Konter über die Außen nur sehr eingeschränkt abgefangen werden könnten. Der aktuelle Aushilfsstürmer sei auch ein reiner Strafraumspieler, der weder in der Arbeit nach hinten entsprechende Akzente setzen könne noch wisse, wo das Tor steht. Die Kollegen widersprechen selbstredend, verziehen sich aber nach längerer, erhitzter Diskussion unter Murren ins Besprechungszimmer.

16:20 Uhr

Nach 30min intensiven Nachdenkens immer noch keine Lösung für den Test gefunden. Erwin beschließt sein Gehirn durchzulüften, den Kollegen das Auffrischen der Kaffeevorräte abzunehmen und pilgert zum Kaffeeröster des Vertrauens. Glücklicherweise war der Kaffee im Angebot. Echte Arabicabohnen mit erhöhtem Koffeingehalt. Das Sprintziel erscheint erreichbar.

16:40 Uhr

Wieder zurück im Büro, wird Erwin vom Kollegen Q. abgefangen, der mit deprimierter Stimme von Abstürzen mit dem neuesten Build auf seiner Maschine berichtet. Erwin hört sich die Sorgen & Nöte geduldig & aufmerksam an, richtet Q. mit seiner bekannt optimistischen Art wieder auf und man verabredet sich auf den morgigen Vormittag, um gemeinsam das Problem zu analysieren.

16:55 Uhr

Wieder zurück an seinem Rechner ist die algorithmische Lösung schnell gefunden. Der zweite Test läuft. Saubere Sache. Es geht voran. Weiter im Text. Dritter Test.

17:15 Uhr

Aufgrund der kalten Witterung bietet sich Kollege Y. an, eine Runde Eis für die Mannschaft zu holen. Eine leckere Sache. Erwin erbittet zwei Kugeln Vanille aus biologischem Anbau sowie eine Kugel Schlumpfeis.

17:30 Uhr

Nach dem gemeinsamen, den Zusammenhalt des Teams stärkenden Verzehr des Speiseeises geht Erwin wieder an’s Werk. Er findet nach kurzem Suchen ein Stück Code, welches mit ein klein wenig Arbeit auch seinen vierten Test erledigen könnte. Aufgrund der fortgeschrittenen Stunde kopiert Erwin dieses Codefragment kurzerhand in seine Funktion, ein paar kleine Änderungen und siehe da, auch der dritte Test des Tages läuft erfolgreich durch. Erwin kommt in Schwung.

18:15 Uhr

Die kostenlose Time-Tracking Applikation seines Smartphones informiert Erwin darüber, daß er heute schon über 8h 15min Büro weilt. Er beschließt den Tag, indem er seine Arbeitszeit am JIRA Task logged: 2.5h (in diesem fiktiven Paralleluniversum wird Timetracking scheinbar zur Selbstkontrolle verwendet). Hmm, damit hat er die für diesen Task veranschlagte Zeit bereits um 1.5h überzogen. Und Erwin hat noch einige andere, komplexe Stories in diesem Sprint zu meistern, von den eingegangenen Code Reviews für bereits erledigte Tasks einmal ganz abgesehen. Das Sprintziel scheint gefährdet. Erwin notiert sich, dass er dies beim morgigen Daily Scrum zur Sprache bringen muss. Bei der nächsten Retrospektive muss er darauf drängen, dass die Zeiten für die einzelnen Stories & Tasks noch konservativer geschätzt und Stories vorab genauer analysiert und besprochen werden.

18:20 Uhr

Erwin Lindemann beschließt sein Tagewerk und strebt seinem heimischen Rechner zu, um endlich einmal produktiv eine neue Version von Debian aufzusetzen.

Wie erwähnt – die Geschichte spielt in einem Paralleluniversum. Vor langer Zeit. Völlig unrealistisch – Science-Fiction.

Jede Ähnlichkeit mit lebenden Personen oder Entwicklungsmethoden ist nicht beabsichtigt und definitiv ausgeschlossen.


08
Aug 13

A few brief thoughts on “Dysfunctional Programming”

Here are a few random thoughts on @SamirTalwar‘s post “Dysfunctional Programming” – learning functional programming in your favourite language (go read it now, I’ll wait for you).

This is an excellent technique to understand the underlying concepts of a new programming “paradigm”. Because the new “paradigm” (*) is not about the language per se, it’s about a new way of thinking about problems, code & potential solutions. A new paradigm presents a new set of constraints and opportunities to the developer. Most of the time, the constraints are pretty easy to emulate (as Samir describes eloquently), sometimes they just require discipline. Plus, you can take advantage of these new opportunities by emulating them in your language of choice (e.g. starting to emulate polymorphism with function pointers in plain C or, as Samir showed, implementing a map function for an immutable list class) (**).

A great session at SoCraTes 2013, I enjoyed it a lot, and will pass this on in an internal workshop at extragroup GmbH.

(*) Most likely, the paradigm isn’t new per se (witness the latest “hype” – functional programming) – it’s just new to you – or, if you’re old enough, you’ve accumulated so much crap in your head that you purged your knowledge about the paradigm over the years anyway.

(**) I have fond memories of moving from structured programming to oo programming way back when using a Burroughs B20 with Pascal (yes, this was considered a leading edge language at that time). Talk about an old dog.


15
Feb 13

Uncle Bob Martin @ Objektforum Karlsruhe

On Feb 6, Robert C. Martin (“Uncle Bob”) gave a talk on “Automated Acceptance Testing: Expressing Requirements as Tests” @ ObjektForum Karlsruhe.

A few statements I found worthwhile for future reference:

  • Deployment is a business decision
  • Agile is not about getting more done, it’s about getting bad news early
  • Don’t let the tool dominate you
  • Not a lot of fixture code to write (to enable automated acceptance testing)
  • Test one thing only once

Here’s a thought which struck me while Uncle Bob waxed eloquently about Fitnesse and showed the DSL he created for testing Fitnesse:

A textual representation of a program’s or component’s output is the major prerequisite for automated acceptance testability. If you struggle with automated acceptance tests – as we do (CAD system with rich user interactions and complex objects being generated, dealing with complex object lifetime issues – “this can’t be tested automatically”) – focus on generating a simple textual representation of the results & interactions etc. This is the foundation of automated acceptance testability. It will be way easier to think about automated acceptance testing once you have this foundation in place.

Thanks to Robert for giving an energized talk despite being attacked by a flu virus and to andrena objects ag for organizing the ObjektForum event series.


10
Oct 12

Regardless of what we discover…

The Retrospective Prime Directive:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

What a great starting point for generating a safe environment during a sprint retrospective. A safe environment is important for a successful retrospective. However, starting with the prime directive will not generate a successful retrospective. Let me explain.

If I start thinking about the last sprint with the prime directive in mind, it is close to impossible for me to see how I could have done better. Because I did the best job I could – that’s what the prime directive said. If I’ve done the best job I could, what could be improved? Because my knowledge & skills are what they are, it sure is the situation at hand and the resources available which could be improved: The story wasn’t workable, the automated acceptance tests were sorely lacking, the build server failed all the time, the code was using this incomprehensible template stuff, the compiler was too slow, I had too many meetings, there are always conflicts when I try to commit my code, the APIs encountered are too complex, the product owner wasn’t available for questions 24/7, the unit tests ran for ages and slowed me down, the Scrum Master didn’t moderate each and every meeting & discussion – etc. and so forth.

If you’re using the prime directive as a starting point, you’re framing your mind the wrong way.

What happened to individual responsibility, to laziness, to procrastination, to lacking technical skills, to a lack of practice, to inefficient use of my time, to a lack of knowledge, to stalling, to stepping up to the plate and saying “I have to do a better job and I need to do something about it”?

Why don’t we start with the Retrospective Prime Questions (you bet I made up this phrase 2min ago)?

  • What could I have done to make this sprint more successfully?
  • How could I have behaved differently?
  • What should I have done to help my teammate accomplish his task?
  • What could I have contributed to improve the process?
  • What do I have to learn in order prevent this from happening again?
  • What can I do to improve our environment?

Maybe we would come up with action items like this:

  • Mary will fix this §$%& build server. Joe will help her out, he’s a Jenkins wizard. They’ll get right to it on Tuesday morning.
  • Mark will help improving our unit tests performance – he has some great ideas on how to make that happen.
  • Erwin needs to use Skype to contact the product owner with questions instead of stalling. Our Scrum Master will help him by reminding us in the Daily Scrum that the product owner is on the road.
  • Joe needs to understand this %&$§ template stuff. He will sit down over the weekend for a few hours, read up on it and do some experiments. Jack said he will work with him over a beer next Wednesday night and help Joe getting his templates straight. Mary said she’ll join Joe & Jack, too as she’s unsure if she really got variadic templates. Our Scrum Master will make sure that there’s plenty of free beer available to make this a pleasant experience.
  • We will check the top stories on the product backlog regularly and see if they’re workable. I will start doing that tomorrow morning before the daily meeting. 10 minutes & a good coffee should be enough to do that.
  • Paul will update his code from the repository multiple times a day to avoid deadly conflicts. We’ll set up a kitchen timer for him as reminder.
  • Marvin needs to ask the Scrum Master to help out if his discussions spiral out of control. Erwin, who’s sitting next to Marvin will help with notifying the Scrum Master in time.
  • John knows a little bit about this Cucumber thing, he’ll sit down with the product owner next week to show him how to use it. This will bring us closer to automated acceptance tests.
  • Hans will ask our Scrum Master about recommendations on how to improve his verbal communication skills.

Disclaimer:

I’m neither a professional Scrum Master nor a Product Owner nor a Scrum expert. I’m just an ordinary software developer trying to deliver valuable, clean software. Most of the time, I’m failing. And it’s not because my environment is to blame or because there are impediments beyond my control. It is because I have to do a better job. And I want you to help me do that.

[Update]
Another take on this topic can be found at What’s wrong with the Retrospective Prime Directive?.
[/Update]

[Update]
My Scrum Master just sent me this link: NAIKAN. Looks like a worthwhile (Warning: German Language) exercise to encourage self-reflection.
[/Update]

[Update]
Very nice German language post on this very topic: Der Flügelschlag eines Schmetterlings.
[/Update]

[Update]
Great take on re-phrasing the Retrospective Prime Directive: Another Alternative To The Retrospective Prime Directive. Here’s a nice German translation by Nicole Rauch.
[/Update]

[Update]
Another take on this very topic by Thomas Mayer – The Prime Defective.
[/Update]


03
Oct 12

Angst, Mut, Verantwortung, Disziplin

Joseph Pelrine hat auf der Agile Bodensee einen schönen Satz gesagt (ich paraphrasiere aus dem Gedächtnis):

“Über Scrum zu reden oder Scrum zu lehren / coachen ist viel leichter als Scrum tatsächlich tagtäglich zu implementieren”.

Das Arbeiten im Scrum-Umfeld verlangt dem Entwickler einiges ab. Es bringt Ängste zutage, erfordert Mut, Verantwortung und Disziplin:

Angst

  • Angst nicht “ganz fertig” zu werden
  • Angst sich vor den anderen Teammitgliedern zu blamieren
  • Angst verantwortlich gemacht zu werden
  • Angst daß eigene Defizite sichtbar werden
  • Angst daß der Task mehr beeinhaltet als man absehen konnte
  • Angst die notwendige Technik nicht zu beherrschen
  • Angst nicht rechtzeitig nach Hause zu kommen

Mut

  • Mut auch komplexe und unbekannte Aufgabenstellungen anzugehen
  • Mut andere rechtzeitig um Hilfe zu bitten
  • Mut eigene Defizite einzugestehen
  • Mut Verantwortung zu übernehmen
  • Mut auch mal später nach Hause zu kommen
  • Mut Aufgaben auch nachträglich zu vereinfachen
  • Mut nicht dem Sprintziel dienliche Aufgaben beiseite zu schieben

Verantwortung

  • Verantwortung, sich fehlende Fähigkeiten anzueignen
  • Verantwortung für die Gruppe zu übernehmen
  • Verantwortung für eigene Fehler zu übernehmen
  • Verantwortung für das Produkt zu übernehmen
  • Verantwortung pünktlich zu erscheinen
  • Verantwortung Informationen klar, präzise und zeitgerecht zu vermitteln
  • Verantwortung sich über anstehende Aufgaben zu informieren

Disziplin

  • Disziplin den Test zuerst zu schreiben
  • Disziplin auch wenn es zeitlich eng wird sauberen Code zu schreiben
  • Disziplin immer wieder über das eigene Fortkommen transparent zu informieren
  • Disziplin auch die unangenehmen oder unpopulären Tätigkeiten zu erledigen
  • Disziplin komplexe Aufgabenstellungen in überschaubare Arbeitspakete zu zerteilen
  • Disziplin immer wieder rechtzeitig Hilfe einzuholen
  • Disziplin bei jeder Tätigkeit immer wieder das Sprintziel im Auge zu haben

24
Sep 12

Staring is not an efficient coding technique

The following quote from Buzz Andersen’s blog (which I highly recommend) caught my eye:

…full-time pairing can make the certain amount of “staring into space” time every programmer needs to get things right excruciatingly awkward.

I don’t want to dive into the pair programming discussion this time, I’ll leave this for another post. I would like to talk about staring. Staring on the code. Staring on a comment. Staring on a UML design sketch. Or, as Buzz puts it, staring into space. (*)

As far as I can tell (and I have done my fair share of staring over the years), staring is a software engineering technique where, for an extend period of time, the software developer refrains from any movement of his extremities, stops moving his eyeballs and focusses on a particular piece of code, while his CPU cores, umm, brain runs at 100% load trying to solve the problem at hand.

If we’re lucky, said developer appears to wake up from time to time, types a few characters, maybe adds a comment and resumes staring. If we’re less lucky, said developer will remain unresponsive for extended amounts of time and will make no measurable progress towards his goal.

I don’t dispute that “Staring” may be a technique to get things right, but I would like to go on the record that it’s an efficient technique to get things right. Day after day, I observe that developers “stare into space” or, even more inefficient, “stare on the code” in order to solve problems. However, I’ve never seen a problem getting solved by staring, I’ve only seen problems getting solved by adding or changing code.

Why is staring an inefficient technique, you may ask?

Staring is inefficient because it doesn’t employ a feedback loop. You are reasoning about the code with yourself. Nothing wrong with it, but there’s no one involved giving you feedback on your thoughts or challenging your assumptions – after all, it’s just you staring at the code.

If you catch yourself staring at code too often, make sure to get into the habit of doing something with the code instead:

  • Even if you don’t have automated tests (and you know you should, don’t you), you can do tiny, lowest-risk refactorings which help you deepen your understanding of the code just a tiny little bit. Rename a variable, a function, extract a few lines of code to a new method, write a comment (gasp), change the formatting to suit your style (quadruple gasp). You can always revert this changes after you understood what’s going on (you do use version control, don’t you?)
  • How about running the code in a debugger to get the additional feedback of variable / objects / state changes at runtime?
  • How about writing unit tests? Write a test, write a little bit of code, write some more code, see a test failing, change the code, write a test to test your assumptions about specific parts of the code. Do a change to the codebase to learn something? Do the tests still run? Great. They don’t? Looks like your assumptions were wrong. Trace back, take another route.

If you absolutely must “stare” at the code, I suggest to take a step back and “sleep on it” or to take a short walk. But those are techniques which should be reserved to occasions when you really got stuck and you’re trying to solve really hard problems. Guess what, most of the time the problems aren’t that hard. They may be challenging but they are quite solvable by taking tiny, reproducible (sometimes revertible) steps towards a solution.

Code is like clay. Make sure to mold it. Carefully. You’ll learn way more by molding the code, not by staring at it.

(*) Don’t want to get into discussing “staring on web-sites not at all related to the task at hand” either.


23
May 12

Softwerkskammer Karlsruhe, 9th Meeting

This time, we decided to do the widely known Roman Calculator Kata. Coding via a beamer worked surprisingly well, especially after Nicole took over who’s a way faster & smarter typist than yours truly.

A couple of observations:

  • Although we started doing TDD (with the proper focus on “Driven”), the group quickly moved away from “doing the simplest thing that could possibly work” and started putting out new algorithmic variants of the solution at an amazing rate using the existing tests as a safety net
  • Taking small steps is a challenge if you’re in a room with smart people who tend to solve the problem right away by applying their superior brains
  • Taking baby steps is even harder in such a setting
  • It would be an interesting exercise to clean up the code produced as much as possible (and making it as C or C++ like as possible while doing so)
  • It would be an interesting exercise to start over with a clean slate and try a different order of the tests and see how this effects the algorithm chosen
  • Another variant would be to start with or at least add tests which check for edge cases or error conditions
  • Note to self: More cold soft drinks are needed / programmer food would be nice, too

A great, educational way to spend the evening. Thanks to all the participants – I look forward to the next meeting.


27
Apr 12

The main benefits of TDD

For me, there are two main, long-term benefits of TDD (Test-Driven Development):

First, by using TDD (thus writing the tests first) you make sure that your code remains in a testable state all the time (even if you don’t write all the tests to cover all the edge cases) – As anybody working with legacy code can attest, adding unit tests to an existing code base is usually excruciatingly hard and takes a lot of time. It can be done – witness Working with Legacy Code, sure, but it’s a very long and thorny journey. You don’t want to go down this road with the new code you’re writing every day.

Second, by using TDD you always have a decent, highly decoupled design – not a perfect or insanely great design, but quite a usable design to go forward. More often than not, it will be a better design than you’re used to.

“Test-Driven Development” is actually “Test-Driven Design”.