How I run Legacy Code Retreat

You want to run a Legacy Code Retreat?

Great! We want everyone to run a Legacy Code Retreat. Here's what I do.

So far, I've followed a similar formula to Code Retreat. The basic framework includes this:

• 45-minute programming sessions
• pair programming
• after each iteration, do the Code Retreat shuffle: thank your pair partner, throw away your code, then switch partners
• after each iteration, debrief: ask each pair to share something about what happened, what they thought, what they saw... anything noteworthy
• at the end of the day, do the Code Retreat Closing Circle: gather everyone together in a circle, then go one by one sharing something about the day. I like to ask people for something they learned that they didn't expect to learn as well as what they plan to do differently when they get back to work
• food, but no pizza, and high-quality coffee (I'm a coffee snob, and no Legacy Code Retreat has had good enough coffee yet -- we're working on it)

Code Retreat, with a twist

Now everyone who runs a Code Retreat does things slightly differently, and I have two important suggestions for change that I use in Legacy Code Retreat:

1. When pairs throw away their changes, let them keep their end-to-end characterisation tests (more on that below).
2. For the last two iterations of the day, ask people to switch pairs before the last iteration, but let them keep their changes and continue working from that point.

Where's the code?

I almost forgot! http://www.github.com/jbrains/trivia. Like any good bit of legacy code, you'll find no instructions, and possibly some bugs. Good luck.

More guided practice

I run Legacy Code Retreat with more guidance than a typical Code Retreat. I have so far used these exercises in this sequence:

1. Do anything you like, but try to add tests changing the code as little as you can.
2. Use the Golden Master technique to generate characterisation tests (I make this a 20-minute iteration and explain the exercise below).
3. Practise using the Subclass to Test refactoring.
4. Practise using Subclass to Test, followed immediately by Replace Inheritance with Delegation.
5. Practise extracting Pure Functions, that is, functions with no side effects. (Be careful! You think there's no side effects, but if can't mark the function as abstract/class-level, then there might still be side effects!)

As always, write whatever tests will help you do these things safely and correctly. Whatever you do, do what you don't normally do!

After each iteration, throw away your changes except for the Golden Master exercise. I recommend that people keep their Golden Master to help them with the other exercises.

For the last two iterations of the day, keep the changes after iteration 1, but switch partners.

Golden Master

The Trivia Game has one feature that can help us quickly and easily generate some helpful characterisation tests: it displays running commentary about the game on the console. After the first iteration of get to know the code a little, I invite people to spend 20 minutes generating output for 10,000 different games (use a specific sequence of seeds for the random number generator!) as a Golden Master. They can use these game logs to build some confidence that changes haven't completely screwed up the code base by generating the game logs after a change, then comparing the test run against the Golden Master. I strongly recommend that you try this exercise yourself as a kata before you run your Legacy Code Retreat. You can figure it out! Just remember that the same seeds for random number generators from different languages on different machine architectures will generate different streams of numbers, so you can't just copy the game logs from one computer to another. I tried that.

Questions? Ideas? Concerns?

Add your comments!