A code kata, as defined by wikipedia, is:

… an exercise in programming which helps a programmer hone their skills through practice and repetition.

At NewVoiceMedia we have been running katas for the last couple of years. Katas have become an integral part of our interview and induction process, but as we’ve grown (from 15 to 60 engineers), they’ve become harder to run well across the whole development team.

I recently participated in a fantastic Agile Cambridge workshop that Red-gate ran, on their experience of running coding katas. This post summarises my takeaways.

Organisation

Running a kata with 10 people is doable. With enough planning, we can find a room and a time slot that suits everyone. Scaling this to 60 people is near impossible though. Here are some ideas that help address this problem.

Self-organise the practice, synchronise the review

Red-gate’s solution to location and timing is to publish a kata fortnightly, then let whoever wants to participate form into pairs. Each pair can then find a time and location that suits them. Finally, because much of the learning from a kata comes from sharing between pairs, all participants attend a review meeting at the end of each fortnight.

Pair with purpose

Deciding who to pair with on any task can be tricky. Some people get on, others do not. To get the most out of a kata, it’s helpful for the pair to have a “teach and learn” relationship (teach and learn is actually one of our values). Although Red-gate made kata participation voluntary, they impose the constraint that participants form apprentice-style pairs, with both parties agreeing on who is the mentor and who is the student. At NewVoiceMedia, we have eight feature teams, so we recommend an additional constraint of pairing with someone from another team.

Make it affordable

Katas are fun and addictive, especially for us engineers, who love solving puzzles. This means they can easily overrun, and take up two hours or more. For a busy developer, two hours may be hard to spare, so timebox the kata to one hour and the review to 30 minutes.

Practices

There are many different aspects to programming well; one kata can easily cover a multitude of best practices. Covering too many concepts can dilute the effect of the kata though. Red-gate shared the following great patterns to prevent this.

Just one thing

Each kata should focus on a single improvement, and over time, ensure that improvements from a range of areas are covered. Such areas should include:

• Craftsmanship such as multi-threading, minimising if/switch usage, and self-documenting code

• Tool usage, such as keyboard shortcuts, Resharper commands, IDE commands, and debugging

• Good practice

• Functionality

Gamification

When you’re doing a kata, how do you know if you’re improving at the practice? Measuring a developer’s effectiveness is difficult and highly controversial, so how do we do it? One solution is to define a single measure that is related to the improvement, which each pair can score themselves on. The review meeting is then a chance for each pair to compare scores, as well as lessons learnt. The key here is to encourage competitiveness, but in a light-hearted way. The scores are to help focus each pair on the practice, and make it fun, not to reveal who is the best developer or pair.

Example measures include:

• When practicing keyboard shortcuts, count the number of times the mouse is used; the lowest score wins

• When practicing baby steps (red-green-refactor), score a point for each step completed in less than 3 minutes; highest score wins

• When practicing minimising if/switch usage, score a point for each if/switch statement; lowest score wins

Keep it simple

Some katas are very simple (such as a string calculator), whilst others are more complex (such as scoring a bowling game). There is a time and place for complex katas, which take several hours to complete, but in this context, simplicity is best. You can achieve this by using the following structure on an index/A5 card:

1. Kata Title - summarise the problem and the practice

2. Problem - describe the problem to solve

3. Practice - explain what practice the kata is trying to strengthen

4. Measure - state how the pair should measure their improvement in the practice

 Here’s an example card:

What’s next

If you’re running katas and looking for ways to improve them, then these ideas are worth trying out. We’ll be applying these at NewVoiceMedia over the next few months, so stay posted for news on how they work out!