What is a coding dojo? Well, there is no “official” standards body, but the best definition I have come across is this:
“A Coding Dojo is a meeting where a bunch of coders get together to work on a programming challenge. They are there have fun and to engage in DeliberatePractice in order to improve their skills.”
Each meeting of the Code Dojo usually begins with someone presenting a “prepared code kata”. This is where a developer writes code “live” in front of an audience to find a solution to a standard problem. As far as I know TDD is the approach always used. The developer provides commentary as he/she types to give some insight into the thought process they are using. After the prepared Kata is complete there is a discussion session where questions can be asked and opinions shared.
After the prepared Kata we break up into small groups of around four people each. In each meeting we work on a problem, with the focus on learning a new technique or experimenting with different approaches. The exercises are performed in groups, with each group choosing an implementation language (and also a communication language :-).
The exercise – How far can you take TDD?
Today we followed a practice inspired by Keith Braithwaite first tried out during his worktorial at the Software Craftmanship 2009 Conference. The rules are deceptively simple:
45 minutes: do a bit of programming. A simple problem will be presented. Attendees solve it working in pairs, with the navigator VERY strictly enforcing this micro-process:
1) write exactly ONE failing test
2) make the test from (1) pass by first writing implementation code IN THE TEST
3) create a new implementation method/function by:
3.1) doing extract method on implementation code created as per (2), or
3.2) moving implementation code as per (2) into an existing implementation method
4) only ever create new methods IN THE TEST CLASS
5) only ever create implementation classes to provide a destination for extracting a method created as per (4).
6) populate implementation classes by doing move method from a test class into them
7) refactor as required
8) go to (1)
At first glance this seems like the logical conclusion to following TDD practices. The only real constraint is to write the production code in the test code.
We used the tic-tac-toe problem as an arbitrary problem to solve with this approach, using java and the eclipse IDE. First we started out codifying the rules in the most basic way we could, and eventually a couple of common concepts emerged (isGameOver, numberOfMovesMade). Towards the end we finally got to a stage where we couldn’t make further progress without introducing a “board” concept, then the tests started getting interesting. To get to this stage took quite a big effort though, so we didn’t really have a lot to show at the end of the session.
This was a fun way to explore the boundaries of what’s possible with TDD. On the other hand, it was very constraining; many people in the meetup felt it was “like programming with your hands tied” and I have some sympathy for this sentiment. On the positive side you are forced to not rush blindly into implementations or abstractions that are later constraining. On the other hand, to me at least, it seemed arbitrarily over-disciplined. Also this method is really only practical for implementation languages that have good automatic refactoring tools, prettty much ruling out using this technique in my daily work.
The Oslo Coding Dojo is a lot of fun. If you live in the Oslo area and are interested in learning more about software development practices this is a great place to come. The people are friendly and engaged, and there are many lively discussions. You can join the group here:
Background to the idea of Code Kata:
The original worktorial from the Software Craftmanship Conference:
A good writeup of the approach written from an attendee at the Software Craftmanship Conference:
And also a follow-up post: