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.
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 or Test-Driven Development (TDD).
Either a single developer or a team of developers is achieving perfection in writing code (not in writing perfect code!), meaning to write code more and more efficiently and to achieve a common understanding of how to write code in a team.
- A small problem (so called Kata), like KataRomanNumerals or KataTennis
A list of possible Katas can be found on the internet (e.g.: www.katawiki.org)
- The form, how the Coding Dojo is done (Kata, Wasa or Randori)
- The environment, the team/developer usually works with
Different forms of Coding Dojo
There are three different form of Coding Dojo:
The pure Kata
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).
Since this form of Coding Dojo is suitable for a single persons or small groups it is useful for improving the dexterity of each single developer. If a developer needs to learn a new tool the pure Kata is useful.
In a Wasa,one person writes code, while the other gives hints for improvement. An alternative is to do ping pong pair programming, 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 Kata that is practiced in pairs.
This form of Coding Dojo is suitable for a pair of developers or more. Therefore the Wasa can be used for practicing Pair Programming and Test Driven Development and likewise methodologies.
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.
This form of Coding Dojo is suitable for three and more developers. The Randori is therefore most suitable improve the common sense in a team of how to write code.
Depending on the kind of Coding Dojo, one person is coding (Driver); another person is assisting (Navigator). The other team members are watching how the small step of the Kata is solved. After a while, for example, after the first unit test is passing, the roles are changing. Before the next unit test is written, the team gives some feedback: What could have been done in a more efficient way? Where the rules of TDD and Pair Programming correctly applied?
Since the Coding Dojo is time-boxed, the Dojo ends when time is up. It doesn’t matter if the problem is solved or not. In the next Dojo it’s important that the same Kata is done again. This time, the team will be able to focus more on “How to write code more efficient” rather than in how to solve the specific problem of this Kata.
Depending on what kind of Coding Dojo is done:
- Driver & Navigator in case of the Wasa
- Developer in case of the Pure Kata and Randori
- Audience that gives feedback
The output will be some code that will be thrown away! But in the meantime, the team of software developers will gain their common understanding of how to write code and will write code in a more efficient manner.
Since the team is improving the common understanding in how to write code in the team, a possible output could by, that the team modifies the coding guidelines of the team. In order to have them suitable for the current “team-spirit”.
Tools / Templates
The tools and settings the developers are usually working with.
Coding Dojo or Code Retreat?
The goal of the Coding Dojo is to learn how to write code perfectly. Meanwhile, the goal of a Code Retreat (see Service Item Code Retreat) is to learn how to write perfect code.
The Code Retreat is more suitable, when you want to:
- Learn a new tool or methodology; the Code Retreat is an initial booster for learning something.
Let’s say, you want to introduce TDD to the team.
- Ramp-up new team members; in the Code Retreat the new team members can learn how to work with the tools and 3rd part libraries, the team is using.
E.g. the team uses a certain dependency injection library. The Code Retreat is the place to teach the new team members how to use this library.
- Improve the skills of the team.
The Coding Dojo is more suitable, when you want to:
- Practice the usage of the tools and methodologies; the Coding Dojo assures that the developers are professionals in the use of the methodology or tool.
After several sessions, the team will apply TDD, while they were sleeping.
- The new team members to understand the team-understanding of how to write code in this particular team.
- Keep the team on the current level of skills.
So, a Code Retreat is the place for learn something new, while a Coding Dojo is the place for practicing something the developers already know.
- Prepare the Coding Dojo, so that you don’t need to spend too much time in discussion how to solve the problem. Keep in mind: The goal of a Coding Dojo is not to write the perfect code; it’s more to write code perfectly (efficiently).
- Use the Coding Dojo to discuss about the way how code should be written in your team
- Be strict about principles you want to practice! (E.g. if you want to practice TDD, make sure every test fails before you start with writing the according code)
- In an agile environment the last day of the sprint is a suitable point of time, where a Coding Dojo can take place; the team will have anyway Retrospective and Sprint Review Meeting on the same day.
- Depending on the team size, a time boxed size of 90 minutes for the Coding Dojo is a good point to start.
- Do the same Kata in several sessions; the first session the developers will only learn to understand the problem. Only if the problem is well known, the developer can concentrate in writing code perfectly.
- Depending on the Kata, after 5 to 7 sessions another Kata might be chosen.
Some professional musicians, for example, do the same “Kata” (=playing the scale) during years!
- For a change after a few sessions of Coding Dojo, a different form of Dojo can be applied.
- Some developers think that they don’t need to practice. But do you know any professional musician that never practices? Any professional athlete that never practices?
- Being a professional developer means practicing. The Coding Dojo is the place to practice.
A professional musician will never stop practicing. A professional developer also, will never stop practicing!