We held our 6th code dojo a few weeks ago and this time we decided to break the pattern and try something different. There are two documented types of code dojo. Prepared Kata where a presenter takes the participants through a worked solution to a problem. We’ve never tried this one and the Randori Kata where random teams of two programmers work for 5 minutes each at solving a “simple” problem with advice provided from the non-active participants. Until our last dojo, this is what we’ve been doing.
A general theme that came out of our randori kata dojos was that it got a little bit frustrating for the non-programmers and that swapping out the coders every five minutes was too distracting. We found ourselves not really getting anywhere near the solution even after two hours, which was starting to take the fun out of things. Also, because we were implementing TDD we found ourselves testing things like IO, which is difficult to test and which wasn’t really part of the problem.
So at code dojo VI we tried something completely different. We wrote a small framework called JTanks which is similar to JRobots and which provided a simple API for writing a TankDriver which would operate a virtual Tank in a virtual arena. Tanks are able to move around at variable speeds, fire missiles, lay mines, and scan the local area for enemies (and missiles and mines). The tanks are operated in real time with a simple granular game clock. We also wrote a small graphical UI for tracking the positions of the tanks so that we could watch our tanks in action.
We then split up into four teams of two; each team with the goal of pair programming a TankDriver. After an hour we re-grouped and got together for the first tournament. We used simple death match rules that the last tank standing in each game would get the most points and a tournament consisted of three games. After that, the teams returned to their desks to continue to build drivers this time based on the strategies they’d seen others employ.
Most teams employed TDD (which i would have thought very difficult in such a short time-frame) and one team did not. Interestingly, the team not using TDD actually performed the worst owing to a silly bug. The non-TDD team definitely had the most complex tank and actually the most successful tank was TDD’d but didn’t move – it would just shoot at the closest tank to itself and try and dodge incoming missiles.
The evening was very enjoyable. Developers didn’t have to worry about a complicated API and they got to see the fruits of their labours in action immediately as everyone started with a basic working tank. This was our first dojo to introduce a competitive element and that worked very well to spur on the developers to improve their strategy. Testing the tank drivers proved a little complicated and the newness of the JTanks API meant that a few bugs crept up on the night. However, this didn’t detract from the success of the evening and could easily be improved (and is being) for future dojos.
There are plenty of other competitive programming problems that could be used (efficient elevators in a building, poker or chess players, etc.) and when combined with a goal for development improvement (in this case pair programming) it makes for a fun and interesting dojo.