I attended the Code Retreat held in Dublin over the weekend. It was a really cool event.
The event was run using a format proposed by Corey Haines and described a bit here. The essence of the format is that all the participants focus on a single problem during the day; there are multiple short iterations (45 mins in our case) and each time the problem is solved with additional constraints/variations. Pair programming is used and there is significant emphasis on Test Driven Development (TDD).
Game of Life was chosen as the problem to work on for the code retreat; it’s very appropriate as it is possible to solve the problem within the 45 minute time window, there are some different solutions and the problem is sufficiently complex that some thought is necessary to devise a good solution.
During the day, we performed 6 iterations, swapping partners each time; the focus of each of the iterations was:
- Develop a solution to the problem with no constraints – the first iteration was an opportunity to start thinking about the best way to solve the problem;
- Develop a solution to the problem with the constraint that no computers are to be used in the first 10 minutes – pen and paper must be used to think through the problem;
- Develop a solution in which no primitives can be used – the solution must be built on classes;
- Develop a solution using the “TDD like you mean it approach” in which code is only introduced to the main codebase once it has undergone test;
- Develop a solution using mocks liberally and no conditionals;
- Develop the solution with no constraints – focus on getting to the finish line.
The purpose of each of the iterations was to focus on different approaches to solve the problem, thus giving all of the participants some feel for alternative approaches to problem solving which they may be able to take away from the event.
My observations/impression of the event:
- Pair programming was a new experience for me – my experiences with it were varied. As there was diversity of experience, abilities and languages during the day, there were many pairs in which the teams were composed of people with quite different skill levels (using a given language/toolset). When there was a big gap in skills, the progress/work of the pair was strongly dominated by one person. When the gap was smaller, however, the benefits of pair programming became much more apparent – bugs were caught earlier and ideas seem to be worked through more quickly. (Pair programming full time would seem to be a very intense activity, however);
- Being forced to think through the problem on paper proved surprisingly productive – I guess I had forgotten how useful/necessary this is and all too often get stuck into coding before thinking through the problem sufficiently;
- For each iteration of the problem, I didn’t really get to spend enough time focusing on the new constraint that was added for a number of reasons;
Overall, I did learn a lot during the day. However, I did think that the format may be more suited to situations in which the makeup of each of the teams is more homogeneous. When there was disparity between the teams, one member was learning off the other, but the other was typically trying to push forward to achieve some of the tasks; this meant that the team was not focused on learning via knowledge transfer or pooling efforts to make as much progress as possible.
I’ll probably attend one of these events again as there were good folks there and I did learn lots. However, I don’t think I’ll bother working on a team using a language that I know little about.
Thanks to the organizers, José, Kevin, Andrea, Viktor, Declan, Vicky for a great day.