La règle du jeu est très simple, assimilée en un tour :
Un scénario utilisateur est convenu. Le but du jeu est de produire dans le temps imparti le code satisfaisant ce scénario. Le code est écrit "test-first". Les membres de l'assemblée passent chacun leur tour au clavier, pour écrire (et faire passer) un nouveau test. Ils sont aidés pour cela d'un co-pilote, qui au tour suivant deviendra le pilote, etc. Chaque binôme amène donc une nouvelle fonctionnalité, et chaque participant se retrouve à devoir :
- Refactorer le code le cas échéant;
- Ecrire le prochain test qui nous fait progresser vers l'objectif;
- Faire passer ce test;
L'atmosphère est très très légèrement électrique, avec une blague qui part de temps en temps, en rythme soutenable. Le codeur, frappé comme tous les autres par la Babel technologique, s'empêtre avec les semis-modes emacs alors que lui, sa vie c'est vi. (Il faudrait régler ce problème d'environnements multiples). Pendant que le binôme sèche un peu sur un test à écrire, les prochains consultent frénétiquement de la doc ou le Net pour trouver une implémentation ou la référence d'une classe ou méthode ruby.
Pour les nouveaux venus que l'exercice allècherait, quelques conseils :
- Le code est revu par 5 à 8 personnes au moment où vous l'écrivez. S'agit pas de bâcler.
- C'est considéré comme looser d'écrire un test qui passe tout de suite. En général son auteur efface le test; mais çà compte pour un tour.
- Ne laissez pas faire ceux qui essaient de monopoliser le clavier en tirant sur leur tour de test. Parmi leur tactiques :
--- "Attends, là je n'ai pas créé un nouveau test, j'ai juste modifié un test existant" (sous-entendu : c'est encore à mon tour);
--- "Là, j'ai juste ajouté un assert, pas un test."
Faire passer le test à l'aide d'un Fake It peut paraître subtil mais c'est aussi légèrement abusif : est-ce vraiment un cadeau à faire à celui qui vous a courageusement assisté pendant 5 minutes ? Si la bonne implémentation est introuvable c'est un cadeau empoisonné. Si la bonne implémentation va complètement de soi, c'est un coup bas !
Qu'est-ce qu'on gagne ?
L'intérêt d'un tel jeu ? Il est triple :
- C'est un jeu ou l'on gagne toujours -- c'est incroyable ce qu'on apprend en jouant à ce jeu, sur tous les tableaux : techniques, mais aussi style de programmation, langages, formes.
- C'est un jeu collaboratif. Si on n'innove pas, si on ne communique pas, si on n'organise pas, le jeu stagne. Ca ne vous rapelle rien ?
- C'est un jeu productif. Combien de temps vous faut-il pour coder le jeu de la vie (coder, pas hacker) ? Je pense qu'une équipe Randori-Round Robin peut faire çà en 2 fois une heure. En tout cas c'est au delà de ce que je pourrais m'imaginer tout seul.
En fait, je peux tout à fait m'imaginer une session de ce type appliquée à la réalisation d'un programme professionnel. Je serais curieux de voir le même problème confié à une équipe "Randori" et à une équipe traditionnelle spécialisée. Je me demande quelle est la part d'over head. Mettons qu'en "Randori" le code demandé soit produit plus rapidement et qu'il soit de meilleure qualité... (ces deux attributs se renforcent mutuellement à mon sens) La porte serait ouverte pour tous les changements de stratégies de développements dans le milieu professionnel ! Personnellement celui qui consisterait à remplacer la vie de bureau par un coding fest me paraît on ne peut plus intéressant.
This hurts. We had agreed on giving some written feedback after each dojo session, and I realize it's been ages (okay, just weeks) I didn't contibute in any way to this blog. What I find both frustrating and striking is, I did get some valuable insights at every session we had last month -- and I did mean to share them. Why stopping writing, then? I trace my silence back to the week of Feb. 14. We planned to have a dojo session that day, but my significant other reminded me few days before the session that it would fall on Valentine's day. I decided I had more important things to do than pondering over ruby code that coming evening. It turned out that most of the would-be attendees thought the same -- yes, all of us had forgotten that Feb. 14 is not any normal day... Coders, geeks, you know our kind. So eventually, we all decided to postpone the session to the following week.
Interestingly enough, someone mentionned on our mailing list that the postponing would be beneficial, since we would have more time to prepare our katas. Let's face it -- I've not been a really serious student during my engineering school time, and I already knew that in my case an extra week wouldn't actually change anything to my production capacity... I was actually wrong: it did change things. Although I have had some code to show since, my posting to the dojo blog fell to a null rate. I find it highly interesting that, as long as I am in the habit of doing something, I am more enclined to continue doing it while a slight perturbation in the rythm -- like feeling having nothing to write on a blog for a whole week -- makes it harder to pick it up again. After all, writing feedback about dojo sessions is something I had just felt natural a week before. Could it be that creative work has an inertia of its own, and that when it's stopped for whatever reason, one must deploy harder efforts to restart it than to just continue it?
I'm writing this post as an attempt to be back on (contribution) tracks. It is not the first time I stop a regular activity for a week, feeling it's just a one-time pause and finding myself six months later having done nothing related to this activity. This is the first time, though, that I have found a convenient way to bring me back to my former velocity -- that is, to acknowledge my stopping the activity through the activity itself.
We'll see how efficient this is.
Monday at the Dojo, none of us who were present had a prepared exercise, or "Kata" to present. So, we decided to do "Randori" instead; that seems to have the meaning of "free exercise" - proper form still being required.
The way we decided to structure randori turned out to be quite interesting. We had a pair sit down at the keyboard, and go three times through the TDD cycle - write a test, see it fail, make it pass, refactor. After three tests, the pair's navigator became pilot, someone else became navigator, and on we went in round-robin fashion.
This turns out to be a lot of fun, rather fast-paced - though I now want to experiment with 2-test or even 1-test round-robin variants. It has a feel that I suspect is close to ping-pong programming, which I've never really tried.
An interesting tension arises with respect to tests that we expect to pass the first time. This feels a bit like "wasting" one of your three tests - and I expect this would be felt more acutely in the 2-test or 1-test variants. So we try a little harder to have the first test we write as pilot be a failing test.
If that test wants something bigger than we can implement in a couple minutes, we're in trouble too; on occasion we had to go back and delete a test we'd written, so we could go back to a green bar and start over with a more modest next step. That hurts plenty.