Sometime last year I came across Dave Thomas’s Code Kata page and I thought, what a great way to learn a new language, or even just shake the rust off. Eventually I learned that some teams practice code kata’s together. This is known as a code dojo. Since I enjoy team building possibly more than I like software building, dojo’s make kata that much more intriguing.
Why dojo’s? Let’s face it, there are some serious limitations to learning on the job. Sure, Apex Tech seems to like the idea, but even they have a standard curriculum you must follow before you graduate with the tools of the trade. The problem with learning software on the job is the occasionality of the problems which catalyze the lessons. Some very important lessons may go unlearned based on how frequently they come up, or based on the level of exposure to the problem your role permits. There are certainly some common skills we must all acquire and some common lessons we can all learn which will help us avoid repeated mistakes in the field of software development.
We software developers have an additional problem, our craft is quite young. It’s only recently that we’ve started to shift away from thinking of it as a field of Engineering, and college programs haven’t even perfected teaching the engineering version of it yet. It will be decades before programming students begin to enter the field with the required skills to hit the ground running. Collectively, we are far too reliant on “on the job training.” Code dojo’s are a great way to start learning those common lessons in a training environment, as well as help unearth some of the team incongruities that go unadressed in our our day to day work and often slip under the radar of our retrospectives.
I have come across 2 types of code dojo’s. A simple kata is a staged execution of a solvable problem. Kata’s allow the group to watch solution performed illustrating good form. A randori dojo is more dynamic and interactive. In a randori the team collectively codes the problems solution.
Wikipedia currently defines a randori as: a term used in Japanese martial arts to describe free-style practice or sparring, sometimes with multiple attackers. The term literally means “chaos taking” or “grasping freedom,” implying a freedom from the structured practice of kata. This definition may be what intrigued me the most. The most effective form of practice resembles reality closely. In a randori the the problem is fairly simple, it should be something that the team can easily get their heads around. The focus shouldn’t be on the problem, but rather the techniques used to solve it, and the problems that arise during the course of the randori. It is not necessary to solve the problem completely. Similarly to rock climbing, it’s about the climb, not the summit.
For our randori’s we have adopted the rules that are very well laid out by Agile Finland on their code dojo page. The rules of the randori like anything else on an agile team are subject to reflection and modification. Each randori ends with a quick retrospective, the output of which helps refine our rules.
- There is a coding challenge that is announced beforehand.
- There is a room with one computer attached to video screen and set up as a pairing station (2 keyboards, 2 mice).
- The presenter explains the coding challenge and starts the Randori with a pair from audience.
- One half of the pair is changed every 5 minutes.
- The pair on the keyboard should continuously explain what they are doing.
- The pair on the keyboard should stop when someone from the audience falls off the sled — and only continue when that someone is back on track again.
- The audience should give comments on design only when there is green bar. (During red bar audience can only ask questions)
- The pair should not continue on writing new code if other participants are not happy with the current design (The code should be always well refactored before starting to write new code)
- The pair will use TDD (Test-Driven Development), preferably employing the ping pong model of writing and passing tests.
- The programming language to be used is announced in advance per session.
- The maximum number of participants is limited to 15.
- The presenter acts as a product owner
- The actual coding is done in small iterations. There are short planning period before every coding iteration.
Some randori’s end up being clean practice session and a knowledge exchange for best practices and good craftsmanship. They usually start off a little rough but really gain momentum during the second iteration. These randori’s have helped us model good behavior in terms of TDD and pairing. Other times we’ve run into a rut which prevents us from making good progress on the randori problem. We find these randori’s to be even more valuable than the former. They expose the problems that hinder us during our day to day work but are less noticeable in the broader context of an iteration.