|
Coding Dojo Primer
Introduction
I have been spurred on to write a blog about coding dojos
by a double coincidence of wants: recent requests for information
and my own thinking on the matter during some great dojo practice
sessions with a good coding buddy of mine, a sensei of source code (he knows who he is!).
What is a Dojo?
This is a term that derives, as with many things in Lean and Agile,
from Japanese martial arts training. It is a place where students gather to train
under the watchful eye of a master. Well that is what we have interpreted and
inferred but as barbarian westerners we have pretty much mixed up the place (dojo means "place of the way")
with the practice and could get into some seriously ill advised altercations with true students of martial arts. All that being said, for better or for worse, the term has been appropriated and the next question is
What is a coding Dojo?
I first heard about coding dojos back around 2005 when I read what
Laurent Bossavit had to say:
«If I want to learn judo, I will enroll at the nearest dojo, and show up for one
hour every week for the next two years, at the end of which I may opt for a more
assiduous course of study to progress in the art. Years of further training might
be rewarded with a black belt, which is merely the sign of ascent to a different
stage of learning. No master ever stops learning. If I want to learn object
programming... my employer will pack me off to a three-day Java course picked
from this year's issue of a big training firm's catalog. Nuts to that
-- acquiring coding skills is not an "instant gratification" process.»
This lead me to finding out about the roots of the
dojo in Paris (the Paris dojo is still run weekly and has inspired other long running dojos
around the world). I made the aquaintance of Emmanuel Gaillot at the Benelux Agile Open.
Emmanuel had kicked off the first coding dojo in December 2004. Among other things
he is also a founder organiser, with some other truly Agile people, of
the French Agile Open for francophones. He is an engaging person and I always love meeting him and seeing what he
is up to because it is always going to be interesting.
I loved the idea of dojos straight away. The Coder's Dojo offers a way of
teaching and learning programming in a more appropriate manner, respecting
the depth and subtlety of the craft. A Dojo is a weekly meeting between
programmers of varying skill levels. They come together as equals -
in physical, not virtual space - around an ongoing series of coding
challenges called "code kata". It is a very old way of learning and practicing. Some suggest
even older than the socratic method (but that would take up the whole blog to discuss).
I immediately started implementing them with
teams I was coaching and recommending them to all other coaches and programmers I knew who were trying to fill the
practical reality gap created by surface level, trendy Agile. It provided a perfect
way to introduce TFD/TDD (Test First and Test Driven Development) and pair programming. It also provided a mechanism to build on
programming skills in a non-threatening and stress-free way because it was decoupled
from the pressures of work. Much to my delight they took on a life of
their own everywhere I seeded them. Developers are quick to realise the power and
elegance of the practice.
It might help you to understand why this is such an attractive way if you realise
that many programmers consider coding to be a constantly developing craft.
They realise that you have never finished learning and that you can learn
useful things from other practising adepts. We recognise that, as in many fields,
there are journeymen and masters.
Watching a master at work and sharing with other journeymen motivates and inspires
many of us to continue perfecting our craft and exploring our art.
Kata and Randori
There are two sorts of Coding dojo: Kata and Randori.
Kata
This takes the form of a rehearsed session.
That is someone has worked a problem through and demonstrates during the session.
Note: they work through the problem again from scratch they do NOT walk through imported code!
Here are the kata rules (probably I adapted them from Laurent’s) that I advise:
- Rehearsed: the solution is rehearsed beforehand by a coder or preferably a pair of coders
- Choreographed performance: the coders re-create the solution during the session
using TDD and pair programming.
- Interactive
: the Group can comment on design and coding style and can suggest improvements.
- Continuous improvement: the group creates the solution that it feels is best, clearest and simplest
- Leisurely: there are breaks for design reviews and discussions
(and coffee is almost obligatory)
Randori
This has not been rehearsed and the group as a whole works through it. Think improvisational
performance with audience participation.
Here are the randori rules (adapted from Laurent’s) that I advise:
- Improvised: the problem is introduced at the beginning of the session and the whole group attempts to solve it in real time using pair programming and TDD.
- Pairing: group all take turns at the keyboard for about 5-7 minutes as pilot and co-pilot.
- Interactive
: the Group can comment on design and coding style and can suggest improvements.
- Continuous improvement: the group creates the solution that it feels is best, clearest and simplest
- Leisurely: there are breaks for design reviews and discussions
(and AGAIN coffee is pretty much obligatory)
Here is a sample agenda for a dojo
- 4:00 - 4:05 Introduction to the challenge
- 4:05 - 4:10 Preliminary design session
- 4:10 - 4:30 Code
- 4:30 - 4:35 Design review and adjustment
- 4:35 - 4:50 Code
- 4:50 - 5:00 Retrospective and challenge for the next meeting
Some general rules for the dojo (I have been using these for ages and probably got them originally from Laurent or Emmanuel and adapted them)
- There is a coding challenge that is announced beforehand.
- There is a room with one computer attached to video screen.
- The presenter explains the coding challenge and starts the Randori
with a pair from audience or chooses a co-pilot for Kata presentations.
- One half of the pair is changed every 5 minutes if it is a Randori.
- The pair on the keyboard should continuously explain what they are doing.
- The pair on the keyboard should stop when someone from the audience
falls off the sled (has a question about understanding what the pair is doing) - and only continue when that someone is back on track again.
- The audience should give comments on design only when there is green bar (All tests passed).
During red bar (Tests failing - coding in progress) audience can only ask questions for understanding.
- The pair should not continue writing new code if other participants are
not happy with the current design. The existing code should be always well refactored before
starting to write new code.
- The pair will use TDD (Test-Driven Development).
- All produced code will be made publicly available
- The programming language to be used is announced in advance of the session.
- The maximum number of participants is limited to 15.
- The presenter acts as a product owner
- The actual coding is done in small iterations.
There can be short planning periods before every coding iteration.
Useful Links
Blog Home Page
|
|