Atomic Object will be kicking off the Code Retreat 2010 season by hosting a retreat in Grand Rapids, MI on February 6th at Atomic HQ. “What is a Code Retreat?”, you ask? Code Retreat was dreamed up by Corey Haines, Nayan Harjatwala and Patrick Wilson-Welsh during some spare cycles at the Codemash v.188.8.131.52 conference. They wanted to create an event that would allow software developers to gather and practice their craft away from the pressures of writing production code and delivering business value. It would be a place where developers could come together and improve their ability to write clean and responsible code and ultimately improve their ability to deliver more business value to customers.
It wasn’t long before Corey, Nayan and Patrick’s idea came to fruition; weeks later, the first Code Retreat was held in Ann Arbor, MI. About 30 developers passionate enough about their craft to spend a whole Saturday geeking out with other developers were in attendance, including some well known people in the Agile/XP community such as Ron Jeffries, Chet Hendrickson, J.B. Rainesberger, Bill Wake, and of course, Corey, Nayan and Patrick. Since this first event there have been several more Code Retreats in places like Cleveland, Chicago, Toronto, Philadelphia, and even Scotland.
So by now you might be asking yourself, “What exactly goes on at these Code Retreats?” Code Retreats typically follow some very simple guidelines. The problem domain that has been adopted is Conway’s Game of Life, which has a small enough problem space, allowing developers to not get overwhelmed by complex business rules, yet complex enough that most pairs won’t be able to finish it. We pair program in ~40 minute iterations on the problem domain, and when the iteration is finished we switch up the pairs and throw away the code we just wrote. The reason behind throwing away the code is because the goal is not to write code, rather it is to learn and practice. We hold retrospectives twice throughout the day to get a feel for how things are progressing, once at lunchtime and once more at the day’s end, and make any adaptions to the process as necessary.