Global Day of Code Retreat, Chennai
[Originally posted on my blog.]
I spend the day on Saturday at ThoughtWorks Chennai attending a code retreat. This is the first time I've attended a code retreat and I had a lot of fun at the event. This code retreat was organized in many different cities across the world as part of the Global Day of Code Retreat (Dec 3).
Code retreat is a day long event where you pair with different people for 45-minute sessions, trying to solve a problem (Conway's Game of Life) using object oriented principles and test driven development. At the end of each session you delete the code, and start all over again with a different pair.
Session 1. For the first session, I paired with a Python developer but used Ruby and Rspec. Neither of us had spent much time doing test-first development, so we took some time getting used to writing tests before code. My pair didn't know Ruby, so ping-pong programming didn't work too well, but Ruby and Python are similar enough for us to not waste too much time on syntax.
We did make the mistake of spending too much time discussing the design in advance; we didn't write the first few lines of code till almost 10 minutes into the session. At that time, I felt that thinking over the design in detail would help, but I have changed my mind since.
During the discussion after the session, Karthik Sirasanagandla, who was one of the facilitators, pointed out that we were doing TDD all wrong by planning too much in advance. I went through the next couple of sessions slightly skeptical about this idea... Knowing in advance exactly what your class is going to do will only help you write better tests, right?
Session 2. For this session, I paired with a Java developer, and we used Java and JUnit. I have to admit that after using Ruby for a while, statically typed languages seem like a lot less fun and we struggled to get much done.
Session 3. Once again I paired with a Java developer but we used Ruby and Rspec for coding. Rather than me writing all the code we tried another approach to pair programming. I would write some code, and slide the laptop to my pair who would write the next bit of code in Java-ish pseudocode, which I would then rewrite in Ruby, and then explain Ruby syntax. Once again, a lot of time was wasted on discussing syntax rather than on design.
Session 4. After lunch, I paired with another Ruby developer who I knew from the local Ruby user group. Now that language syntax was no longer a distraction, we had a very productive session.
For one, I got rid of the approach I had been using for the first three sessions - using an array of 1's and 0's to store the game state. Instead we started with the proper object oriented approach of using a Cell class to represent the state of each cell on the grid. We also switched to Test::Unit and Shoulda for the tests, rather than Rspec that I'd been using in the morning.
Session 5. Most of us were starting to get tired of the constant deleting of the code, and it wasn't doing morale much good. So instead of having two more 45-minute sessions, we had a single longer session, so that people would have a chance to go further than they had in previous sessions. We also teamed up with our pair from the 4th session. We continued using Ruby but switched to Rspec for testing.
This was the session where I finally started getting the hang of test-first development. Unlike in the previous sessions, this time we strictly followed the principle of having a single failing spec, followed by code to make it pass, and then writing the next spec. We also didn't spend too much time planning what attributes and methods a class would have and instead focused on what was the next method we needed to add to solve the problem.
One thing that surprised me was the number of developers from enterprise-y companies that turned up. (I too fall into that category.) The fact that very few people were Ruby (and Python) developers was quite surprising, seeing that the event was sponsored by ThoughtWorks and C42, which are both well known companies in the Ruby community.
Another surprise was how many of the people expected this to be some sort of a training session. I had expected most people participating in the code retreat to be people familiar with the format.
I can't wait for the next chance to participate in a code retreat. It was a great experience pairing with other developers, but I felt that pairing programmers who code in different languages (and completely unfamiliar with each others' preferred language) leads to time being wasted on understanding the syntax.
If there's a code retreat happening in your city, don't miss it. You'll certainly pick up some fresh ideas about object oriented design.
Did you attend a code retreat in any of the cities on Dec 3? How did you feel about the event?