What is Pair Programming?

Pair Programming as Part of Extreme Programming

Pair Programming is often declared to be part of Extreme Programming. In fact, it belongs next to

• refactoring,
• working in short iterations,
• the effort estimation via Planning Poker,
• continuous integration,
• the test-driven development etc.

to the 12 so-called traditional practices from Extreme Programming. Since Extreme Programming is considered an agile method, Pair Programming is often described as an agile approach. On the one hand, this is correct, on the other hand, it can also be used in classical developments – for example, according to V-Modell XT.

Interestingly, Pair Programming was already used in the 1950s, long before it got its name. Fred Brooks reported in his 1975 book “The Mythical Man-Month” how he tried pair programming as a doctoral student together with his fellow student William Wright between 1953 and 1956: “We produced 1,500 lines of defect-free code; it ran correctly first try.”

In 1995, Larry Constantine, a US software engineer and professor, wrote that he had observed “dynamic duos” at Whitesmiths, Ltd. in the early 1980s. And in 1993, James O. Coplien described organizational patterns and the approach of solving problems together by “compatible designers working together as a pair”. In 1995 Coplien published the book “Developing in Pairs”.

In October 1999 Kent Beck published the book “Extreme Programming Explained”. 

The Procedure for Pair Programming

The procedure for Pair Programming is relatively simple:

• There are two roles: the driver or pilot and the navigator or observer. The Driver operates the computer and writes the code. He comments what he does so that the Navigator can understand the underlying thoughts. The Navigator observes, gives feedback on the implementation and tries to develop ideas to solve the task even better. The goal of role sharing is to have two different perspectives on the code: The driver should think more tactically, he should think about the details, about the existing lines of code. The navigator can think more strategically in his observing role. He has the overall picture in view.
• The roles change regularly between the developers, so that everyone alternates between driver and navigator.
• Ideally, the pair develops a team spirit, communicates continuously and clarifies any ambiguities regarding the procedure, programming and testing as quickly as possible.
• It is quite common that one of the two developers leaves the team after a while (2-3 days or a week) and makes room for another colleague. This results in a pair rotation. In some publications, the person who stays is called the anchor. The intention behind it (unless it is a rotation due to holidays or illness): a fresh perspective, new energy and avoiding silos. Of course, each organisation should decide individually if and when a change makes sense.

In practice, opinions vary as to whether the developers really share a computer or whether everyone has their own computer and you work on a common stand. In connection with today’s version management, working with two parallel computers is not a special challenge.

The Advantages of Pair Programming

There are a number of advantages that are often mentioned in the context of Pair Programming:

• Knowledge transfer: The knowledge between both participants is shared and increased. Other perspectives broaden the individual horizon.
• Pleasure in the work: Often takes increases, at least temporarily, the joy of exchange and interaction.
• Improved cooperation in tandem and through pair rotation also in the entire development team.

Other advantages are often cited as

• better code,
• fewer errors,
• lower risk,
• improved discipline or
• higher efficiency.

These benefits may or may not apply. Just because two developers implement a common idea to solve a task, another idea might still be better. The implementation of the idea may be efficient, but if a “wrong” idea is implemented, the effectiveness suffers. So it is important not only to “do things right”, but also to “do the right things”.

An “integrated” code review is also often mentioned. Since four eyes are known to see more than just two, it can be assumed that more bugs are found during implementation than during a self-test by a single developer. But again: is this really more effective and/or efficient than if it is done by a separate developer? In any case, it is clear that this advantage should also be examined in each individual case.

However, two advantages for Pair Programming are usually overlooked in practice:

• Mentoring. It is very well suited for establishing a mentoring relationship with an experienced and a less experienced developer. Reverse mentoring could be established as well as the induction of new developer colleagues.
• Cooperation between contractor and client, between supplier and customer. Especially in times when feedback and direct communication are becoming increasingly important, and companies temporarily want additional service providers to supplement existing development capacities, Pair Programming also makes a lot of sense beyond company boundaries.

Tips for Pair Programming

There are some aspects and recommendations that organisations and/or the pairs can use to make life a little easier for themselves. Here you will find some tips:

• Clarify the general scope of Pair Programming. Is it a temporary thing, a first test or a permanent form of cooperation.
• Clarify the concrete cooperation, e.g. when do you start in the morning, when do you stop, when are there scheduled breaks, at which workplace do you work etc.
• Only process one task at a time. One task, one goal, one procedure.
• Ideally, there are coding conventions and coding styles in the organisation. The navigator should ensure that they are adhered to, or inform the driver of any violations.
• Discussions are part of Pair Programming, but cooperation often takes place in open-plan offices, so the volume should be “appropriate”.
• Use line numbers to make it easier to identify specific lines of code.
• Play “Ping Pong”, for example in the course of Test -Driven Development. Developer A writes a test (Ping), developer B writes the implementation to pass the test (Pong). Developer A extends the test (Ping) and developer B extends the implementation (Pong).
• It can be useful to use a timer to change roles at fixed times, for example every 20 minutes. The more familiar a tandem is, the less important the use of a timer becomes.
• Tandem programming is also a question of attitude. Instead of “I have an idea, give me the keyboard” a “I have an idea. You take the keyboard.” would be desirable.
• And last but not least: arrange lessons learned or retrospectives to learn from and with each other.

Impulse to discuss:

Is there a way to calculate the financial benefit of Pair Programming?

Notes:

Here you can find the text of The Mythical Man-Month.

Here you will find additional information from our Smartpedia section:

What is Clean Code?

What does t2informatik actually do? One click and you'll know.