The Coderetreat

Yesterday, I took part in my first Coderetreat at the /ch/open workshop days in Zürich. I was pretty sceptical about the day to come. The course description didn't mention much about the topics which are to be worked on. But I was also looking forward to work on my social coding skills.

The course process

The main task, we were working on for the whole day was called Conway's Game of Life.

The Game of Life, also known simply as Life, is a cellular automaton devised by the British mathematician John Horton Conway in 1970. The "game" is a zero-player game, meaning that its evolution is determined by its initial state, requiring no further input. One interacts with the Game of Life by creating an initial configuration and observing how it evolves. Wikipedia

Rules

1. Any live cell with fewer than two live neighbours dies, as if caused by under-population.
2. Any live cell with two or three live neighbours lives on to the next generation.
3. Any live cell with more than three live neighbours dies, as if by overcrowding.
4. Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.

The main focus of the Coderetreat day wasn't the taks itself. It was more about the approach with focus on clean, re-usable code and test driven development. The session lasted 45' each, with a 15' review session.

I'll try to summarize shortly the different sessions, what the individual goal was and my lessons learned.

Session #1 - Warm-up

This was mostly a warm-up round. As I was used to TDD already, I could dive into the problem solving immediately as the driver.

• Using a single file for specs and production code turned out to be a good choice for TDD, especially in early phases.
• It's helpful to invest time and effort into your development environment. Being able to run the specs quickly with a keyboard shortcut (I use vim-vroom for that) or automated (e.g. with guard ) helps you to pick up speed, especially when moving between production-and test-code.
• I liked the fact, that we had to delete the code after the session was over.

Session #2 - New constraint: No return values

After changing groups, the coding started again from zero. As an additional constraint for this session, we were not allowed to use return values.

In this session, you could clearly see, how important it is to talk to your coding partner. Some challenges are better approached by thoroughly discuss a possible solution or approach upfront. In my opinion, this is what makes pair programming so valuable.

Session #3 - New constraint: No conditionals

OK, this time no conditionals. Almost all the groups came up with some sort of dictionary decision tree based solution. The proposed Object Oriented approach first seemed as a total overkill (it was some kind of state machine, where a cell could trigger a state change of a counter depending on it's own life state).

Session #4 - New constraint: Time

In my opinion, this was the best session. The 'Write test/implementation' and refactoring cycles were time-boxed to 3'. Later this time was reduced to 2' and even 1'. The implementation and test code that was not yet finished (green) had to be deleted after every cycle.

Also if the code quality was questionable, this was the session were I came closest to a running implementation. It forced to shrink your coding cycles to about one or two lines per production and test code each. This constraint really kept you going the red/green TDD iteration path. And it forces you to be proficient in your development environment.

Session #5 - The Devil is in the details

For the last session, I was working with a ActionScript/PHP developer and we were struggling in finding a suitable environment, that fit for both. It showed pretty quickly, that for a successful pairing session it's essential that both participants are familiar with the environment. As for me, I am using vim together with the Dvorak keyboard layout. You seldom find people who are familiar with this environment (that is also my biggest doubt about using it). But even a slight little change in your work-flow can already slow you down drastically (like the different layouts used in Switzerland like German, Swiss-German, US, ...).

If you are working together with a vim user, these issues can be addressed by using some sort of screen sharing (e.g. tmux). But again, it forces many people to leave their known environment. Perhaps the emerging usage of web IDEs like cloud9can facilitate pair programming.

The follow-ups

As a follow up, I implemented the Game of Life in CoffeeScript. The code is available hereI will write a post about the implementation details.

Summary

All in all it was a great and exciting experience and I highly recommend to anyone to participate in such a Coderetreat day.