Newswise — 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 successAguirre-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.”
Push for pair programmingDespite the purported advantages to pair programming, Aguirre-Urreta said 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 said 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 said. “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 said, 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 said. “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 this paper and its appearance in the IEEE Magazine 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.
He also would like to further the research by investigating which pairs work best together. He said 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.
“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 said. “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.’”
RSS