No Pairing, No Programming

Image Source: Codementor

One of the more controversial practices in Extreme Programming is pair programming. When many team managers talk about it, their first reaction is a waste of time: isn't it a waste of time to arrange for two people to do what one person can do? Is pair programming a waste of time? I want to share our team's more than ten years of practice in pairing programming.

Let's start by defining what pair programming is. Many of you may think that your team has never implemented pair programming, but every development team has done it. The most common scenario is when someone encounters a difficult bug that one person can't solve and then discusses and communicates with another colleague to solve the problem, a pair programming. Another example is when the team assigns a master to guide a newcomer; the master sits with the newcomer to demonstrate how to solve the problem, discuss the ideas and methods of specific problems, or write some codes that belong to the category of pair programming. Many people will think two people sit in front of a computer for a long time to program pairing programming. But in fact, pair programming (or pair working) is a natural form of collaboration that is everywhere all the time.

Let's look at the efficiency of pair programming that everyone is concerned about. It is difficult to do a complete metric because it is hard to find two teams with the same programming ability to compare and test. However, it can be seen that pairing programming will not reduce efficiency, and even the efficiency of pairing programming will be higher than that of programming alone, according to our more than ten years of pairing programming. Let's analyze it concretely.

Image Source: The Product Developer

From a programming perspective, there are two tasks:

• The first is to find solutions quickly (design);
• The second is to implement it quickly(coding).

When looking for a solution, two things tend to happen:

• The first is a delay in finding a solution and getting stuck.
• The second is to find a direction to start programming hastily and finally find that the path is blocked and can only be reinvented.

Therefore, the first thing to be solved is how to find a reasonable solution quickly. As the saying goes, two heads are better than one. When two people communicate with each other, on the one hand, they can better clarify their needs. On the other hand, they can quickly form an effective solution by combining their own experiences, learning from each other's strengths and offsetting weaknesses. It is easy for one person to make mistakes, but the probability of making mistakes by two people is much lower.

Here are four common problems with coding:

• The first problem is that coding efficiency is low due to programming ability or lack of business proficiency.
• The second problem is the waste caused by low-level errors in programming.
• The third is the logical problem caused by poor consideration.
• The fourth is the waste of switching states due to inattention. From a lean perspective, these are all wastes, and pair programming is a great way to reduce these wastes.

For example, how the master guides newcomers can help the novices understand common programming skills and business details. The characteristics of pair programming provide a third perspective of the coding process, so many low-level errors can be found and solved the first time. In pairing, there is a frequent exchange of computer control between two people, which requires a high degree of concentration and can also avoid logic problems caused by poor thinking. When programming alone, it is easy to be accidentally interrupted by phone calls, WeChat, etc. When a partner sits next to you, it isn't very comfortable to always look at your phone, and then the two people can concentrate on the work for a long time.

Therefore, from the perspective of design and coding, pair programming can improve the efficiency of programming. In addition, there are several other benefits of pair programming. In addition to the master guiding the novices, as we mentioned above, it can also effectively promote the sharing and inheritance of business knowledge and programming experience within the team, thus promoting collective code ownership, forming unified coding standards and true teamwork, and laying a solid foundation for internal rotation and avoiding single points of failure.

Pair programming can be done in many ways. When we deal with some core problems, we will adopt the strong-style pairing, where two people will work on a fixed iteration. When a task is created in Zen Tao, it is also assigned to an account for tracking the workload of the pair programming, such as the xxx combination. Normally we will adopt the weak-style pairing, and the combination of personnel will be flexible. We will have two sets of keyboards and mice when pair programming and any colleague can take over the keyboard to code at any time.

The practices in Extreme Programming are complementary to each other. Pair programming can promote the practice of collective code ownership and code specification. In turn, collective code ownership and code specification are the basis of pair programming.

So, object-oriented programming starts with pairing.