code-through-glasses
Code seen through a pair of glasses Foto: Kevin Fu © CC0
>

Relay programming -- because pair programming is so 1999

Siv Midtun Hollup 
6. okt. 2017

Introducing a way to handle those high risk one-person projects

For nearly 6 months I shared a project with Ove Gram Nipen by working alternating days. The project was small and only required one full time developer. Rather than having one person work on this full time, we split the project between us. At the end of each day I would commit my code and Ove would take over the relay pin the next day. After his working day he'd commit his changes and I'd pick up where he left off.

Why would we do such a thing? We happened to have a baby together, and one of us was on parental leave while the other one worked. Together with the management team we decided that the best way to keep the project going was to share the project rather than have someone else take over.

To make this work we'd have a short handover either at the end of the day, or at the start of the next day. This usually consisted of a quick overview of what had been done, taking about five minutes. Sometimes we even wrote a failing test and ignored it, so that the relay would be as smooth as possible and you'd have an easy start.

As we committed often and only worked on one feature at a time, we didn't suffer from having to think about too many things at once, and we didn't have to use branching. Our version control history usually looked something like this:

commit-log-no-branches-single-feature
Git commit log for two people working on the same project relay style

While it's more common that people would work on different features in separate branches, we decided against that. We worked on the same feature until it was finished before moving on the next, which in Kanban terms would mean we only had one item in the "on-going" category. 

Working on a project with relay programming had some interesting effects, both on the code base itself and on the organisation. First of all, knowing you'd have to hand over the code at the end of the day meant you did smaller steps. With very few exceptions we always committed at the end of the day. As we didn't always talk too much apart from the handover phase, it was important to have good test coverage (we used TDD). A handful of times we swapped workdays if one of us had started a larger piece of work that couldn't be completed in one day. 

Working as one on the code base, we had to agree on the architecture and direction of the project on all levels. The relay style provoked early discussions about the architecture and code style, and increased the quality of the code base.

Most importantly, with relay programming both of us had an intimate knowledge of the whole project. Even in a small project with only two people covering one full-time position, knowledge transfer in case one of us left would be much easier than if only one of us had worked on the project. This means less risk if one person has to be replaced, as knowledge transfer is covered by the remaining developer. This reduces risk in the project both for the consultancy company and for the client.

Last, but not least, relay programming gives a possibility to make meaningful teams for small projects. Instead of two people in a small team working on separate projects, they could alternate on both projects. This also scales up to a team of four.  You could pair up people on different projects as long as everyone has someone to relay with. Be wary of having more than two people relaying, though, most likely this won't work for three or four in a team as you'd only work on the project one day a week.

In the figure below, O and X are used to denominate alternating days, so that each person (row) should have one of each, and every project (column) should have one of each.

relay-style-person-project-grid
Relay style project group grid

Relay programming won't fit everyone. As a developer you have to be fairly independent. You need to be able to adhere to code style and preferably have the same code style as the other developer. If you hack away without much thought and clean up later on, that won't fit with someone who plans ahead and doesn't write code until the whole piece is thought out. Developers should also be at roughly the same skill level.

Meetings can become a challenge, but if you work in-house you can plan around this. We usually had a breakfast meeting, as that would give a smooth handover and kick start the day. The customer must also be aware that either person could show up at meetings. As both developers knew the whole system, this was never an issue.

As I mentioned above, we sometimes swapped days if one of us was deep into a task that took more than one day to complete. This shouldn't happen too often or go on for too long or you'd be back in the separate features scenario with added risk and more need for knowledge transfer.

To sum up I'd say relay programming could be useful for small projects. These projects are usually high risk and not everyone enjoys working on their own. The quality of the delivery goes up as two heads think better than one. Relay programming let's you form meaningful teams and eases knowledge transfer. As long as your team members are OK with such a tight collaboration, go for it!

Temaer