Running a coding dojo: choosing a kata and driving it with TDD
A coding dojo most often fails for a simple reason: the group treats the session like an assignment with a shorter deadline, when the goal isn't to finish the exercise, it's to observe and discuss how it gets solved. The format and the chosen kata determine whether that distinction survives the first half hour.
Two formats, two different dynamics
| Format | How it runs | What it favors |
|---|---|---|
| Randori | One pair at the keyboard in front of the group, rotating every 5-7 minutes | Collective discussion, each rotation picks up where the last one stopped |
| Practice-in-pairs | Every participant paired up, working the same kata simultaneously | More code written per person, but less shared discussion |
Randori suits a group new to the practice better: frequent rotation prevents one pair from locking into a single direction, and the rest of the group actively observes rather than coding in parallel without ever seeing other approaches. Practice-in-pairs suits a more experienced group better, one that wants to compare several independent solutions at the end of the session.
Choosing a kata: what actually matters
A good kata for a 60-90 minute session has to hold three constraints at once: small enough to finish in the time available, rich enough to reveal a real design tension, and not reliant on a trick that, once found, makes everything else trivial. That last point rules out a lot of seemingly-popular katas: a problem solved by a single "aha" moment turns the session into a hunt for the trick, not a TDD practice.
| Kata | What it forces you to work through | Why it works well in a dojo |
|---|---|---|
| String Calculator | Progressive escalation of rules (multiple separators, exceptions, custom delimiters) | Each added rule forces a fresh red-green-refactor cycle without ever needing a full rewrite |
| Bowling Game | Incrementally computing a score with overlapping rules (spare, strike) | Reveals the temptation to over-engineer too early, before the simple cases even demand it |
| Roman Numerals | Translating a conversion rule without a cascade of if/else | Good ground for practicing techniques that avoid nested conditionals |
| Mars Rover | Modeling a state (position, direction) that evolves through commands | Good material for discussing sealed classes or state modeling in general |
FizzBuzz, despite its popularity, doesn't hold up: the complete solution fits in a few lines from the very first cycle, leaving nothing left to explore once the first test goes green.
Driving the Bowling Game kata with TDD, step by step
The Bowling Game illustrates well the progressive escalation a dojo is meant to produce. The classic sequence of tests, in the order they're written:
- A completely missed game (every roll is 0): the expected score is 0. First test, trivial implementation.
- A game with no bonus (every roll is 1): the expected score is 20. Forces a first calculation loop, without yet handling spares or strikes.
- One spare (a roll of 5, a roll of 5, a roll of 3, the rest 0): the expected score is 16. The spare's frame is worth 10 plus the next roll (10 + 3 = 13), the following frame is worth 3. This test forces the generalization of the spare bonus.
- One strike (a roll of 10, then 3 and 4, the rest 0): the expected score is 24. The strike's frame is worth 10 plus the next two rolls (10 + 3 + 4 = 17), the following frame is worth 7. This test forces the generalization of the strike bonus, structurally different from the spare's (two following rolls, not one).
- A perfect game (twelve strikes): the expected score is 300. This last test verifies that the tenth frame, which has a special rule (two bonus rolls instead of one), is correctly handled by the generalization already in place.
Each step follows the discipline detailed in the article on real TDD: test first, red verified, minimal implementation, refactor before moving to the next case. The dojo's pedagogical benefit comes precisely from that sequencing: jumping straight to the general score-calculation implementation, without going through the intermediate cases, deprives the group of the most interesting part of the discussion, the one about why each generalization showed up exactly when it became necessary, not before.
The deliberate constraint, an underused tool
Adding an artificial constraint ("no for loops," "no more than three lines per method," "commit every two minutes") forces the group to explore a design direction it wouldn't have taken spontaneously. That's not gratuitous complication: it's the most reliable way to surface design techniques that the most natural solution never reveals, precisely because it looks too obvious to be worth discussing.
What a dojo isn't
A dojo isn't meant to produce code that ships to production, nor to crown the "best" solution among the pairs. The end-of-session retrospective is worth more than the code produced: comparing two different solutions to the same kata, understanding why one emerged earlier or later in the test sequence, is the exercise that actually transfers to real work, far more than the exercise itself.