Abstract: Pair programming comes from eXtreme programming (XP) and is one of its twelve best practices. Pair programming, as the name suggests, is when two programmers sit together and develop code in pairs.

This article is shared from the Huawei Cloud community “Is pair programming good”, author: Agile jianghu peach Blossom Island Sister Mei.

What is pair programming

Pair programming comes from eXtreme Programming (XP) and is one of its twelve best practices. Pair programming, as the name suggests, is when two programmers sit together and develop code in pairs. In EXTREME programming, all software products are produced by two programmers sitting side by side on the same machine.

Figure 1 pair programming

Two forms of pair programming

Different teams take different forms when using pair programming practices. Some have a clear division of labor, with one person writing the code and another reviewing it, responsible for its correctness and readability. One person does the detailed design and one person does the code implementation; Or one person writes the functional code and one person writes the test cases. Some are collaborative, where two people discuss the architecture, coding implementation, testing methods, code styles, and so on of the functionality being developed, and then take turns doing input and observation.

“Old belt new” is not pair programming

In China, there is another way for people to pair up: “the old lead the new”, in which an old employee leads a new employee. This kind of pair programming is not strictly in the sense of pair programming, but a form of new person training. In this way, there will be the phenomenon of a pair of words, losing the meaning of the pair itself.

The state of pair programming

There is a lot of chatter about pair programming on the web, and it is nearly the most controversial of all agile practices. According to VersionOne’s 14th annual State of Agile Report, pair programming accounted for 31 percent of agile engineering practices adopted by organizations, ranking eighth, just behind continuous deployment and higher than TDD, so there is a place for pair programming.

Figure 2 VersionOne’s 14th annual State of Agile Report – Agile Engineering Practices adopted by organizations

Whether or not an organization should adopt the practice of pair programming is a matter of whether or not it fits into its project and company culture. When we choose a practice, we need to be both physical and physical. If it’s just two programmers sitting together, one writing, the other reading, it’s just formal, but the point is to understand the idea behind the practice. In pairing, two programmers are usually required to be at a similar level, which can be complementary and lead to discussion. The wisdom of two people is greater than the wisdom of one person, which is the basic basis of pair programming, so as to improve product quality and work efficiency. Let’s take a look at the characteristics of pair programming.

Features of pair programming

From the project point of view, improved product quality

Pair programming, two people work together to complete a function, can avoid personal mistakes, usually personal ideas inevitably have limitations, their own code always feel how to write right. Everyone from different angles can see each other’s errors. And by pairing, code is reviewed by at least one programmer, which improves product quality by making design, testing, and coding more friendly and reducing defects.

In addition, the form of pairing also ensures that at least two people know a function and form backup for each other, so there will be no situation where one person asks for leave or leaves and no one knows about the follow-up. Some companies will regularly change the pair of people, so that the team members can be familiar with each functional module of the project, the formation of the project collective ownership and responsibility atmosphere, avoid the phenomenon of one person responsibility system, cleaning the door, but also can let the team members quickly familiar with the business.

From the perspective of the team, knowledge transfer and sharing are better realized, and the relationship between members is more harmonious

There is no denying that pairing is the best form of face-to-face communication for the transfer of knowledge and skills. At the same time, this kind of instant communication also leads to a harmonious relationship among colleagues, which is more conducive to creating a harmonious team atmosphere than everyone in a cubicle writing code. According to the “Johari window (communication window)” theory, in the practical work of interpersonal communication, the more common open area, the more convenient communication, the less likely to produce misunderstanding. As we expand our openness quadrant to others, we build more relationships with them, and pair programming is a good form of that.

FIG. 3 Johari window

In fact, pair programming is to gradually form a common value and culture of the team during the running in of the pair. This process is a long and subtle process, which inevitably goes through the process of divergence and unity. However, many teams will stop the practice directly in the divergence, so they cannot see the benefits of pairing.

From the personal point of view, improve personal ability, improve efficiency

In pairing, each person not only learns new knowledge and skills from the other, but is also influenced by the other’s work style and attitude. Everyone has his or her own advantages and merits, which deserve to be learned and respected. When the ability of each member of the team improves, the ability of the whole team improves.

In terms of work efficiency, pair programming makes people more focused on work, and some personal activities outside work will not be carried out. Everyone has his own task to be responsible for. In fact, two people form a small team that supervises each other and makes progress together. In order to complete the team tasks, two people will focus on their own tasks, thus improving the output efficiency.

Doubts about pair programming

As mentioned earlier, pair programming is highly controversial for two main reasons.

Managers think it raises labor costs

When two people do what one person can do, the output is cut in half, which is clearly a waste. In terms of improving the quality of the product, it won’t be obvious for a while, so undoubtedly pair programming is considered a bad practice.

The team found it difficult to find the right pair

First of all, there are not many people in the team who are not too different from each other; Secondly, pairing requires that two people’s temperament can be congenial, otherwise it is difficult to cooperate; Thirdly, some people like to work alone, are not good at cooperating with others and so on for many reasons and reasons.

For the above two points, there is no judgment here. Agile development does not mean that all agile practices should be implemented on your own team. Again, what works for you is best.

Click follow to learn about the fresh technologies of Huawei Cloud