Agile 2009 - Day 3 - 26th August - Kake Coding Dojo

On Wednesday evening, after the talks were over, I organized a Kake Coding Dojo at the open jam area. We had 3 computers (my own running OS X, Thiago Colucci's with Ubuntu Linux and Pedro Leal's one with OS X) and about 10 people participating.
We chose Kata Bowling as our problem.

We built up the nice sheet you can see above (thanks Danilo Sato for the picture) with our explanation of the problem as well as the mechanics. This way, we intend to get people to join us on the fly while the dojo was already running. And it worked! We had about 3 or 4 people that came by, joined for two rounds and then left. A few people kept around just chatting about what was going on and wondering how to things were going. Thanks Pedro Leal for the picture below.

The same problem was being solved in Ruby, Haskell and Java on each computer and it worked about fairly well in all of them. We kept 7 minutes round as usual and just had some problems with missing experts on Haskell (just two people very familiar with the language and 2 more with some experience) which drove us to ask out for help to other Agile attendees.

Finally, we ran our retrospective which the result you can check on the picture above (or this link for the higher resolution one).

Our main problems were about the noise around (downside of being in an open area) and our lack of detached keyboards (which could have jumped from hand to hand more easily). We learned (the hard way) that changing a pair in the middle of a big refactoring is really hard. It is very difficult to explain what is happening to the newcomer when the code is not working.

People also liked trying Ruby and Haskell but mostly the experience of pair programming with different people from different backgrounds. There was a small issue regarding the stress situation that the format puts participants on. 7 minutes is a short time and having the pressure to explain the code to the newcomer and adding your own contribution in that time (not being able to fail on any or else the whole code might get lost) is not an easy and comfortable situation. From this view point, the format breaks the safety aspect so important in a Coding Dojo. On the other hand it also leads to a more exciting experience and gets you to practice a different set of skills.

On the overall it was an amazing experience and I would like to thank everyone for joining us. After so much fun, we obviously went out for some dinner at an amazing burger place in Chicago.


You can checkout the generated code of the three solutions at Coding Dojo São Paulo's github account. There are also more pictures from Danilo at his Flickr account and some more from Pedro at his Picasa account.

Coding Rumors++ or UberDojo

Hello,
I previously described the Coding Rumor game and later on presented the results we had at PyCon Brasil 2008 doing it. During the Encontro Agil, we tried having a session of what rbp (or R) called UberDojo to follow the UltraDojo idea (the name he prefered for Coding Rumor).
Just to remind you, UltraDojo (or Coding Rumor) is a Coding Dojo session where you don't need a projector. The code is written in one laptop and the pair switches with rounds just like the regular one. Everyone works on the same problem but you only get to see the code for 2 rounds (14 minutes) in which you are the co-pilot and then the pilot. If you are not on any of those roles, you can chill and chat with other people. The advantage of this is that it requires less time focusing on the problem which makes it a good practice for conferences.
The UberDojo version is just the UltraDojo game with several laptops. You should plan to have at least three people for each laptop but you can have more if you want. In this case, when the pilot leaves, he goes to the "audience" and will choose another laptop to go to on the next round.

Last Monday's session happened at Thiago's house. We were 14 people (Danilo Sato, George Malamidis, Rodrigo Bernardo Pimentel, Thiago Colucci, Fabricio Sousa Nascimento, Jacqueline Marchetti, Renato Willi, Bruno Pedroso, João Pedro Kerr Catunda - a.k.a Yoshi, Mariana Bravo, Breno Flesch, Rafael Schouery, Adolfo Rodrigues and myself). We had four laptops splitted in two round tables. Each table defined a language (Haskell and Ruby) and each side of the table defined a problem (Bank OCR and Minesweeper).
We followed 7 minutes rounds and tried to keep Haskell and Ruby "experts" available to help out people programming. At the end of each round, the co-pilots would become pilot, pilots would go away and part of the audience would join as a co-pilot on each table. We tried to keep it as random as we could in order to never repeat pairs. We had over 1 hour coding that way. It was very intense and fun. Obvisouly, we never got to finish any problem although we walked pretty well with the Haskell OCR system.

All the produced source code is available at Github on the dojo project at UberDojo-02. In retrospective people reported that is was very exciting and that it was actually a good teaching system but that they should police themselves to actually explain quickly the code to the newcomer before starting to code and be even more radical with the baby steps approach. I think this might be a very good exercise for experienced TDDers and agile teams. I believe if a team manages to actually code something slightly more complicated than Roman to Numerals, it is actually showing a lot of code cleaness. We acknowledge, however, that this sort of exercise is not especially welcoming to new people and requires quite a few experience with TDD. We agreed to have a UberDojo once a month in our meetings and keep the rest as regular dojo sessions. If you try it, please let me know what went right or wrong and your impressions.

Thanks and bye bye.