Pair Programming: The pros and cons

Developing new software is a complex undertaking. Depending on the scope of the software, programmers have to consider many different eventualities, functions and problem areas. Even experienced software developers can sometimes lose their bearings. In recent years, new methodologies have been developed to make programming as efficient as possible while ensuring bug-free code. Practices such as scrum and kanban are designed to improve an entire system.

Pair programming is smaller in scale. In this technique, developers always work on code in pairs. How does is it work and what are the advantages of the method?

What is pair programming?

The pair programming method is mainly used in agile software development and is specifically required for extreme programming (XP). In pair programming, 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 continuously interact, discussing problems, finding solutions, and developing creative ideas.

Normally the two co-workers have two different roles: The programmer in the driver role writes the code. The navigator checks it. The rules of pair programming require that the two programmers continuously switch roles at short intervals. This eliminates towers of knowledge. Both programmers are equal and can easily slip into each others’ roles.

Ideally, the workplace too should be adapted to the requirements of pair programming. Both developers have their own mouse, keyboard and monitor, but their screens display the same information.

Remote pair programming is somewhat less common. In this technique, the programming partners work from completely different locations instead of sitting together at the same workstation. Special technical solutions are required for this to work. The programmers must be able to communicate directly with each other, access the code and see changes in real time despite the distance between them.

Best practices in pair programming

In practice, two developers with different experience levels are often paired up. This way, a highly experienced programmer can share expertise with a younger co-worker directly on the job. At the same time, the novice programmer can contribute fresh ideas to the project.

Pairing two colleagues from different areas can also be productive. When a traditional programmer teams up with a designer, they can support each other with their different areas of expertise.

Pair programming is especially useful for larger projects. The principle that two heads are better than one is especially 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 corrections 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.

Incidentally, you don’t always have to pair up the same two coders, even on one project. It’s actually beneficial to reshuffle programmer 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 individual team members. If one person drops out, the entire project isn’t jeopardized because everyone else can pick up their slack.

Pros and cons of pair programming

Collaborating on a project in pairs has many advantages, whether programming a project or any other undertaking. Two sets of eyes usually see more than one: Pair programming minimizes the risk of errors. While one programmer 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 discrepancies much faster.

Another big advantage is that communication fosters creativity: By constantly interacting, the programming 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 programming, co-workers always have to justify their decisions to the other programmer. The other person might have a different view of the problem and might not be satisfied with the proposed solution. The resulting discussion often leads to ideas for much better code.

Ultimately, good code means lean code: Experience shows that source code created through pair programming 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 programmers to share their knowledge with less experienced team members. That way you can benefit from the main advantage of pair programming – high-quality code – and simultaneously use the method for training teams.

However, pair programming can be time-consuming: Although two programmers working together might be much faster than one person working alone, they’re not as fast as two programmers working separately. 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 programming assume that the initial extra work will pay off in the end. Since the resulting code contains fewer errors and is generally better structured, it requires much less maintenance.

Another possible drawback: Pair programming is good for team building, but only if the two programmers 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 escalation. Programmers should never be placed together randomly. Although it’s ideal if every programmer has been paired up with every other team member at some point, it won’t work unless the whole team gets along well together.

Summary

Pair programming can make software development easier. But to be truly effective, this method requires resources and the willingness to work together constructively.

Was this article helpful?
We use cookies on our website to provide you with the best possible user experience. By continuing to use our website or services, you agree to their use. More Information.
Page top