ERNI Technology Post No. 39 - Coding Dojo

The conductor of an orchestra or a choir, on the other hand, aims to bring the individuals together, so that they understand each other, follow the same standards and rules, talk the same language, can help each other - and create something together as a team, as a harmonious team, in an efficient way.

How do professional software engineers practice and improve their skills? Do they exercise at all, or are they "in concert" all the time? How does a team of software engineers improve and get more efficient? Moreover, all software team/project leaders want top quality and high team performance in terms of speed, for example. But what is being done, what is being invested in a team to actually get close to this level?

The Coding Dojo methodology may give answers to all of these questions! In fact, real-life software projects show clear benefits from this methodology for both individuals and the team.

This article gives an introduction to the Coding Dojo methodology for both software team/project leaders and software engineers. The first two sections present an overview of what a Coding Dojo is, and what forms of it are available. Then, a walk-through of a simple example illustrates how a Coding Dojo could work in practical application. The article concludes with some real-life experiences of the author's, followed by a short summary.

What is a Coding Dojo?

A Coding Dojo is a methodology for improving the quality and performance of a software developer team. The methodology defines an environment for a group or a single software developer to practice writing program code. Hence a Coding Dojo is a framework for practicing writing software in a formal environment. Besides training, a Dojo can also provide an environment for examinations and other related encounters [1].

This framework cannot only be used for practicing writing code; it can also be used for practicing other known and established methodologies such as Pair Programming [2] or Test-Driven Development (TDD) [3].

Now, where does the name of this methodology come from? A Dojo is a place for any kind of physical training. In martial arts, for example, a Dojo is used to approach perfection. Every movement is to be perfect. All the movements are then put together in one fluent enactment.

The goal of a Coding Dojo is to achieve perfection in writing code (not to write perfect code!), meaning to write code more and more efficiently and to achieve a common understanding of how to write code in a team.

This can be achieved by practicing as a single developer (like the musician) or as a software developer team (like the orchestra).

Different forms of Coding Dojo

There are different forms of Coding Dojo [4]. The most important forms are described in the following sections.


Kata is a Japanese word referring to detailed choreographed patterns of movements practiced either solo or in pairs.

In a programming Kata, the movements needed to solve a programming problem are being practiced. The goal is not to practice solving the problem - the solution is already known - but to practice how to write lines of code in a perfect manner and how to assemble these lines of code into a smooth and fluent, easily readable piece of code.

You repeat the Kata over and over again. As you practice you will discover subtle improvements and efficiencies either in the solution itself or in your movements (using shortcuts instead of using the mouse).

There are many possible Katas, e.g.:

  • KataTennisGet the correct score resulting from a sequence of rallies won by the tennis players.E.g. Player A wins three points, player B wins two. The result should be 40:30.
  • KataPrimeFactorsThe program is to factorize a number into prime factors.E.g. 42 can be factorized into the prime numbers 2, 3 and 7.
  • KataRomanNumeralsThe program is to convert normal numbers to Roman numerals.E.g. 1 -> I, 10 -> X, 42 -> XLII.


In a Wasa, one person writes code, while the other gives hints for improvement. An alternative is to do ping pong pair programming [2], in which one person writes a unit test, and the other must make it pass. Then they reverse roles.

Both kinds of Wasa are quite similar to a two-person Kata.


This Dojo is played by several people with varying roles. While one person writes a unit test, the others observe the way the code is written. After the test is written they give feedback about possible improvements. Then the next person makes the test pass and writes the next test. The next person makes this failing unit test pass and writes the next test, and so on.

An example of a Coding Dojo

In the following walk-through example a team of six software developers are doing a Coding Dojo. It was a team decision to do a Randori with KataTennis.

The setup

It is important that the team does the Coding Dojo in an environment that it usually works in and that is therefore familiar to everyone. This particularly applies to tools and their settings, such as an IDE for example. Moreover, every team member must be able to observe the movements of the person that is coding.

The Coding Dojo is time-boxed, let us assume the team agreed on a duration of two hours.


The goal of this Kata is to have a program which can write the correct score of a tennis game at any time. The program is to state normal scores such as "40:15" and scores such as "Advantage A" or "B won".

The constraints

As was mentioned in section 2, Coding Dojos offer the possibility to practice other methodologies like TDD simultaneously. In the present example, the team decided to focus on TDD and BabySteps [5].

The Dojo

Team member Bob starts the Dojo. He writes some TODOs and the first unit test. Then Bob runs the unit test to make sure that the test is failing. As he leaves the notebook, the code looks as is shown in Code 1.

Code 1: First unit test

