Communications of the ACM
Are Two Programmers Really Better Than One?
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 described in "Effectiveness Of Pair Programming: Perceptions Of Software Professionals," to be published in the journal IEEE Software, by Miguel Aguirre-Urreta, a Texas Tech University professor in the Rawls College of Business.
Aguirre-Urreta, an assistant professor in the Area of Information Systems and Quantitative Sciences, along with colleagues from Washburn University in Kansas and Florida International University, researched the area of pair programming, why some programmers like it and some don't. They also examined what makes a good programming pair and at what point programmers come on board with the idea.
"The thought has been that pair programming has a lot of purported advantages in terms of speed, quality, and whatnot," Aguirre-Urreta says. "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 why, for 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; and when should pair programming 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 or her 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 says. "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."
Success Factors
Aguirre-Urreta says several factors are involved in determining whether 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 says. 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 says. "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 says 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 says. "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."
Not Always Best
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 or her coding or work methods to the other frequently, which results in a lengthier period to produce the code.
Aguirre-Urreta says 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 says 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 says. "Again, it depends on the project. There are some combinations that seem to just work better than others."
Pushing for Pairs
Despite the purported advantages to pair programming, Aguirre-Urreta says it has been difficult to get the idea to take hold fully with the programming community.
With every new idea, technique, or development, Aguirre-Urreta says there are those who are really willing to try it because they have been beaten down by the previous way of doing things. But once all the enthusiasts are immersed in the new technique, adoption of that new technique slows down, or plateaus.
Much the same can be said for pair programming. Those programmers who have embraced the idea and used it have a much more favorable view of pair programming than those who have resisted its use. It could be a matter of viewing pair programming as positive, but the way they achieve success now has worked well and there's no need to change it.
Eventually, however, Aguirre-Urreta's research discovered once programmers give pair programming a try and use it over a period of time, they eventually come around to its advantages.
"We don't know if it's six months of doing it or a whole year, or it could be three weeks," Aguirre-Urreta says. "We don't know where that click happens and the perception shifts, but we can tell and compare with people who have a fair amount of experience with pair programming to people who haven't done it, there are some marked differences in everything, from benefits to downsizing, cost, all those perceptions."
Once that happens, Aguirre-Urreta says, the change in perception comes quickly.
"We think it's actually the act of just doing it, being there and experiencing working with the other person," Aguirre-Urreta says. "They see that, indeed, their fears that it will take forever to get done are not really realized. They see the quality of the code is indeed better and there is a huge time-saver. Fixing code is very expensive compared to producing quality code from the get-go."
Aguirre-Urreta is hopeful the research's publication in IEEE Software will encourage programmers who have been reluctant to use pair programming to give it a second chance, seeing how popular it is with those who were reluctant to it at one time.
Co-authors of the IEEE Software article are W. Sun, G. Marakas, and M. Aguirre-Urreta.
Aguirre-Urreta would like to further the research by investigating which pairs work best together. He and his colleagues have good models in place but haven't always had the best data until now, so he would like to plug that data into the models to see which pairings produce the best increase in productivity, he says.
"The work we're doing now is using those same simulation models, but with the data we have now we feel is more realistic, we'll see what we get out of it," Aguirre-Urreta says. "We have data from different groups and we know how much they agree or disagree, so we can plug that into the models and get results that have some validity based on the data from professionals.
"This research should help motivate someone to say, 'if all the people who are like me and do the same work I do think it's a good idea, maybe I should try it and I don't know what I'm missing.'"
No entries found