Global Day of Code Retreat Recap
December 05, 2011
Over the weekend, I took part in the Indy edition of the Global Day of Code Retreat.
I had never been to a Code Retreat before and didn’t really know what to expect.
The gist of a Code Retreat is to take some time to practice writing code and applying techniques that you aren’t normally able to use in your day job - usually due to schedule or budget pressure. This practice is facilitated by Pair Programming in small sessions. The idea is to work on solving a problem (Conway’s Game of Life) for 45 minutes, then delete your code, rotate pairs, and start again.
Each pairing rotation also has a unique set of constraints that encourages you to think outside the box and explore new ways to solve the same problem.
There is plenty of extra information about Code Retreats available elsewhere, so I thought it might be valuable to recap what I actually did during the pairing sessions.
#Pair One My first pairing of the day was with Jon, who was a self-described “procedural guy”. He worked on writing installers in his day job so he was interested in doing more OOP stuff.
We decided to use Ruby and RSpec for our development environment - mainly because I wanted to try it out and Jon was willing to indulge me.
We spent most of the time getting familiar with the problem domain and applying the Four Rules of the Universe to a Cell class. I introduced Jon to Ping Pong pairing, which was a concept that I was introduced to by an old coworker and we ended up getting all of our tests passing. We were about to move on to start modeling the Board when time was up.
#Pair Two I was able to find someone else that wanted to use Ruby, so I paired with a guy named Shawn next. The challenge for this round was to try to use polymorphism instead of primitive-types (e.g. use an enum of states instead of a boolean flag).
Shawn wanted to explore an idea that would have a Cell generate it’s own neighbors on the Board
when the game first started. We came up with a neat concept for navigating to neighbors using
a Hash with keys like :left, :right, :up, :down - then we could combine two directions
to find a Cells upper-left neighbor for example.
We struggled to find a good way to detect if a given Cell needed to be generated or if it had already been generated by another Cell. We were making some progress, but then time expired.
#Pair Three
After we rotated, I was paired with Daniel, a .NET developer that I knew from Indy ALT.NET. Our
constraint for this round of pairing was to focus on how we would deal with the “infinite-nature”
of the Game of Life. It is rather simple to model the game as an N x N array, but what happens
when N becomes larger than can fit in memory.
Daniel and I spent a bit of time brainstorming an idea based around circular buffers. The idea was to keep only a finite chunk of the universe in memory at a time and partition the rest of the data into ‘stripes’ that could be stored to disk. It was described as a cylinder with other tangent cylinders in 3D space- yeah, sounds pretty weird but made sense at the time…
We used C# this time and when time expired we were in the middle of debugging why the Blinker shape
wasn’t working.
#Pair Four (after lunch break) I stayed in .NET land and paired with Mike, another familiar face from ALT.NET. We had talked about doing an event-driven model over lunch so we decided to try to implement it. The challenge for this iteration was to do Ping Pong pairing - since I had been doing this all along, nothing really changed for me.
The event-driven model was a pretty neat concept. Instead of trying to manage a global Board state, we would use a message bus and cells would subscribe to it. Each cell would filter out messages that weren’t relevant and broadcast messages about itself (“I’m alive”, “I’m dying”, etc).
Using a test-driven approach allowed us to define the public “messaging API” quickly and we were able to spot problems almost immediately. We ran into a few cases of getting stuck on stuff outside the problem domain so we were just getting into the meat of the message bus when time ran out.
#Pair Five Back to RSpec and Ruby as I paired with Vamshi. Vamshi took a different approach that any of my other pair partners. When I immediately went to start writing the first test, he stopped me and we discussed the overall design we wanted for 2-3 minutes.
I think this was helpful because, at this point in the day, I was kind of an auto-pilot for the first 15 minutes of the pairings. First we make the Cell class, then we add the tests for the rules, then we add the Board class with a list of Cells…
By stopping and re-approaching the problem from a different angle, my preconceived ideas were
put aside. In our design, we wouldn’t have an is_alive? boolean because we weren’t going to track
dead cells. Since our constraint for this round was “Tell, Don’t Ask”, our design shifted into
something that resembled the Command pattern.
Vamshi also showed me some neat conventions that he uses for RSpec. I found the pairing to be really beneficial, for me at least, because I was able to learn some practical tricks from my partner that I can immediately apply to my day job.
It was definitely my favorite pair and I was bummed at how fast the 45 minutes went by.
#Pair Six For this pair, we went back to our original partners from the morning session (Jon in my case) and all constraints were removed.
Jon and I were both a little tired of writing the Cell and Board logic, so we decided to explore an area that neither of us had gotten to work on yet - a graphical representation of the board.
We tried out “Ping Pong Pairing with Loopholes” - basically you try to screw over your teammate by making the tests pass, but leaving the code still technically wrong - with the goal being to help you write tests that are more bullet-proof.
#Closing Circle After six rounds of pairing, we regrouped and talked about the day for a bit. After going around the circle, I traded business cards with a few people and headed home after a long (but fun!) day.
A big thanks to Aaron Lerch for facilitating, Interactive Intelligence for hosting the event, and everyone there for making the event a huge success!