(Editor’s Note: The following is an extract from a November 24, 2015 Science Daily article based on materials provided by Texas Tech University. The original, is available at http://www.sciencedaily.com/releases/2015/11/151124082459.htm .)
Scientists investigated the advantages and perceptions of pair programming from the programmer’s standpoint.
Texas Tech professor Miguel Aguirre-Urreta and his colleagues investigated the advantages and perceptions of pair programming from the programmer’s standpoint.
It seems like a simple premise — two people on one project can do the job faster and easier and generate a better product.
So why, in computer programming, is there still a significant resistance to sharing the work or at least having someone on the project who can check the work being done to ensure it is of the highest quality? That was the idea behind the research in a paper recently published by a Texas Tech University professor in the Rawls College of Business.
Miguel Aguirre-Urreta, an assistant professor in the Area of Information Systems and Quantitative Sciences (ISQS), along with colleagues from Washburn University in Kansas and Florida International University, researched the area of pair programming and why some programmers like it, some don’t, what makes a good programming pair and at what point programmers come on board with the idea.
The findings of their paper, “Effectiveness of Pair Programming Perceptions of Software Professionals,” has been accepted for publication in an upcoming edition of IEEE Software magazine.
“The thought has been that pair programming has a lot of purported advantages in terms of speed, quality and whatnot,” Aguirre-Urreta said. “But we haven’t seen as much of an uptake as you would expect from something that has those advantages. We wanted to see if we could understand the reasons who or which kind of project pair programming is a good idea and for which project it is wasted on, what are the perceptions people who have done this for a living have on pair programming and when it should be used.”
When it comes to programming, or writing code for programs, Aguirre-Urreta’s research seems to show two heads could indeed be better than one. But the success of having two programmers, called pair programming, also depends on the complexity of the project and the composition of the programming pair involved.
In instances where pair programming is used, Aguirre-Urreta’s research shows programmers have a more favorable view of the technique than those who have not participated in pair programming. It also shows once a programmer is involved with pair programming, his view toward the technique is more favorable than before.
“Part of the culture and the kind of work environment is it tends to be more competitive in terms of producing quality code,” Aguirre-Urreta said. “Working by yourself is part of the culture. The thing we did talk about in the research and found interesting is people who haven’t tried pair programming have a very negative view of it and people who have tried it and done it for a few years have a much better perception of its benefits.”
Factors of success Aguirre-Urreta said several factors are involved in determining whether or not pair programming is right for a project and what constitutes a good pairing of programmers.
Complexity of the project seems to be the first determining factor, Aguirre-Urreta said. If it is a simple project that doesn’t require much time to complete, then a single programmer is likely the best solution. However, if it is a longer term project requiring a great deal or different types of code, pair programming seems to work well.
“The main advantage to pair programming would be having two people work together on the problem where you get more of a discussion between two people,” Aguirre-Urreta said. “You get a better exchange of ideas. It’s not a scenario where one person has a certain way of doing things or a certain approach to the problem that they can’t break away from because they have someone else working with them.”
In a typical pair programming situation, Aguirre-Urreta said the pair works by having one person write the code and the second person checks the quality of the code to see if it could be done better. Eventually, the roles will switch so neither programmer gets burned out doing the same thing for the length of the project.
“Presumably, the quality of the product is going to be much better,” Aguirre-Urreta said. “The person doing it by himself is going to find the mistakes at some point but usually it’s after someone complains to them that it’s not going to work. With pair programming, you should have a better quality product, fewer bugs, a better exchange of ideas and also a knowledge sharing and trading aspect.”
Pair programming, however, isn’t always the best solution. For one, if the project is a small one, it would be difficult to justify having two people, and thus two salaries, working for its solution unless two people can produce quality code at a much quicker rate. Also, pairing two people means one person may have to explain his coding or work methods to the other frequently, which results in a lengthier period to produce the code.
Aguirre-Urreta said the question is whether that outweighs the factor of working alone and having no one checking the work being done, or if the lone programmer gets stuck on something and has no one there with whom to brainstorm or troubleshoot.
Then there’s the factor of the actual makeup of the programming pair. It all depends on the type of project, but Aguirre-Urreta said the research found that for projects in which pair programming is used as a training tool, having one programmer with a good amount of experience and another who is relatively new often produces the best results. Often pairing two senior programmers or two junior programmers doesn’t produce the same results or quality code.
“If the goal is to produce good, nice working software but also train junior programmers and help develop programmers, pairing them with a senior programmer seems to work well,” Aguirre-Urreta said. “Again, it depends on the project. There are some combinations that seem to just work better than others.”
(Editor’s Note: The original article continues with a discussion of why it has been difficult to get the idea to take hold fully with the programming community. The researchers also give some suggestions for further research.)
Cite This Page:
MLA APA Chicago
Texas Tech University. “Computer programming: Are two heads really better than one?.” ScienceDaily. ScienceDaily, 24 November 2015.