Trio programming revisited

Last month I was at the airport browsing random things on my phone and I ran into this text by Jon Evans.
It made me think of how people always try to come up with the perfect set of practices for software development, but there’s always someone reminding them that common sense still prevails over every possible process or practice. But it also reminded me of some thoughts I had many years ago about pair programming, or, actually, trio programming.

I’ve seen many terms for the situation where 3 people are coding together: triple-programming, trio-programming, trairing, etc, choose at will.
The problem I see with these terms is that usually they are used to describe 3 people working on a single feature, and that’s not very effective in my opinion – except on some rare occasions with extremely complex/important features or problems (common sense still prevails).

Going back in time a little, when I was in college I had to work with a group of 3 other guys to write a web application, it was our finals for one of the courses we were taking, and it was a big deal because we had never written something like that with all the integrated bits and layers and shenanigans. One of the guys bailed for some reason I can’t recall – no hard feelings, he had his legitimate reasons – so it fell to the other 2 and I to do the work.
All the 3 of us were raised in Brazil, and as I usually say, every Brazilian is born agile, because we always seem to “do everything at the latest responsible moment”. As expected, 2 days before the deadline to hand in the application we had barely started coding, so we had an overnight development session where we wrote most of the application together.

It worked like this: we were 3 guys, we had 2 machines. There was always one pair and one solo dev, but the pair would rotate constantly. I was pairing with João now, and César was going solo, until he stumbled on an issue/doubt/important-decision-making-point, where he would call for help and either João or I would join him. If João joined him, now I was the one going solo, until one of them joined me again. We had 2 well defined streams of work, but neither of them had a clear driver, because all 3 of us had a medium-to-high level general understanding of what was going on with both.

The most interesting thing is that this process had not been defined previously, in fact we only realized that it had happened once we finished, it was all very natural and organic, and worked very well. We didn’t have any tool to remind us of rotating, in fact, we barely noticed we were rotating. We were just 3 guys working together on a project, all of us helping one another.

Back to the present, whenever I think about that experience, I recall how well it worked, and how interesting it would be to try that again.
I guess I am just trying to put into words a very non-organized way of work, but I think it’s possible.
And here’s why:

A typical pairing session for me usually has 3 clear different actions: the talk, the decision making, the typing. For the typing bits, given both people in the pair are proficient with the technology in hand, usually there’s not much the navigator has to add. Most of the comments around typing are going to be things along the lines of “you forgot a semicolon” or “there’s a typo there”, which are usually things the driver had already noticed and was on his way to fixing, or that he would catch quickly enough anyway. The greatest value of pairing is on the other 2 actions.

(Now, there can be typing involved in the talk and in the decision making, typically when one of the developers in the pair go like “here, what if we did something kinda like this?” and starts to type code away, usually not really code that is going to be used in the final version of the solution but just a means of expressing his/her ideas. So when I say that “typing” is one of the 3 actions in pairing, it does not include these moments where we write code to discuss our solution.)

That’s why I think triple-pairing in 2 work streams works so well: there’s always a pair talking and making decisions, while the typing can be done solo. Hell, if the typing is so important to you, and, let’s say, you don’t want to have to wait for the tests to run to catch a typo, I could even argue that there’s some just-in-time code-reviews happening there as well: whenever the pair enters in typing mode, one of the guys in the pair goes back to the solo guy to check on how he’s doing and can offer advice on the typing bits.

So how can this practice be formalized? Should we try to assign 2 stories to 3 people?
Well, maybe, why not? I still want to try this out and see what happens. If anyone out there has had experiences in these lines, please share!

But I think that there’s more to that than simply having 3 developers for 2 streams. The project I am currently working on has a small team of 5 developers. Which means there’s always one person soloing, but this person is more often than not doing QA work. Anyway, here are 2 situations that I think fit this idea even though they don’t fall into the 3 for 2 category:

– I worked in a story while another dev worked on some other bits of work. We were sitting side by side just as if we were pairing, but our pairing screens were not connected to the same machine. We both knew what each other was doing, and we both talked about both problems constantly and even took each other’s keyboard for a few seconds to type something – but we had clearly one person working on each stream of work;

– 2 pairs working on 2 different stories, but all 4 people involved knew at least some about the 2 stories (they are both stories in the same project after all, so guess what? They are related!). One developer goes to the restroom, his pair has a doubt, one of the developers in the other pair joins them, the refreshed-developer-who’s-just-back-in-the-room hovers a little bit both streams of work and eventually joins one of them. This happened more than once (and not only triggered by restroom visits, otherwise we would be thinking about a general team visit to the nephrologist).

So, here are my conclusions:

– 3 developers for 2 streams of work may be worth trying. I want to try it out again, and will share my experience when I do so. If you have, please share with me.
– When pairing on a story with someone, don’t shut yourselves from the world – I see this happening very often. Go around the team and talk about the problems you’re facing, ask for advice from a third party, go around offering advice. If you’ve done the talk and made a decision with your pair that results in at least a few minutes of pure typing/refactoring/moving stuff around, choose one of you to do the dirty job and get the other to go poke around and check what the others are doing, maybe they could use some talk themselves. Of course, sometimes it may be worth to stay and pair through the typing too, specially if it involves moving a bunch of existing code around or touching the always-present-hairy-parts of the codebase – again, common sense.