The Dojo we had last evening was very instructive
We were 11 people from various background sit around a computer and a keyboard with a videoprojector.
The master and the rules
The overall evening was really well mastered by the MC. He told us the rules:
- a recap from last Dojo session
- a brainstorming for the subject
- a vote
- several "randories" of 5 min each
- pair-programming. The co-pilot becomes the programmer when the randori is over and a new person becomes co-pilot
- TDD is mandatory and should be followed by the rule
- watchers are only allowed to participate to ask for explanations or to state that the current development is out-of context
- no more than 2 hours in a row (1 and a half is common)
- the aim is not to be productive but to learn as much as possible
First of all, we had the choice of the language: either Java or Python (my coworker is also proficient in Prolog, but she was the only one). I voted for Python because first I wanted to taste another dynamic language such as Ruby, but also because I feel this kind of language is pretty well adapted to the Katas.
The kata we chose is an idea I proposed from Cédric Beust blog: solve a Suduku grid.
First of all we started from a list of tests that we wanted to pass. And we lowered our ambitions from that point on,... So we started with a kid's suduku of 4x4.
And we had a first objective that was to find the solution when only one square was uncomplete.
All in all, something like 16 unit tests were implemented and everything went with a smooth pace. Until the hard part!
The hard part
When you learn martial arts, there are times when you feel at ease with the movements and there are times when something seems unnatural, uneasy. Then you have to struggle with yourself to feel the right way to do it. Ok, enough for the metaphor.
Everybody in the room stumbled on one algorithm that we could not get straight. Even with such brilliant minds around the table. We wanted to implement a function that would return the uppermost left corner of the ith subgrid of the suduku.
This may sound easy for a 4x4 grid but, I don't know why, we had the madness to try to solve it for the general case:
- a suduku of NxN
- with subgrids of WxH
I was myself pretty much disappointed as I was too tired to get it right and I felt there was a really smart solution to the problem (something like a fractal approach).
So I think this will be the subject of an upcoming kata and I will post the solution if available.
Eating a delicious home-made tiramisu, we exchanged on this experience. I had great pleasure exercising TDD with an integrist as MC (I will certainly blog later about that. For instance, why would you need to execute the tests when you have just written a test with a missing method? You know that it will fail!).
I think this kind of session is the real way of learning the practise to a group of programmers.
We also had a discussion around the Cascade style for development thanks to Laurent Bossavit (the MC) that told us a funny thing:
- the man that drawed the first cascade-style process for development, Winstom Royce, wrote, in the same article (« Managing the Development of Large Software »), that this style was "risky and invites failure".