How we use pair programming to develop high quality software

Most people picture software developers hunched over a keyboard, clicking away in silence, alone. A problem with that scenario is that one person is intimately familiar with the code and no one else knows what that person did without ongoing knowledge transfer.

If you visited our offices, you would see a different setup because we program in pairs, with a team of two at a workstation. The pair share the controls like a pilot and co-pilot. Of course, only one can drive at a time, but the 2nd person is an invaluable part of the team.

Pair programming improves decision-making

One of the benefits of pair programming is that for complex code requiring many decisions, those decisions can be tested along the way. If one person were programming alone and had a question, they may try to answer it themselves and possibly not find the best answer or go ask a co-worker which requires bringing that co-worker up to speed and interrupting the other work the co-worker was doing.

By building code together, the best way to design code is discussed and validated as its written. The pair takes turns being the pilot or driver and co-pilot or navigator. The navigator is also writing test cases and tracking any other ideas that come up or issues that will need to be addressed. The driver focuses on writing clean code.

Pair programming forces discipline and boosts creativity

Working in pairs imposes more discipline than working alone. Proper procedure and best practices must be adhered to or both people can’t follow what’s happening.

However, even though it’s disciplined, pair programming isn’t rigid; in fact, it encourages brainstorming. The pair approach works particularly well for parts of the development process that allow some creative license and must be clear to many people such as defining names and concepts.

Pair programming continuously transfers knowledge

Another benefit is that pair programming ensures instantaneous knowledge transfer so that more than one person is extremely familiar with the code. If one person is on vacation or out sick, progress can continue with the other person in the pair. The same is true for any fixes or maintenance later. Availability to work on that project isn’t restricted to one person who knows the code or dependent on knowledge transfer. We double our resources with built-in knowledge sharing. By developing together like a pilot and co-pilot, both developers keep the code on course and either one can take over in case of emergency.

Pair programming creates validated code with fewer defects

Not surprisingly, code written in pairs results in fewer defects and many issues being ironed out right away. Having a second pair of eyes instantly screening every line means that the code has already undergone a thorough quality check before it’s even tested. Minimizing rework and bug fixes later in the process is a huge time savings.

Pair programming requires the right team members

Pair programming does not work well in all environments. In places that rely on a few superstar geniuses to do all the heavy lifting, pairing them with junior programmers wouldn’t work well. Certain personality types do not function well working in pairs.

However, with the high experience and expertise level of the people on our team, our culture, and the process we use, we have found that pair programming works exceptionally well to allow us to deliver quality code quickly and efficiently.