Code 2: First GetScore() Implementation

Before the next person takes over, the team gives feedback as to what could be improved.

The team tells Bob that he should choose the name of the unit test more carefully. It was decided some Coding Dojo sessions before that the team prefers a naming that follows the scheme TopicWhenConditionThenExpectedResult. Hence, the name of the unit test should be: GetScoreWhenInitializedThen0_0().

Flora is next. She has to make the unit test pass as fast as possible, so her implementation is extremely simple (Code 2).

Now Flora writes the second unit test, according to the TODOs. She selects Bob's re-named unit test, copies and modifies it (Code 3).

To make sure the unit test compiles, Flora writes an empty ScoreA() method in the Scorer class.

Code 3: The first time a player scores


As expected, the new unit test fails.Now, again, it is time for the team to tell Flora what she could have done better, in a more efficient way.

Todd, the keyboard shortcut genius of the team, suggests increasing work efficiency by using the appropriate keyboard shortcuts instead of using the mouse and typing code manually.

Bianca is the next person to sit down in front of the notebook. She tries first to turn the failing unit test into a passing one as fast as possible, deletes the TODOs and then does some refactoring. The unit test she writes afterwards is called GetScoreWhenAAThen30_0().

Code 4: A possible KISS implementation


This time the team explains to Bianca that she should stick to the KISS principle [6]: Bianca introduced a field that holds the score. The GetScore() method translated the score to a string. A simpler and faster solution would have been that shown in Code 4.

Bianca agrees because the team has committed to practicing BabySteps.

After two hours time is up. The Scorer class can handle the scores up to 40. The test case where Player A wins is also covered. But none of the Advantage situations are covered - which is fine because it is not the goal of the Coding Dojo to write a complete tennis game scorer.

In this example, some of the team members learned a lot about keyboard shortcuts, about naming conventions and about following the KISS principle. Some will use the newly learned shortcuts in the productive environment as well, and some will need to do more Coding Dojos until they get used to them. However, the team will certainly discuss the experiences of the Coding Dojo session, right after it has ended, or during coffee breaks, which is also a great way to implement what was learned.

What's next?

In this Coding Dojo session the KataTennis was done. After this first session the team should now understand the problems posed by a tennis game scorer. In order to improve the efficiency of each developer in the team, it is important that the same Kata is used again in the next Coding Dojo session. In this way, the team can really concentrate on efficiency rather than on how to solve the specific problem.

After three or four sessions, the concept of doing a Coding Dojo is clear to everyone. The team can then choose another problem to be solved (another Kata, e.g. KataRomanNumerals), or do a Wasa or the pure Kata instead of a Randori.

The team could also shift the focus. For example the team could decide to practice the use of the single responsibility principle. In this case the team will see how different things are if there is an ITennisResultConverter which is responsible for converting a result of 3:2 into a result of 40:30.

Experience of a real-life project

In this section the author reports about his own experiences made with Coding Dojos, including personal benefits and benefits for the team, and how the results could be measured.

I once joined an established project team that had recently gone through a lot of change. A total of four persons were new to the team, three persons had left or were about to leave the team.

When you join an existing team, you face a number of challenges: What are the specialties of the domain? How does the team write code? Where is your place within the team?

With the help of regularly held Coding Dojo sessions, we newbies learned about the dos & don'ts in the team, and how to write code in this group of software engineers in general - in a very efficient way.

I personally learned a lot of shortcuts, which increased my efficiency significantly. Within the scope of the Coding Dojo, I also had the opportunity to suggest ways of writing code different than how the team used to do it. Moreover I learned how to write code so that it fits well into the existing code.

Above all, we discovered that the success of the Coding Dojos can be measured in a very obvious and plausible way: Following an agile software development process, team velocity is a parameter that is available anyway. During the first sprints with the new team setup, we recorded a poor team velocity of about 7 story points per sprint. Now, after five months and 10 Coding Dojo sessions, the team performs 17 story points per sprint.

Obviously, the positive impact of the Coding Dojo method can be measured in a very simple way, namely based on team velocity. I personally believe that it can be felt in the growing team spirit, too.


Just like musicians or an orchestra, software developers should also regularly practice their craft as professionals. A Coding Dojo provides the framework for such practice. Here, on the one hand, the developers are able to advance their movements to perfection, and on the other hand, they learn to play together as members of a harmonious team. The progress of a team can even be measured, for example based on increasing velocity.

Finally, a Coding Dojo has another advantage: it's just fun for everyone!





[4] Robert C. Martin: The Clean Coder, ISBN: 978-0-13- 708107-3