Two pair of eyes are always better than one; or so the saying goes. That being said, this post will discuss pair programming, which is still a controversial practice of agile software development. Its controversy lies in the premise that two programmers working on the same code, at the same computer, can’t produce as much code as programmers working individually.

Let’s see how, in an agile environment, as explained in our Rapporto sull'esperienza Agile, pubblicato presso il Sito web dell'Alleanza Agile, pair programming can be quite beneficial.

Many think that if two programmers are working on the same code, on the same computer, with a single keyboard, one must be working and the other just wasting time. After all, they can’t both type at the same time. Nothing could be more wrong. First of all, writing code is not about quantity. It’s about quality. Second, the quantity of code that needs to be written is not as much as some people may expect. Nobody can code real applications like hackers do in blockbuster movies. The act of writing, physically hitting the keys, is the simplest and least demanding part of programming. Knowing what to write is the secret to successful design and architecture. And this is hard; very hard.

“This practice has been nominated several times in the last decades as an improved way of developing software.”
– Alistair A.R. Cockburn – Humans and Technology Technical Report – 2000

Done alone, programming is a very error prone activity. This is one of the reasons we have complex automated testing frameworks and large quality assurance teams. After a lonely programmer writes the code all by himself, an army of testers are required to make sure the code works. There are of course other ways to improve code quality. Ways like code reviews, or restrictive and enforced code standards also work. But none of these implies that a second person’s effort is dedicated to producing the code itself. All other methods imply post factum code checking.

When the code is written by two persons, both of them contribute to its crafting. They combine their mental effort by collaboration, talking, sharing of ideas, and occasionally fighting to demonstrate who knows a better way to solve the problem. All this interaction is essential in producing better code, with less bugs. We, at Syneto practice pair programming most of the time. At some point we even had a rule that no code was allowed to be pushed to the version control system unless written by two people. Pair programming is one of the many small things that led to our Un bug al mese paper.