Coding by VISEO

VISEO Expertise

Dojos coding explained by VISEO

If you were to look up “coding dojos” in your favorite search engine, you would probably find a definition that looks something like this “Coding Dojos are small programming challenges done in groups that use methods very similar to TDD (Test Driven Development).” So, what are Dojo coding methods, how are they organized and what kinds of benefits do developers get from participating in them? An article of Julien, Developer Designer Engineer and Paul, Developer, 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 try to use TDD while successively implementing the smallest improvements possible (baby step principle). For example, if a dojo 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 see if the code is a unique pattern. If that is indeed the case, there is only one occurrence and no refactoring is necessary. If the code pattern repeats itself once the participants only refactor if they can be linked back to one of the exercise’s underlying rules. If the 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 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, dojo codings 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.

- The mob: 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 the previous team finishes writing a test and it 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.

Dojo coding. What’s the purpose?

You might think it is a bit silly at first but one very good reason for doing dojo 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 pour 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, reduce the risk of setbacks and improve the amount of tests 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 Dojo 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, dojo coding is a great practice can brings a lot of benefits to developing teams and that team leaders should encourage as a regular practice.

 

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