I "invented" this game yesterday before Sao Paulo's Coding Dojo meeting started. We were going to celebrate one of the attendee's birthday after the meeting and I started this idea being a joke. I suggested we could go have the Dojo at the restaurant.
Someone pointed out that we could not because there would be no way everyone could see what was going on. It then stroke me that this was a full exercise itself.
The idea is to gather at least 8 people around a table (a round one preferably) with one laptop (the token). To start the game, the group must choose a language and environment they are all familiar with (this is very hard, might only work with certain groups of people). After that they have to choose a problem. Make it a very simple problem to start with. Something such as Roman to Numerals or The Block's Problem or any other that everyone in the can quickly see a solution. Once everyone understood the problem, the game starts.
Get a chronometer to define a round time (I suggest 5-7 minutes as we do at the Coding Dojo) and give the laptop to someone. At max 3 people will be able to look at the laptop's screen at the same time: the one coding (the pilot), the one that just coded (the retired) and the one that is about to code (the rookie).
During a round, the pilot has to follow the TDD cycle (test, pass, refactor) explaining the rookie what he is trying to reach. He can ask for help from the retired to better understand the existing code but should not let him touch the keyboard. Once the round is over, the pilot hands the laptop to the rookie and becomes the retired. The rookie becomes pilot and the person next to him becomes rookie. The game should go on until the solution is ready or each participant received the token three times or when a pilot is not able to produce any effective change to the code in his round.
I would suggest a local version control repository (git, mercurial or even svn) to be used at each pilot change so that the group can review the code evolution afterwards and evaluate on what were the key moves in the game that made it success or fail.
I suspect it will be VERY hard to reach a solution on this game but I am pretty sure that playing the game can only be an very rich experience. If the group does manage to reach a solution, I would also say the resulting source code will be very simple to understand and tests will define very well how the methods (or functions) should work.
As I said, I will try at PyCon and I will report the results here when I have them. If you try to play the and have suggestions for it, please post a comment. Have fun Telephone Coders :)
Tuesday, September 9, 2008
Subscribe to:
Post Comments (Atom)
Posts
2 comments:
Have you put this game in action?
I believe the round duration should be longer than in Dojo (because people are not seeing the code and the code will be always a surprise) and there should be fewer contributors (because waiting six or seven rounds doing nothing would suck). Besides, it would be easier to understand the changes if there were fewer coders.
But it's just a guess. What do you think?
Hello Heitor,
I have put this game in action about a dozen times now.
The regular 7 minutes round is small but pretty exciting. We never really felt the need to grow it over that.
Regarding the waiting time, this game quickly evolved to a "multi-computer" experience. Where each computer has a problem or language and people cycle between them. I've called it Kake recently but originally described it here: http://codeache.blogspot.com/2008/10/coding-rumors-or-uberdojo.html
This way people only wait for a round and it gives them the oportunity to chat a bit about each solution they've been thru.
A lot of fun but it requires very experienced TDD people and provides an intense experience to all atendees. I've only received very good reviews of this game so far except for the high level requirements.
Post a Comment