me.andering – Willem van den Ende

Eric Lefevre and I co-organized a coders dojo at CITCON Amsterdam a few weeks ago. A coders dojo is where programmers meet to collaborate on a programming challenge, so that they can improve their skills.

What is a dojo?

The dojo takes its’ inspiration from martial arts, where practitioners get together to repeatedly practice excercises (‘katas’), amongst each other or guided by a teacher.

Coders dojos exist in many shapes. The form I often use is called ‘rand

ori’ : one or two people prepare an excercise, explain the excercise to the group and start pair programming on the excercise in front of the group, using a video projector. After five or ten minutes one of the original pair rotates out, and someone from the audience rotates in. Rotation continues every 5 or 10 minutes.

yours truly and Eric Lefevre kicking off the Randori

Benefits

• Improve your skills by doing, and seeing other people do it (also teaches small things about editor etc.)
• challenge and be challenged: accept criticism, defend your ideas, deliver criticism in such a way that others are encouraged to act on it
• Learn how to better work in really, really small steps. If you want to rotate out in 10 minutes with a green bar – all tests pass – you have to

@ CITCON Amsterdam

This is also the form Eric and I used at CITCON Amsterdam a few weeks ago. We both had posted a coders dojo on the open space schedule. I wanted to do a dojo with Mockito (a relatively new mock objects framework for java), so that I could try out a modified excercise for an upcoming training on Responsability Driven Design with Mocking. Eric wanted to do a kata on legacy code, so that he could experiment with an excercise he uses in courses.

We decided to apply some courage and try to see if we could combine the two: use Mockito to add tests to Eric’s case. We started after very little preparation: while we were preparing a heated debate with other conference attendees on how to teach mocking and what (not) to use) already started… We introduced the case and started to work towards adding a test. We found a defect in the only test present (it was not completely legacy code ), and we let the audience decide whether we should fix the test first.
The audience decided we should fix the test. We listened. Therefore we did not show how to use Mockito… Fixing the test eventually took the better part of the coders dojo, and we never got around to having the participants to try out Mockito to make a test running. Eric already summarized what came out of the mini retrospective at the end of the session.

The audience vs. Ivan Moore and …

Coding in front of an audience can be confusing at times

A test is not worth fixing, if it is the only one you have.

I would normally delete this test, guess its intention(s) and re-write the test from scratch. The reason this test was so difficult to get working, was that it was trying to do multiple things. In making the test work, it started to test even more things, so while fixing it, it became increasingly more difficult… If we had rewritten the test, we would have discovered this early on. We then would have noted the other things to test down on our ‘to do’ list, gotten a green bar quickly and then moved to the next item on our to do list.

Programming as a spectator sport. Henk Van Voorthuizen, Marc Evers watch Intently, Jamie Dobson takes notes (he was making a diagram of sorts I believe).

Some things I learned

Having some of the most clever bastards of Europe in the room made this session extremely interesting. It definetely showed me there is ‘more than one way to do it’, and that includes refactoring and adding tests to legacy code. Some will do nothing without a test, some will use automated refactorings only (me) and then add the first test ASAP. Many of these strategies work most of the time… “Many people can be right most of the time, not all people can be right all of the time”, and that shows in a dojo. Most strategies would work to make the situation of the legacy code base better (better factored and/or more tests), but changing strategies every few minutes does not .

As Eric says, I’m sure we’ll do better next year. One thing I would try would be to spend more time at the start demonstrating and setting out a direction before rotating in someone from the audience. That way, I would expect less confusion by the participants, and more work in the same direction. This is what I normally do during courses, but the session slot had so little time that we (erroneously) skimped on it.

In the meantime, I’ll be doing some more experiments in (ab?)using mocking tools to shorten the “time to first test.”

Credits

• Laurent Bossavit and Emmanual Gaillot for popularizing the idea of a coding dojo
• The writers of DeliberatePractice for explaining some of the benefits of a dojo
• Marc Evers for making photos (and lending me his camera during the dojo)
• Eric Lefevre for the first writeup
• The participants for making this a very interesting dojo

This entry was posted on Tuesday, October 21st, 2008 at 3:54 pm and is filed under people & systems. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.