From the perspective of improving project quality, promoting knowledge transfer, and reducing project risks, this article describes some experiences of the author's team in the practice of pair programming, and how to avoid or reduce its negative impact.
Do you know about pair programming? Have you tried pair programming practice? Maybe you haven't tried or even understood it yet, so let's learn and understand the practice of agile pair programming together. I believe you will gain something if you are interested in agile.
What is pair programming
Pair Programming is an agile software development practice in which two programmers sit side by side in front of a computer, face the same monitor, and work together using the same keyboard and mouse. One person enters the code, while the other person reviews every line of code he enters. The person entering the code is called the driver, the person reviewing the code is called the observer (or navigator), and the two programmers periodically switch roles. Together they complete requirements analysis, system design, coding, unit testing, integration testing, and documentation. Basically all development segments work side-by-side, equally, and complementary (as shown in Figure 1).
Figure 1 Sharing a computer for pair programming
The above is a description of pair programming in eXtreme Programming (XP), which has the following main advantages:
- Conducive to improving project quality and reducing bugs;
- Conducive to knowledge transfer and reduce learning cost;
- Multiple people are familiar with the same piece of code to reduce project risks;
- Working with others increases responsibility and discipline etc.
Despite all the enticing advantages of pair programming, the practice of pair programming is rare, and the main reasons may be:
- Pair programming requires more resources;
- Both sides of the pair need to focus at the same time, otherwise the efficiency will be lower;
- The ability requirements of the paired personnel are suitable, otherwise they will not be able to play the role of observers, or even become dependent;
- Unsuccessful pairings often lead to quarrels, internal friction, and team disharmony.
Pair programming is one of the controversial agile practices. In addition to some of the advantages and disadvantages mentioned above, there may be more different opinions, but analyzing the pros and cons is not the focus of this article.
Experience
As far as my project team is concerned, the development team of about 6 people needs to support the demand development of multiple small and medium-sized independent products. Under the heavy business pressure, the rapid delivery of user value is the first priority, so I want to try to share a computer. The practice of pair development can only be a luxury. Let team developers be familiar with each other's product codes as much as possible, improve project development efficiency and ensure good project quality, which are the key issues we need to solve during project development.
We have tried to improve code quality and familiarity with each other's business code through activities such as collective Code Review and design exchange and sharing, but have always had little success. The main problem is that this kind of centralized activity is difficult to arrange, the communication effect is not good with many people, and the cost performance is not high. Later, thanks to the company's mentoring mechanism, a prototype of agile pairing was found in a pair of newcomers and mentors. Due to their close cooperation and timely communication when encountering problems, the newcomers have performed well in project progress and quality, and integrated into the team well. In the follow-up project process, we constantly try and optimize this pairing form, and gradually form a relatively fixed working method.
Compared with XP pair programming, the most significant difference in agile pair programming is that pairing requires analysis, system design and problem discussion, but they are implemented separately by coding, and the effect of pairing can be achieved through frequent reviews in the process. Developers work in pairs to jointly claim development tasks and take responsibility for the development tasks they undertake. In the requirements understanding and design stages, the two parties design and discuss together, and then divide the labor for their respective coding and implementation, and pass Code Review to ensure that the implementation is consistent with the design. Communicate and discuss the problems found during the pairing process at any time. Since the business logic of the product is relatively uncomplicated, most of the problems in the project can be solved through this small-scale and efficient communication, achieving higher development efficiency and ensuring code quality. Currently, the main pairing activities in the development process are shown in Figure 2.
Figure 2 The main activities of agile pairing
What are the benefits of pairing activities (shown in Figure 3)?
- Improve project quality. The paired developers have fully communicated and discussed on requirements understanding and design ideas, and can find and solve problems as soon as possible, avoiding rework caused by deviations in requirements understanding and design defects in the early stage.
- Knowledge transfer. For new employees or less experienced developers, through frequent communication and discussions, they can quickly enter the role and accumulate experience, playing the role of mentoring.
- backup to avoid project risks. The paired personnel back up each other, which is beneficial for team members to familiarize themselves with business codes, and is beneficial to project risk control if there is a change in personnel.
Figure 3 Pairs fully discuss design details and problems
Regardless of whether it is a new or old pair or a strong or weak pair, we must try our best to avoid one party's dependence on the other, give new people enough space for growth and exercise, let them think and solve problems independently, and allow them to try and fail within a controllable range. Valuable experience grows. Otherwise, the team will only have one more executor, and it is difficult to achieve the desired effect in pairing. At the same time, a certain degree of independent activities allows everyone to retain their own work habits, and the form is more free and flexible. Of course, you may have questions about how to ensure the correctness of the work of senior engineers in the pairing candidates, because newcomers and weak people are likely to be unable to provide the desired review help. This problem is inevitable in our pairing, and it may be a good solution to selectively invite other senior experts to review, especially for some important complex business logic.
Engineers participating in the pairing should have the ability to think independently and solve problems, and have a good sense of teamwork. Otherwise, not only will there be no good pairing effect, but some new problems will be brought on the contrary. In addition, pairing is not limited to R&D engineers, but also between R&D and test engineers or with product managers (as shown in Figure 4), which can also bring good results.
Figure 4 Pairing between R&D and front-end engineer testing to solve problems
Introducing agile practice is about fully understanding and combining with the actual situation, and it is a process of adaptation and development, and it is definitely not a good idea to follow the steps. It may be the best policy for us to selectively pair, and carry out selective implementation in terms of pairing candidates, occasions, and pairing links.