In 2000, Kent Beck wrote about pair programming, and he suggested this practice could improve software quality while not adversely affecting duration as compared to solo programming. On comparable lines, I built the idea of confined pair programming. I led a pilot test in four Agile Java advancement projects in two Indian multinational companies (MNCs) and found that it not only delivers a higher-quality software/product without affecting the term but also functions admirably in the following related areas:
- Faster programming
- Employee satisfaction
- Employee confidence
- Better learning
- Improved quality and readability of code
- Lesser regression defects
I conclude the article with findings from the experiment; there is definitely scope for future research on this topic.
Pair programming is a style of programming in which two programmers work side by side at one computer, continuously collaborating on the same design, algorithm, code, or test. Of the many ways to do pair programming, two core methods have evolved. The first method is to have one coder as the "driver" and the other as the "navigator." The driver performs the coding, whereas the navigator aids the driver in thinking through issues, searching for errors, discussing alternatives, etc.
The other is the ping-pong approach whereby one partner writes a test and the other person takes the keyboard and implements just enough code to pass that test. A review of the literature suggests that the earlier a bug is discovered, the less costly it is to fix. If that is true, then we should not be inspecting the code after it is complete but instead should perform the review during the programming cycle, or in the moment.
Being roused by the Kent Beck pair programming approach, I have rebuilt it by making certain changes to realize the product quality advantages of pair programming yet maintain the rate/speed of solo programming.
I call this modified pair programming technique confined pair programming (CPP)
Confined pair programming technique
The method used in confined pair programming, or CPP, implementation is that of the driver/navigator with some variation in implementation as described below:
- Two programmers work on one task but work together on one computer for 50% of the office hours. For the remaining 50% of the time, they work independently.
- Pair programmers take the design task independently. They can thereafter discuss and finalize the design for the story.
- Pairing is carried out with a junior and a senior associate (whereas Beck advises pairing associates with the same level of expertise).
- Only high-complexity stories, not simple stories, are distributed to the pair programmers. Solo programmers handle the simple stories. As a result, the project team is a mix of solo and pair programmers.
- Under the driver/navigator method, the driver and navigator rotate/swap their roles after every hour, whereas in pair programming the role is fixed.
- Coding is carried out in pairs whereby the driver performs the coding and the navigator aids the driver by searching for errors, discussing alternatives, and performing code review simultaneously.
- After coding, a separate review step is introduced. This involves a tester as well as the junior programmer from the pair. Here, the tester is a full participant in the code review process and ensures code readability while in the process gains better knowledge to write test cases with 100% code coverage.
Testing the CPP technique
I conducted some experiments in four Agile Java development projects in two Indian MNCs. Fortunately, in all these projects, we managed to get at least one shadow resource/associate who was not getting billed for the project. Therefore, that associate did not need to burn the hours in Daily Scrums and could work on anything that the project manager assigned either individually or in a pair.
These shadow associates were asked to pair up with senior Java associates in their team and work on stories in confined pairs, abiding by the rules provided above while the other team members continue to work solo.
We observed the four teams in the following areas in each sprint for six months:
- Defect count and defect density in the stories completed by the confined pairs
- Number of stories completed and the assigned story points
- Quality and readability of the code
- Employee satisfaction
- Employee confidence
- Learning by junior associates
Without even examining the results, we can expect that the quality will improve due to pair programming because two people are more likely to solve complex problems more effectively than only one. A dialogue between two developers is likely to generate a better outcome than when either of the developers acts alone.
Established software engineering techniques often stress the importance of defect prevention and efficient defect removal. This "watch-over-the-shoulder" technique may epitomize defect prevention and defect removal efficiency. "The human eye has an almost infinite capacity for not seeing what it does not want to see as programmers, if left to their own devices, will ignore the most glaring errors in their output — errors that anyone else can see in an instant." (Weinberg 1998)
As Beck indicated, "If people program solo, they are more likely to make mistakes, more likely to overdesign, and more likely to blow off the other practices, particularly under pressure."
One of the problems faced during pair programming is the idea that it will be too slow.
It's obvious that two people doing a one-person job constitutes twice the effort. Considering the advantages of thinking and working together, which can shorten the process, can it reduce the time by 50%? This is the question many people have asked when countering the pair programming approach.
The benefit of CPP is in people working in pairs only 50% of the time, on coding only, whereas analysis, design, unit testing, and integration are carried out separately. This reduces the duration.
For all four teams, the main source of data were interviews and sprint data for paired members. To analyze the level of effectiveness of CCP for the four projects, we considered certain broad areas and realized the following results in each:
Quality is (can be) measured in a couple of different ways. The most common single measure is defect density, which accounts for various types of errors per body of code.
Using CCP, defect density and defect count has been reduced considerably, particularly the regression defect count. Developers feel that matching with a QA partner has helped them obtain more bits of knowledge because of the new story/requirements. Thus, they could concentrate on those areas and get those tested and rectified before the QA deployment.
QA partners who got the chance to survey the code likewise emerged with confidence since they got the opportunity to see which parts of code they had to cover. Consequently, it prepared them for composing better test cases.
Meaningfulness of the code was enhanced after QA checked the code and gave proper feedback.
Comments from one of the senior Java associates who worked in a confined pair:
I strongly feel confined pair programming is the primary reason our team has been successful. It has given us a very high level of code quality (almost to the point of zero defects).
Duration is the total calendar or wall time required to complete a task; productivity is the task per unit of time; and effort is the person hours required to complete a task.
The confined pair groups completed the task 50% more quickly and effectively by producing better algorithms and code in less time. It's analogous to a senior associate who has estimated a complex story to be completed in ten program days, but it was completed in five program days while working in pair.
The data was compared for six months and the average reduction in timeline varies within 40 to 50%. These numbers clearly show that there is no reduction in speed, as is observed in pair programming.
Risk has been considerably reduced in CPP, because if one programmer is gone, you will always have another to document the process and teach everyone else how it works.
As noted by confined pairs:
"There are many instances where risk has been considerably reduced since two people are involved in one story, while there was considerable reduction in velocity when associates took unplanned off due to unavoidable reasons and were not able to deliver the story by end of sprint, as they were working independently on that story."
The majority of the senior programmers were initially skeptical of the value of collaboration in working on the same problem, but after few months, we observed that they started enjoying the confined pairing process.
Also, results showed that collaboration improved the performance of both developers, and they started enjoying working in pairs on the problem-solving process.
Pair programmers cite that "it is amazing how many obvious but unnoticed defects become noticed by another person watching over your shoulder. Additionally, these defects can be removed without the natural animosity that might develop in a formal inspection meeting."
The shadow junior associates got more insights into technology and the application. They felt a boost in their confidence levels.
Finally, the constant communication during the development of complex software products contributed to the improvement of the developers' skills, including interpersonal and soft skills.
CPP positively impacted the learning outcomes of developers. Since developers have been participating in pair programming, they have learned from each other.
The experiments showed that, together, a confined pair will come up with more than twice as many possible solutions as the two developers would have working alone. They more quickly zero in on the best solution and implement it more quickly and achieve better quality. A survey respondent reflects, "It is a powerful technique, as there are two brains concentrating on the same problem all the time. It forces one to concentrate fully on the problem at hand."
Advantages of CCP over pair programming
In general, pair programming does improve software quality but lags on duration and speed. Also, there is no evidence that pair programming makes a positive impact on other parameters, such as learning, confidence, and satisfaction.
In CPP, pairs are confined, and they work together at one desktop for only 50% of the time; thus, it provides an opportunity to think independently for the remaining hours. This drives better ideas that enable them to come up with out-of-the-box solutions. Pairing further helps them convert their ideas to a best solution through active collaboration.
I also found that CPP is superior to pair programming when it comes to learning. Since junior developers are paired with senior developers, they learn more rapidly. Junior associates gain considerably from the experience and technical expertise of senior associates, while seniors get out-of-the box solutions from juniors who consider the problem from a fresh and new perspective, making it a win-win scenario for both.
Since pairs are expected to work only on complex tasks in CPP, quality has improved without impacting the velocity and duration. By comparison, grunt-work tasks are straightforward, so it would be better to divide the work into two groups, and let each developer do some of the work separately to get the work done. Some tasks require a lot of typing but aren't worth spending a few hours to find a better solution, as these can be done easily if each developer takes a brute-force approach for a few hours.
At the point when individuals work in sets on basic undertakings, however, there is not much effect on the quality but rather on the length for that errand, which eventually affects the speed. It's not a decent quality-time deal. Although in pair programming there is no evidence that shows there is an increase in the associate's confidence and satisfaction levels, there is considerable proof observed in my CPP experiment that it boosts the confidence level of junior associates, and the pair's work satisfaction also increases considerably.
Work satisfaction increases due to ownership, as associates get an opportunity to work independently on design and testing activities, and they work collaboratively on the coding activity.
Our experiments proved that CPP is more productive than dividing the work between two programmers and then integrating the results. We further analyzed that if pairing is followed in a confined manner, we can eliminate the impact on duration with a considerable boost in associate satisfaction, confidence, and enjoyment levels. Also, learning will considerably increase with pairing of senior-junior associates. Development-QA pairing, finally, not only increases the code quality but also enables the tester to write test cases that can cover 100% of the code.
However, further testing shows that this is probably not the end of the story — there are likely some moderating factors in each of these relationships. This means that the relationship between CPP and organizational outcomes may be a bit tricky.