Legacy Code Retreat

Having been home now for 3+ years, away from an urban center, I've been considering a post on what I've learned (good and bad) over that time, as it pertains to crafting software.

This is not that post. However, the following event certainly falls in the good column.

Summerside, Prince Edward Island, punches well above its weight-class when it comes to software. Both Steven R. Baker and J.B. (Joe) Rainsberger hang their hats there, and along with the PEI Developers group, are transforming the tech vibe here on the Island.

As one example, Joe recently facilitated a Legacy Code Retreat (LCR) at the spiffy Holman Centre (no doubt arranged via srbaker). Opportunities like this don't happen often on PEI (though, actually, they are becoming more frequent).

In brief, we paired in five 45-minute sessions with a code base that is brilliantly, wonderfully awful. We practiced specific "rescue and improvement" techniques in a variety of languages.

Here are some quick thoughts on my experience.

What is Legacy Code?

We didn't spend a lot of time on this, but my favourite definition is attributed to Michael Feathers: legacy code is code without tests. I love it.

If you're in a gig that doesn't embrace testing (and with slack-jawed amazement, I've discovered how prevalent that is), adopt this definition. If it doesn't have tests, start referring to the code you wrote yesterday as legacy. It will get attention.

Art imitates Production

The LCR code base appears to be a turn-based trivia game. However, it is replete with dice-rolls, a penalty box, and a board that may or may not be in a Euclidean geometry.

It's a parody, and it's both funny and horrifying. Scary, because it feels so familiar to ghastly production code. That is, code maintained over time by many people, each of them blind and touching an elephant.

Even better, there are bugs! Just when you think you understand the rules of the game, you realize that it is impossible to distinguish between a quirky rule and an outright bug. The code really is magnificently bad, as though crafted by Kafka. (Ed's note: in fact, it was written by Chet Hendrickson).

Pairing

I paired with several people and learned from them all. We might pair at our day gigs, but the variety is fixed in that setting, and ultimately predictable; at an event like this, the environments are truly diverse and fresh.

For junior and intermediate developers, I can't stress this enough. At a retreat, you'll see new languages, editors, virtual machines, techniques, but most importantly, workflow. I paired with jbrains for a session. It was rewarding... and humbling. I thought I was fast but I've rarely seen such speed: mouseless navigation through several tools, all at the speed of thought.

Pairing can be intimidating. That's normal. We often hear empty phrases such as "get out of your comfort zone", but this is precisely that case. It's a fabulous way to learn and grow as a developer.

Tests

A predominant theme for each session was the importance of setting up some kind of test harness before making changes to the code. The harness is almost like a critical utility, such as getting electricity to a disaster site.

No surprise, but this transcended all language implementations, and manifested itself in many ways. For example, one C++ team simply set a fixed seed on a random-number generator and used the Golden Master technique on an output log.

Upshot

True, I haven't written much about specific techniques here. (To find out more, attend a Legacy Code Retreat! Or start with this site or the Feathers book.) But they are useful and interesting, along the themes above. The upshot is: this stuff is important, and fun. It's practice with others who care about the craft. It's hard to imagine a better bang-for-buck for your development as a software practitioner.