Pair Pro­gram­ming: The pros and cons

De­vel­op­ing new software is a complex un­der­tak­ing. Depending on the scope of the software, pro­gram­mers have to consider many different even­tu­al­it­ies, functions and problem areas. Even ex­per­i­enced software de­velopers can sometimes lose their bearings. In recent years, new meth­od­o­lo­gies have been developed to make pro­gram­ming as efficient as possible while ensuring bug-free code. Practices such as scrum and kanban are designed to improve an entire system.

Pair pro­gram­ming is smaller in scale. In this technique, de­velopers always work on code in pairs. How does is it work and what are the ad­vant­ages of the method?

The pair pro­gram­ming method is mainly used in agile software de­vel­op­ment and is spe­cific­ally required for extreme pro­gram­ming (XP). In pair pro­gram­ming, two people always work on the code at the same time. Ideally, they sit right next to each other. One writes the code, the other checks it in real time. They con­tinu­ously interact, dis­cuss­ing problems, finding solutions, and de­vel­op­ing creative ideas.

Normally the two co-workers have two different roles: The pro­gram­mer in the driver role writes the code. The navigator checks it. The rules of pair pro­gram­ming require that the two pro­gram­mers con­tinu­ously switch roles at short intervals. This elim­in­ates towers of knowledge. Both pro­gram­mers are equal and can easily slip into each others’ roles.

Ideally, the workplace too should be adapted to the re­quire­ments of pair pro­gram­ming. Both de­velopers have their own mouse, keyboard and monitor, but their screens display the same in­form­a­tion.

Remote pair pro­gram­ming is somewhat less common. In this technique, the pro­gram­ming partners work from com­pletely different locations instead of sitting together at the same work­sta­tion. Special technical solutions are required for this to work. The pro­gram­mers must be able to com­mu­nic­ate directly with each other, access the code and see changes in real time despite the distance between them.

In practice, two de­velopers with different ex­per­i­ence levels are often paired up. This way, a highly ex­per­i­enced pro­gram­mer can share expertise with a younger co-worker directly on the job. At the same time, the novice pro­gram­mer can con­trib­ute fresh ideas to the project.

Pairing two col­leagues from different areas can also be pro­duct­ive. When a tra­di­tion­al pro­gram­mer teams up with a designer, they can support each other with their different areas of expertise.

Pair pro­gram­ming is es­pe­cially useful for larger projects. The principle that two heads are better than one is es­pe­cially effective when you have huge amounts of code that’s being changed on a regular basis. You can be sure that the best possible version of a section is always used in the source code. Fewer cor­rec­tions are necessary and errors are reduced. Reviewing lengthy source code is time consuming and tedious, which is why it’s better to write code without any errors right from the start.

In­cid­ent­ally, you don’t always have to pair up the same two coders, even on one project. It’s actually be­ne­fi­cial to reshuffle pro­gram­mer couples on a regular basis. That way, each team member will have a good overview of the entire source code. Plus, the success of the project won’t depend so much on in­di­vidu­al team members. If one person drops out, the entire project isn’t jeop­ard­ised because everyone else can pick up their slack.

Col­lab­or­at­ing on a project in pairs has many ad­vant­ages, whether pro­gram­ming a project or any other un­der­tak­ing. Two sets of eyes usually see more than one: Pair pro­gram­ming minimises the risk of errors. While one pro­gram­mer writes the code, the other examines it and focuses all their attention on finding errors. It’s often difficult to spot your own mistakes. A co-worker can often find dis­crep­an­cies much faster.

Another big advantage is that com­mu­nic­a­tion fosters cre­ativ­ity: By con­stantly in­ter­act­ing, the pro­gram­ming duo comes up with ideas that might not have occurred to one person alone. When the two partners share ideas, they come up with better solutions to problems in less time. One coder working alone might be satisfied with the first solution that comes along, but in pair pro­gram­ming, co-workers always have to justify their decisions to the other pro­gram­mer. The other person might have a different view of the problem and might not be satisfied with the proposed solution. The resulting dis­cus­sion often leads to ideas for much better code.

Ul­ti­mately, good code means lean code: Ex­per­i­ence shows that source code created through pair pro­gram­ming is often shorter and more efficient. This means that fewer resources are required to maintain and modify the code later.

As mentioned, you can also use this technique to enable expert pro­gram­mers to share their knowledge with less ex­per­i­enced team members. That way you can benefit from the main advantage of pair pro­gram­ming – high-quality code – and sim­ul­tan­eously use the method for training teams.

However, pair pro­gram­ming can be time-consuming: Although two pro­gram­mers working together might be much faster than one person working alone, they’re not as fast as two pro­gram­mers working sep­ar­ately. In other words, this method will either slow down projects or require you to hire more staff, which in turn will increase costs. However, advocates of pair pro­gram­ming assume that the initial extra work will pay off in the end. Since the resulting code contains fewer errors and is generally better struc­tured, it requires much less main­ten­ance.

Another possible drawback: Pair pro­gram­ming is good for team building, but only if the two pro­gram­mers can get along. They have to interact so closely that personal problems between them will either slow down the project or result in a major es­cal­a­tion. Pro­gram­mers should never be placed together randomly. Although it’s ideal if every pro­gram­mer has been paired up with every other team member at some point, it won’t work unless the whole team gets along well together.