How to Run a CodeRetreat

[Patrick Wilson-Welsh]

 This recipe may evolve, but our collective desire is that if you diverge very much from this recipe, however useful that divergence may be, you do not call your divergent thread a CodeRetreat. The current recipe is working pretty well, and we want to learn as much as we can from this recipe before trying others.

Premises

At CodeRetreat, we retreat from the world to advance in our craft. We sharpen our saws, together. We retreat from production and business value to increase our production capacity, our quality, our velocity, our ability to produce business value. We retreat from immersion in deep technology weeds (Oh no! The JBoss ClassLoader is giving me CCE's!) to advance in our ability to learn and adopt to any technology well. We retreat from our fears, and embrace new practices, patterns, languages.

We retreat from our local ponds and swim in a larger pool. We connect with other passionate coders who we seldom get to code with. We make new connections and learn new lessons.

More Guidelines Than Rules

The unwritten Rule Zero, now actually written I suppose, is Have Fun While you Learn. All of this recipe tries to serve that goal.

First: Choose a Place/Sponsors, and a Programming Language, and Provide Food

CodeRetreats work best if everyone is working in the same language. CodeRetreats have been done in Java and Ruby so far, but feel free to try any language. Just please have everyone in the room use that same language, and publish that language choice early on, so that attendees can bring a good-enough level of expertise that the day is not spent by people teaching each other language fundamentals.

Get sponsors to provide breakfast and lunch, at least, that just show up on time for enough people. Otherwise your flow and focus will suffer terribly.

Second: CodeRetreat is One Entire Weekend Day

Most CodeRetreats have been on Saturdays; Sundays work fine too. More people in your area likely have more free time on weekend days than during the week. This makes it much easier for more people to attend. We typically serve continental breakfast around 8:30, serve lunch around 12:30, and end around 5. Sometimes a sponsor or host provides dinner; sometimes not. Often we all go out afterward for beers, sponsored or not. You choose.

Third: Use Conway's Game of Life as your Problem Domain

The kata most CodeRetreats have used is "test-driving the four rules of Conway's Game of Life," and related Game of Life work. J.B. has created a template Eclipse project on github that will get you up to speed faster (also read J.B.'s comment below about using git, and about a commit-per-passing-test iteration experiment). This is a small enough problem space that repeatable kata are easily discovered. It is also a large enough problem space that very few pairs can finish it in 40 or so minutes. This tends to focus pairs on the test-driving, the design, the refactoring, and the craft generally, as opposed to "hurrying to get this thing done."

Fourth: Work in Pairs, Triples, Quads, Teams

No-one at a CodeRetreat should be programming solo. Ask people to organize into pairs or triples, ideally. Sometimes you may need quads. But five or more programming together is usually not a good idea.

Fifth: Work in 40-Minute Iterations

Iterations last 40 minutes (or so; feel free to experiment with 45 or 50 minutes; an hour seems too long, while 30 minutes is certainly too short). At the end of the 40 minutes, ask each pair/triple/team to stand up, do some stretches, then have them swap a pair partner with another pair/triple. To begin the next iteration, the pair/triple can go over the previous iteration's code (or not).

But, critically, the pair/triple must delete the previous iteration's code before starting over.

Deleting code and starting over each iteration is at the crux of the learning mechanism of CodeRetreat.

Sixth: Distribute Expertise Around the Room

Try to prevent situations where two people are pairing and they have never test-driven before, never refactored before, never worked in the chosen language before, never seen Conway's Game of Life before, etc. As best you can, try to ensure that as you swap pairs, you distribute all kinds of expertise around the room evenly. This is not always possible, but always preferable.

Seventh: Let Pairs Innovate

There are many ways to test-drive Game of Life, many ways to evolve the design. Let pairs try new things for an iteration. Though we prefer to test-drive, should we insist that every pair do it every iteration? Well, I would prefer that TDD-novices always do, but sometimes TDD experts will publicly state their intention to not test-drive for an entire 40 minute iteration, and that's great, if they and we can all learn something from it,

Eighth: Toward Day's End, Try Something Completely Different

Around 4PM, it can be great to try an entirely new experiment for the whole room. We have had publicly-performed kata by very experienced programmers. We have had a great whack of Java Game of Life code ported to Groovy. We have had mob programming. We have tried (in vain) to run a brief project to deliver an entire, working Game of Life application. There are many other interesting things to try, toward the end of the day, once people are pretty sick to death of 40-minute iterations, and deleting code.

Ninth: At Lunchtime and Day's End, Retrospect and Adapt

Things go wrong or weird, for all manner of reasons. While people are eating or winding down, ask the crowd what is working, what is not, and what they might want to change. Harvest the wisdom of the local crowd to tweak the recipe, determine how to mix things up and otherwise adapt.

-------

I'll have more to share on CodeRetreat HowTo later, but this is enough to get anyone started. :)

[Gerald Van Baren]

@Corey - I participated in the CodeRetreat hosted by Atomic Object. I did snapshot a couple of our sessions, but it was a distraction and I did not revisit the branches. Besides that, since the CodeRetreat is pair programming, there is no telling which user's computer is being used and thus I did not even capture all of the runs.

As a result of my practical experience, I concur WRT saving code - likely not useful and not worth the distraction. The difference is the theoretical (save code) vs. the practical (the learning, not the code, is what is useful).

[Corey Haines]

Regarding saving the code, my response is a resounding 'No.' The practices done at coderetreat should be like scales: once you do it, it is gone. You should practice repeating it, but each time should be different and better.

[Corey Haines]

I wrote a description of how I currently run coderetreats. It has evolved a bit over time, especially over the past year that I've been doing these regularly.
http://coderetreat.com/how-it-works.html

[Patrick Wilson-Welsh]

Hi Guys:

I'm OK with code being committed before being locally deleted. But I really want the last iteration's code to be invisible to the new pair / new iteration.

I'm still not OK with CodeRetreats focusing more on things like new language skills more than they do on language-orthogonal aspects of craft. Again, I want it to be possible for folks to get together and learn new languages. I would just ask that you invent something else for that learning meme/venue, and that you try to keep CodeRetreat focused on learning craft in a language you already know.

--Patrick

[Gerald Van Baren]

I understand why you want to throw the code away after each exercise, but that eliminates the opportunity for postmortem learning after the event. A better way is to *virtually* discard the code after each exercise by using git branches.

At the start of each exercise, create a new git branch:
git checkout -b exercise1

[code][commit][code][commit][BING we're out of time][commit]

git checkout master # back to a clean slate

git checkout -b exercise2
[code][commit][code][commit][BING we're out of time][commit]

Rinse and repeat. Now you can look at the more interesting of the exercises later.

Just to be explicit, the commit step is
git add [new files] # if new files were created
git commit -a -m "comment"

[Guðlaugur Egilsson]

Patrick, you say that ".. our "learning" signal to noise ratio got worse...". Certainly, there will be less time to learn TDD and design, but the learning would be more on the language level, but that is also learning. Is that a bad thing for code retreats, i.e. to widen the horizon of programmers language wise ?

[Arlo Belshee]

I probably have enough people for single-language sessions. But I'd like to get people in these different communities to meet each other.

Perhaps I'll hold 2 code retreats at the same time and in the same large room. People can chat with each other and observe each others' cool implementations / crazy ideas, but stay in the retreat for which they know the language.

When I held a code sprint in Portland (3-4 years ago), we got 50 people, so we've certainly got the numbers for a code retreat or two!

[Patrick Wilson-Welsh]

Adrian:

One more point: have pairs focus, for several iterations, on the four rules of Conway's Game of Life that determine whether any given live or dead cell lives or dies between generations. That starting point has neary always worked well for us. :)

--Patrick

[Patrick Wilson-Welsh]

You can't do a full implementation in 40 minutes. That is exactly the point. The point is to Abandon All Hope of Completing the Requirements, and instead receive these constant, jolting reminders to focus on your level of craft, the quality of your design, then quality of your interractions. It is an anti-project. It's just a domain to work in. :)

We have so far NEVER found that anyone can code an entire Life app in 40 minutes by the end of the day. If we had, we would have a looked for a larger problem domain

The idea is NOT to complete it, in order to refocus our natural instincts away from "getting the thing done" to "doing a bit of work really, really well."

Does that make sense?

--Patrick

[Adrian Mowat]

Hi Patrick,

Thanks for the post. This is really helpful.

We are wondering, though, how you can do a full implementation of Conway's game of life in 40 minutes. Do you find that, by the end of the day, the pairs have enough experience to code the whole solution in 40 minutes from scratch - or have my friends and I misunderstood? In particular, we wondered how much of a GUI is needed and if you supplied a simple GUI as a starter - after all, you could easily spend 40 minutes just creating a GUI.

Many Thanks

Adrian