Last week Wednesday, I organised my first Code Dojo! For those that are not familiar with the concept, a Code Dojo is when programmers get together to exercise their craft by solving a problem together. The problem is called a ‘Kata’, analogous to the way these concepts are used in the Karate world.
As a problem, I had selected the ‘Gilded Rose’ Kata, for which I have created a Java version a while back. I figured that since this is a refactoring Kata, the type of problem would be all too familiar to my colleagues…
While preparing for the Dojo, I asked for advice on twitter. Luckily, Mark Levison reacted, and had some good advice (“Keep It Simple!”). What’s more, he had documented his own first experiences (first and second dojo) very thoroughly! We had enough pizza.
Based on that advice, I tried to simplify the kata a little, giving us a headstart by starting off with some already implemented acceptance tests. (See my FirstTry branch to look at the integration tests. I didn’t do that try test-driven (tsk!)). The idea was that this would save us some time, and let us jump right in to TDD-ing the refactoring.
I also figured that it would be wise to do a little introductory presentation on what a Coding Dojo is, and what is important for Pair Programming and TDD. I found a nicely made presentation on slideshare by Serge Rehem. Unfortunately, it was in Portuguese, which I don’t speak. A little Google Translate, and imagination, helped though, and I created a translated version.
On the evening itself, after Ciarán got everyone warmed-up and enthusiastic with a run through Boris Gloger the Ball-Point-Game, we started the dojo with the 5 minute (well, at my speed, is was about 15-20 minutes) introduction using those sheets, and going into the specifics of working with TDD. Then we briefly discussed the kata, and got going.
At this point I was very happy with the ‘Keep It Simple’ advice, since we obviously needed time to really get started. We were working with 5 minute turns at the keyboard, but since we were still getting the hang of this, those sometimes turned out to be a little longer. Unfortunately, this meant that not everyone got their chance on driving, but the whole group did join in the discussion.
We also got some discussion going about the why and how of working Test Driven, which was a lot of fun, and precisely the point of the exercise, of course.
So what are we going to be doing different next time?
- We’re going to plan more time. We had about 90 minutes, including the introductory presentation and discussion of the Kata, that didn’t leave us enough time to get through the problem
- We’ll need to pick a smaller Kata. The refactoring Kata is fun, but it is not small enough, especially when starting out with Coding Dojos.
- I will not write tests in advance! This helped keep the assignment small, but not small enough, and it allowed us to go too quickly to coding, without really understanding the assignment. This was actually one of the main complaints: the goal of the exercise wasn’t clear enough!
- We’ll ask everyone to try the Kata in advance, so that we can focus on the process of writing code together, instead of on understanding the problem
- We’ll time-box the pair-rotating more carefully, so everyone gets a turn
Overall, though, it was still a lot of fun, and most people really liked the idea of doing real hands-ons learning during our regular get-togethers withing Qualogy.