Are Two Heads Better Than One? Learning More About Pair Programming

Pair programming is classified among the most disputable agile practices, and, telling the truth, it is not frequently used among the coding community. Why do many programmers have mixed feelings or even are reluctant when it comes to this practice? In fact, it happens not because this is an ineffective approach. Conversely, it can be very beneficial to all the participants of the software development process; however, it has its pronounced peculiarities.

The term “pair programming” describes the process when two programmers are working together on one task, sitting next to each other in front of one computer. One of them is coding while the other one is watching, detecting mistakes, suggesting solutions, working with documentation, and assisting the first programmer in any other way. Once in a while, these two swap places and keep working.

The proverb says, two heads are better than one. Does it work in real-time conditions? Let’s see which advantages and disadvantages of this method may emerge in practice.

Pros of pair programming

• Performance and speed. When two persons funnel their energy into one activity, the effectiveness doubles. This is especially vivid in the situations where a solo programmer faces some challenges. He/she can start walking and pondering about it, can leave it until tomorrow or even start procrastinating. Obviously, such an unproductive time is cut to a minimum when this is a pair game. Moreover, none of the participants spends much time checking email or googling something unrelated to work since your mate is unlikely to be happy about it sitting and waiting. All this incredibly increases the concentration levels, and, consequently, the velocity of delivery.
• Quality. Since two pairs of eyes are constantly monitoring the process, the bugs are more rare guests in the code lines. Simple mistakes that occur as a result of losing the sharpness of vision are promptly detected. Besides, the experience is multiplied, which helps partners learn from each other in practical terms. Time needed for unit testing and debugging is cut significantly.
• Training. Since software development is a lot about cooperation, being involved in a pair coding is a great way to practice the ability to collaborate, make compromises and be tolerant — i.e., all those soft skills some developers lack, but which are so valuable for the team. Apart from that, pair programming is a great opportunity for juniors and newcomers to flow into the working stream. They learn and get used to the inner processes, instruments and architecture quicker in comparison with the standard introductory and supervisory activities applied when trainees are often left alone with a code base to dig around.
• Redundancy. Two specialists are familiar with the matter, so if one is temporarily absent or even goes out of the project for some reason, you have a backup in the name of the other specialist.

Cons of pair programming

• Inequality of partners’ skills. If the two participants of the coding process have dramatically different levels of experience and mastery, there is a great likelihood that both of them will be more or less frustrated. Seniors may feel that they lose steam, and juniors may feel hog-tied. It is ok if the pair was created exactly for teaching purposes, but if not, it may cause discomfort.
• Non-compatibility. It may happen that the degree of interaction required is in conflict with a developer’s personal qualities and programming style. For many years, programming has been the domain for individual activity. Many developers are individualistic workers by nature and get used to working alone and at their own pace; a continuous interaction is perceived as a continuous interference. Some people just can’t work being constantly monitored, while others are too fond of communicating and distracting by small talks at the workplace. Some people demonstrate the best results when working according to their own schedule (and most IT companies allow a certain flexibility in this), so it’s difficult to make late risers and early birds work in sync.
• Ego and subjectivism. Having got used to working solo, many developers are reluctant to share their established procedures with someone else. They may feel that they would have been much more productive if they had worked alone. On top of that, every programmer has one’s own preferences in the sequence and style of coding course, and don’t want to share their hacks with others. They may even start pushing on the partner so that he or she accepts one’s vision or solution.

Some Points to Consider

If you decide to start practicing pair programming within your company, make sure you’ve prepared the ground for that.

It’s important not to push on the developers, trying to persuade them working in a pair. As it has been mentioned, many programmers prefer working alone and are watchful of new workplace techniques. If the person does not support the idea, don’t wait for the satisfactory results. Start introducing the new practice by engaging the most enthusiastic and newly hired specialists, and the further success will motivate others to be involved.

Be scrupulous about selecting a pair; you should consider the programmers’ experience, personal attitudes and the way they communicate with each other. Provide the mate programmers with a comfortable workplace.

It is a good idea to start exercising pair programming as a part of hiring and training processes. It will help both novices and versed developers feel all the benefits of this technique, and there are indeed many reasons to like it.

Anyways, you should try it yourself and become acquainted with pair coding through your sheer experience. Only after that, you will be able to see whether this practice is feasible for implementation within your company.

By the way, pair programming has some variations; for instance, ping pong interaction, when participants are involved in a test-driven development or virtual pair programming, when the two programmers are working remotely using specialized project management software. We are planning to immerse into this topic more and write an article on it soon. Stay tuned! As for now, we would be glad to read your feedback on this topic — both comments and questions.