The Ergonomics of Pair Programming

Of all the practices of eXtreme Programming, pair programming was possibly the most controversial of all, maybe even more so than test-driven development. But just as TDD has gained traction in the industry, albeit hardly taken up universally, pair programming too has adopted in many organisations that are following some form of Agile software development. My purpose here is not to reiterate the arguments for why you should or should not practice pair programming. Rather, this article is for people and organisations that are already doing so or want to start. Deciding to do it is one thing, but it is well worth giving some consideration to the practicalities of how it should be done. I have worked in a few organisations where pair programming has been practiced, I have seen a variety of approaches, and I wanted to share some of my thoughts on the matter.

Space

First of all, the obvious stuff. To program with a pair you want room for both people to sit in comfort. That means you need desks wide enough for both people to get their chairs fully underneath without being blocked by the desk legs. This is mainly a consideration for the organisation, who will be responsible for choosing the furniture, and partly a consideration for the developers when it comes to placing their equipment. If you put your computer box under the desk, it needs to be not in the way of someone's legs when two people are sitting there.

There also needs to be enough space on top of the desk for two people to work there: both people need to be able to put their phones and stuff on the desk, and some people like to have a pad of paper and pen handy. The desk needs to be sufficiently free of clutter so that neither pair is hampered. Some people make themselves very at home in their work space, filling it with lots of personal possessions such as photos of their family, etc. If you have your own desks at work, and you want to practice pair programming, the needs of your pair must be balanced with your desire to personalise your space.

Computers

We love our laptops, if we have them, and people especially like MacBooks. I am no exception. They make us mobile, we can easily work from home, and that is a Good Thing which I do not think you should give up if you're lucky enough to have it. Still, laptops are the worst computers in my opinion for pair programming on. To use a laptop comfortably you must have it right in front of you, and that makes it most incommodious for your pair to see the screen and play a full part in the work. They will have to lean over all the time. If your laptop screen has a poor viewing angle that will make things considerably worse. It's also a slight hassle to move the laptop over when your pair wants to drive, which may seem a very minor problem, but when it comes to ergonomics even small inconveniences matter a great deal.

A desktop computer is far better for pair programming on. You can have a much larger screen than a laptop does, and push the screen to the back of the desk so that both programmers can easily see it without having to lean over or crane their neck. Even better, have two screens, as is increasingly common these days, which you can either set up as an expanded workspace or you can choose to mirror the displays so that both person has a screen straight in front of them. But as I mentioned before, take care where you place the base unit so that it does not get in the way of anybody's legs or feet. Modern computers are small enough that you can probably put the base unit on the desk.

Peripherals

You may or may not be old enough to remember back in 1999, when eXtreme Programming Explained came out, keyboards and mice were connected to computers via the PS/2 port. This had one minor advantage and two major disadvantages over modern USB devices. The advantage, which only really applies to pointing devices, was the responsiveness: no USB mouse works quite as nicely as PS/2 mice did, in my opinion. But there were two big downsides: you could only connect one keyboard and one mouse to a computer. What's more, if you connected either of them while the computer was running then you had to reboot it before the device would work. USB human input devices have neither of these drawbacks. You can hot plug them in and out to your heart's content, and you can connect as many of them simultaneously as you have USB ports. We should avail ourselves of this advantage. Two programmers working at the same computer should have a keyboard and a mouse each. In my mind it makes no sense not to. I have worked at a company who set up their workstations this way and I can attest: it works very well.

Environments

You may have objected to my assertion that desktops are superior to laptops as pairing workstations, on the very reasonable grounds that you can just as easily plug external keyboards, mice and monitors into a laptop. Perfectly true, although modern laptops sadly have very few ports so you might need an adapter. I have an additional reason for believing that stationary desktop computers are better suited to this task, and here we come to the really challenging one for us programmers.

One characteristic shared by all the software craftspeople at Codurance is our individuality. Many of us have a fetish for mechanical keyboards: all of them different, of course. We each have our favourite computers, operating systems, and editors, and fiercely defend our opinions on all of the above. I get it, and I don't profess to be above all of this myself. But too much individuality is bad for teamwork.

If the organisation has provided the programmers with a laptop each, then these can be used for their personal stuff (Slack, emails, documents, etc) and that frees up the pairing workstations to be standardised. Now, I'm not saying that the organisation should dictate the operating system environment (though many do) but I am saying that I think it is a good idea for the team to standardise on a particular environment for all their pairing workstations. It is an even better idea to set all the workstations up automatically using something like Chef or Ansible. If the team can control the automation themselves, and update the workstations at will, then they will not need to know the admin passwords, which will prevent tampering with individual stations.

All of the tooling should also be the same, e.g. IDEs, with the same plugins installed and the same keyboard shortcuts. The purpose behind all of this is to create a standard environment that all the team members can become proficient on, and then any two of them can pair at any of the workstations. When everybody has their own individually customised working environment, it creates friction when pair programming.

Pair Programming Like You Mean It

Above all, what I'm suggesting here is that, if you're convinced of the efficacy of pair programming then why not take it really seriously and arrange the work environment around it? In my mind, this is part of a wider image I have of the ideal space for an XP team, which would include the pairing stations plus an area adjacent with a projector and comfy seats, for the sole use of the team, around which they can gather for mob programming sessions, group code reviews and the like. They would also have their own meeting room, copious white board space, and the team's area as a whole would be isolated enough from other areas that noise from outside is kept reasonably low and no-one needs to walk through the team area in transit to somewhere else.

Perhaps this seems excessive and maybe I'm being unrealistic there. A chap can dream. I do think the team would probably prefer this to the kind of stuff that companies usually provide in order to make themselves attractive, like posh kitchen areas, video game consoles, foosball tables or ping pong. But that's by the by. Companies that want to encourage pair programming can certainly aid the process a great deal without serious outlay: in many cases one additional keyboard and mouse per programmer, plus a bit of thoughtfulness about how the desk contents are arranged, will be all that is needed.