[Agility and limits] Some Opinions on paired Programming

When talking with my colleagues about the pairing programming of extreme programming, I often encounter a series of objections, which leads to great controversy. According to their understanding, pairing programming is simply a joke, they think that this development method is almost impossible and will consume time in a series of collaboration. In fact, I think this is a concept constraint, but why do they reflect this strong? What is paired programming? What are the advantages of paired programming?

Master Laurie Williams (http://collaboration.csc.ncsu.edu/laurie/) once described Pair programming as "a programming style that consists of twoProgramMembers work on one computer side by side, and collaborate to complete the same design,Algorithm,CodeOr test ". From this we can know that pairing programming is not only about coding or implementation, but also about the work of two partners sitting in front of the computer holding the mouse and tapping the keyboard. Steve Hayes was also on hisArticleAs mentioned in, "pairing programming is not simply a person looking at what the other is doing-in the fruitful pairing work, these two partners often work at different abstract layers, one person pays attention to the details of the code written to achieve the current goal, while the other person considers the bigger prospects and what to do next. The roles of these two people change frequently. This is a high-intensity, rigorous, and often exhausting activity, but it can create well-thought-out high-quality code ."

My colleagues and colleagues sneer at Pair programming because of traditional software development habits. They cannot accept this new development model and are indeed unacceptable, traditional development habits have a profound impact on us, people have always thought that writing code for development requires a very quiet environment of thinking (so that our company's development department is isolated from other departments by sound insulation glass ), we often don't want to be disturbed at work, let alone the discussion of two people sitting in front of a machine, scrambling to type the code and drag the control ......

If you still understand Pair programming this way, it is really wrong. "Of course these are general ideas, but you are always reluctant to work with other programmers, satisfaction with their work will certainly be affected by something like pairing programming, it is generally related to the idea that the time spent by two people working on one machine must be twice as long as they work independently and then merge their work results."

Here is a reference to the description of pairing programming in Steve Hayes's article:

Another misunderstanding is that the success or failure of pairing programming should be ultimately determined by the quality of the generated software. When two people work together, there are at least three results:

Software
Common understanding of applications (Business Domain, design and implementation)
Skill transfer
 
The ratio of these changes depends on the balance and dynamics of the pair, but all of the above three will be shown to some extent. When an experienced programmer matches a newbie,

The software produced by pairing may not be produced by the experienced programmer working independently, but this newbie will certainly learn a lot about this application and about editing.

Basic knowledge of the process.

Another goal of paired programming is to disseminate the knowledge of application design and implementation as widely as possible.

This is achieved through pairing rotation, so that everyone in the group can pair with others over a period of time, and the specific part of the application will be made by as many people as possible

. In this environment, bad code won't exist for too long, because it is exposed to many eyes (similar to the principle behind developer code development), and when

When the design cycle comes, the group will benefit from everyone's contribution, instead of relying on an individual who is familiar with specific parts of the application.

Pairing programming has the following benefits:

Direct and continuous code review
Working with others will increase responsibility and discipline.
It is much harder to get lazy when someone is staring at it!
Two programmers have very little possibility of having the same disadvantages and blind spots, so we will have a powerful solution.
If you enter a dead end, pairing will waste much time, because one of them will inevitably get bored and want to seek help.
 
In the case of regular pairing and rotation, the last two items in the above list are especially realistic. Of course, there are many methods that seem like pairing programming, but they cannot be achieved, or these advantages are broken.

It is unrealistic to allow programmers to work with each other for eight hours a day-the continuous interaction of pairing brings accurate and clear results, but this process is also time-consuming and (a person) there will always be tasks other than development to complete.

Practical experience tells us that pairing programming is an effective way to improve software quality and reduce development time, but it is not suitable for all programmers. It requires a careful implementation to be effective.

My thoughts:
Since there are so many advantages, why does the domestic software industry reject such a method so badly?
Q: Does your company use this method? Do you want to use it?
I'm afraid there are few, right?