Coding dojos explained by VISEO

Dojo techniques

With TDD (Test Driven Development), the idea is to develop tests before actually implementing the code. This is done in three phases:

- Write a red test that focuses on an isolated functionality and its behavior and the user until it works.

- Write a green test that is just enough code to get to work, as simply as possible, using code that already exist if necessary.

- Use refactoring to make the design as appropriate and readable as possible using Clean Code principles.

In dojo coding, the objective is to use TDD while successively implementing the smallest improvements possible (baby step principle). For example, if a dojo’s exercise had the objective to translate several roman numbers into Arabic numbers, participants might begin by testing the ‘I’, then implement the smallest possible solution, without projecting into what comes next and thinking about how to translate ‘MMCXLIV’ (2144). Once completed, the group would start working on ‘II’ and so on.

The refactoring phase is primarily where participants reduce the amount of duplicated code and code patterns (DRY). A good, simple technique would be to look for duplicated patterns in the code. If that is not the case, there is only one occurrence of each pattern and no refactoring is necessary. If a code pattern repeats itself once it is a coincidence, and it should be refactored only if it can be linked back to one of the exercise’s underlying rules. If a code pattern repeats itself more than once it is a recurrence and the participants refactor to limit any repetition.

It may seem impossible to complete a complex exercise under such conditions. This is partly true, but only partly. Even if the goal is not to finish the exercise no matter what, it is still frustrating to end after an hour and a half when it feels like only the beginning of the solution has been implemented. Even if the goal is not to finish the exercise no matter what, it is still frustrating to end after an hour and a half when feels like only the beginning. Nonetheless, it is important not to forget that the first TDD phase is a RED test, and therefore does not really work. Yet, in the roman numeral example, once the tests for ‘I’ to ‘XI’ have gone through and been refactored according to the above principles, it is highly likely that the tests from ‘XI’ et ‘XII’ will be green on the first go. According to TDD principles, they would therefore be useless. 

Programming challenges

As mentioned earlier, conding dojos are exercises in small groups, for which several coding techniques exist:

- Pair programming: developers get into pairs (ideally) with one PC and take turns at the keyboard. In this case one or more teams do demonstrations of their work at regular intervals where they show different solutions to the same problem.

- Mob programming: Only one person codes, for one of two reasons. Either the person coding is teaching the others about something (a programming language, a pattern, an algorithm…) in a live coding session. This is called a Prepared Kata. Otherwise, the others participate actively, telling the driver what to do and how to do it. In this last case, the driver usually changes at regular intervals.

- The Randori: a rare but interesting format where a pilot and copilot code in front of a group, and the group participates as well. In this case there is a rotation by pairs: the pilot leaves, the copilot takes over and someone new comes from the audience to copilot.

In both pair and randori programming, teams rotate. More precisely, the idea is to rotate every time that a new test is written and is at the red phase (TDD step 1).

And that’s it! That’s all anyone needs to know for organizing a dojo coding session. Now that you have the how, let me tell you why.

Coding dojo. What’s the purpose?

You might think it is a bit silly at first but one very good reason for doing coding dojos is that it’s fun. Taking time to remind coders that what they do is cool is essential. It motivates people to want to keep learning (it’s a sector in constant evolution so continuous learning is hardly a bonus), improving, harness best practices and to share them. That is reason enough to make group coding exercises a standard practice. But what makes it all the more interesting is its flexibility for learning and you can integrate many different concepts into the exercises.

First and foremost, TDD is an essential element for developing good, quality software. When it’s done well and applied to real projects it helps to shorten the time needed for development and testing, reduces the risk of regressions and improves the amount of tests coverage in an intelligent way. The challenge is to learn how to do it correctly and efficiently, and that can take months. Applying TDD to existing code can be tricky for beginners, and that is rarely compatible with the average project cycle. Dojo coding provides a practical solution to learn at a slower pace and without risk.

Another Coding Dojo’s strong suit is flexibility for teaching. The simplest of exercises can help to teach a new language, and it is easy to add different constraints to vary the disciplines being taught. For example, if a group needs to improve its IDE skills, a dojo session can ban mouses and only allow keyboards. It can help to work on an consequential legacy program and adapt to new code. Teams can switch pcs at regular intervals to help adjust to the new code. There are special dojos to learn how to refactor a legacy (the Gilded Rose by Emily Bache, in several languages).

To sum up, coding dojos are a great practice that can bring a lot of benefits to developing teams and that team leaders should encourage as a regular practice.

If you would like to organize coding dojos for your own team, business or school, look at these sites to find examples of coding dojo's exercises here:  http://codingdojo.org/dojo/, and here : http://codekata.com/ , and there are many more to choose from.