Yesterday we held a coding dojo at our office. This time we were supposed to code a sudoku game (without GUI). There were some new things that were tried, like having a product owner, and dividing the coding time to iterations. This time we had a group of 14 or so a good many more than in the previous one I attended where only 6 people were around.
To tell you the truth, this coding dojo session was very much alike the previous one I attended, with the exception that more people was present. Again a lot of time was spent on discussing elementary TDD issues. This is good and bad thing. TDD is such a good programming mindset that it is good to discuss about it in depth. However the Coding Dojo should not be solely about TDD. The Dojo should be about learning, but unfortunately I don't think I picked up too many new things from this session (the retrospective on how to improve the dojo was good though! :) ).
The reason the discussions revolved around the exact same topics was partly due, in my opinion, to the fact that the project was started from scratch and everything had to rediscovered once again (test naming conventions, test granularity). I also think that the simplistic coding challenges we have had encourage the same discussions too.
Don't get me wrong. I think TDD fundamentals are very important and everybody (even the most seasoned TDD practicioners) should take a frequent look at how they implement the fundamentals. However as even for the TDD I would like to have varied discussions on many of the more specific topics we haven't yet touched - mocking, GUI testing, test separation, acceptance tests, data tests etc.
I think it would great if we coded something that could be used in the contexts of the dojo. Creating something useful would probably align the mindset of the attendees a bit and the discussions would be probably a little different. --- Since this time didn't find a timer to keep time for the programming pair, I suggest that we write an eclipse plugin (or ruby app or whatever) to do that. This is not too hard of a programming challenge, and might pose also some more real life problems and techniques for the attendees to talk about.
As Bas Vodde pointed out the code we produced was not really of good quality and almost looked like legacy code (atleasts the tests) already immediately after being written. I think this was partly due that people were not reflecting on what they had written or what the previous pair had done. It takes disclipine to refactor and in a such a short time frame it takes even more. One might want to make progress (and there's even time pressure for it) during one's turn and not just refactor the previous pairs code. It's human, but some more attention might be spent on that. In the retrospective we had we talked about having more time for the pair (like 10 minutes for the pair and then change the pair fully), that would probably be better since the pair would have time to refactor their code.
One more point. For future dojo's I think it would be imporant at the beginning of the dojo (or on the dojo announce page) to set objectives for the session so that everybody would know what's important for the session. All the dojo's I've been in have had implicintly been about TDD, but the dojos could have some other goal/topic too like learning Eclipse RCP, pair programming, refactoring (we could have project we start to refactor) or oo principles (open-closed principle etc).
