JournalAug 2014

Pairing: a whole lot more than just better quality code

For a long time, I was intrigued by the possibility of pairing, but didn’t think it could easily be applied within a more design-focused team that works primarily with startups, rather than enterprise clients who are flush with cash.

The appeal of it was in no small part down to larger companies that I’ve followed and respected for a long time, like Pivotal Labs and Novoda, who take a lot of XP principles and apply them to their projects incredibly successfully.

A dashed out paragraph doesn’t really help a newcomer to fully understand what pairing involves, but to simplify it, it’s the process of building software via 2 people, sitting side-by-side, with separate keyboards and mice, but working on the same computer, and with the same content on their displays. It’s 2 people doing the same work at the same time.

I think it’s fair to say that the benefits of pairing are fairy widely accepted. If people criticise it, it’s largely on the grounds of them not feeling those benefits justify the investment. From experience in our own team, I think that’s actually a mistake, and is very short-sighted. Pairing can solve some very significant problems that crop up even on non-code related tasks, and even if you’re not pairing 100% of the time.

So let’s take an example of something that happened on a recent project

Matt had been working quite extensively on content strategy for a few weeks and building up research, initial site outlines and wireframes, and handover documentation. Once he and the client were happy with the results, he lined up a call with Zsolt, who was going to be leading the next stage of the process and focusing on implementing everything Matt had put together.

That handover call went pretty smoothly, and Zsolt was happy with what he had to work with. But as he began to implement things, 2 main issues came up:

  1. While iterating a little on the design, certain things seemed a little awkward to him. With the best of intentions, he made some adjustments to further improve the UX, but it subsequently turned out that there was a fairly complex, but entirely justified, reason why those original design decisions had been made by Matt. In the process of figuring this out, Matt spent quite a bit of time explaining things to Zsolt so he could fully understand the rationale.
  2. We push heavily to avoid waterfall processes in the way we work with clients, but we were getting dangerously close to waterfall here, even if the deliverables weren’t fixed and locked down at the handover point. Subsequently, the second stage of the process here was distinctly unengaging for Zsolt. He wasn’t able to contribute to improving several of the UX issues he saw, and there was a real danger that the implementation would descend into an unfulfilling ‘paint by numbers’ process. Not great for Zsolt’s morale and motivation.

The problems mainly stemed from the fact that there was an identifiable ‘baton change’ point that the project was handed over at. It’s impossible for Matt to be able to transfer every little bit of learning and understanding he’s taken from the project so far, and pass that completely fluidly to Zsolt. Even with the best of intentions, there is always going to be knowledge that gets left behind.

Ultimately, we managed to get through this once the two of them were able to line up a few calls and discuss things in detail. But there’s no doubt that even if we resolved it well, we created needless hassle and stress for ourselves. Surely there’s a better way to do this and cut that out, leading to a more efficient and rewarding process for the team?

So how might we improve this?

This, clearly, is where the pairing comes in. And as we just saw, it’s nothing to do with improving code quality in this situation. Typically you’d have 2 developers pairing, but the interesting thing about the solution we’ve stumbled upon while pairing, is that you can have 2 people with quite distinct skills, who can still pair very productively if we’re smart about the times they do this.

So instead of Matt working on this by himself next time around, we might:

  • Have Matt kick things off with research and planning as usual
  • Have Zsolt jump in and help out with this, on a focused 2 hour pairing session, with Matt doing the ‘driving’
  • Repeat the process again when Matt begins thinking about wireframes, but this time, stretch it out a little longer and spend more time pairing.
  • When the implementation begins, we switch, and Zsolt does the driving this time. Even though Matt isn’t a developer and has less code knowledge, he’s still involved and pairing with Zsolt here.

You get some fantastic benefits from this:

  • The mere process of collaboration helps get better results: 2 people teaming up means 2 heads on the job, and better solutions. Not to mention, working together is fun, and a lot better than being isolated, and having to shoulder all the responsibility for that part of the project on your own.
  • There’s fantastic cross-pollination of ideas, and transfer of skills: Zsolt learns more about the content strategy side of things, and Matt gets a much better understanding of what’s involved in the implementation. This is an incredibly powerful tool for training your team.
  • Better project continuity: previously, Zsolt would have been confused and perhaps frustrated by Matt’s decisions. Now, he’s been a part of that decision-making and fully understands the reasons for and the implications of each decision.
  • Less team politics: since Zsolt is less frustrated on the project, he’s also likely to be less stressed about his relationship with Matt. This can only be a good thing.
  • Better stability: 2 people now understand the project decisions entirely. So if Matt gets ill and needs to take a few days off, that doesn’t mean we have a big issue. Zsolt can pick up from where he left off. This is a far better result for clients, too, since they get much more predictable project progress and less chance of things being derailed.

To be honest, with all of these additional savings, and knowing how much time it would ordinarily take to hand over a project like this, I don’t even think the pairing time investment is any greater than the time it would take to fix the problems that would unavoidably come up with the alternate approach.

That point about building skills is, to me, critical. It’s very hard to put a price on the value of your team growing dramatically and learning a wide range of new skills from each other. This is a fun, efficient, and great real-world way to learn how to use these skills on a project. Not to mention, jumping into a bit of pairing, rather than trying to keep managing a jerky handover process, and the fallout from this, is definitely a whole lot less stressful for all involved.

How tricky was it to implement this?

The biggest barrier I’ve found, has been a hangover from the days we used to obsessively track all time invested in the project and aggressively fight against any non-billable time that was getting invested. It had created an unusual team culture whereby it almost felt wrong to the team to have someone else help on a task where technically, they could complete it themselves.

Again, we keep coming back to quality. The important thing to communicate to the team to help them see the benefits is that it’s not dead time, even if it’s costing you money in order to do this pairing, that might not be time you’re going to bill on a project. It’s not about the extra time being put in–it’s about the benefit that this time investment delivers.

The net effect is that it builds far stronger teams and shared understanding, which benefits not just the current project, but also future projects. It’s hard to put a price on how valuable that can be.

Posted by
Jon Lay

Jon is a Partner at Hanno. He wears many hats, but his primary focus is on leading our engineering and technical operations.