Wednesday, April 18, 2012

A Reflection on Pair Programming

At the beginning of this semester, all of the Computer Science students met and decided on the methodologies we would adhere to for the duration of the project. One technique that we chose is pair programming. This process is a part of Extreme Programming, which is a popular Agile methodology that emphasizes “communication, simplicity, feedback, respect, and courage” in software development [4].
In pair programming, “all code to be sent into production is created by two people working together at a single computer” [4]. Tom Dommett explains the basics of pair programming on Jeff Atwood’s blog Coding Horror.

The idea is two developers work on the same machine. Both have
keyboard and mouse. At any given time one is driver and the other
navigator. The roles switch either every hour, or whenever really.
The driver codes, the navigator is reading, checking, spell-checking
and sanity testing the code, whilst thinking through problems and
where to go next.

For the most part, pair programming has worked out well for our development team. It is easy to see some of the benefits that proponents of pair programming mention. For example, Jeffries points out that the navigator can catch the small errors that the driver may miss. Tom Dommett adds that pair programmed code is less likely to contain defects than code created by one developer working alone because there is someone watching to catch things that would cause problems later. I have seen this happen many times this semester. It is so easy to overlook those little mistakes when I’m in the middle of typing out an idea. With a partner to look over my work those mistakes can be caught sooner rather than later, saving precious time trying to find the source of defects later on. I am confident in saying that my partner very often influenced me to write better code than I would have on my own. Even just the act of explaining my ideas to my partner generally produced cleaner code.
Other benefits described by advocates of pair programming include that there are two people working to find a solution whenever a problem arises, which increases the chance of coming up with a good idea. Also, learning can occur between the partners when one person shows the other some new programming concept or trick [1]. Studies have shown that even student pair programming has a positive impact on learning, despite the general lack of knowledge of those involved [2]. While it was sometimes necessary for a third party, our professor, to step in and point us in the right direction, I still feel that I learned from the various partners I worked with.
Advocates of pair programming “have found that with very little practice, most people adapt quickly to pair development. They get to like it, because progress is discernibly faster” [3]. However, in my experience so far the progress does not always feel faster, and there are some bumps along the way. I tend to agree more with Don Wells’s explanation that “Pair programming is a social skill that takes time to learn. You are striving for a cooperative way to work that includes give and take from both partners regardless of corporate status. The best pair programmers know when to say ‘let's try your idea first.’ [You can’t] expect people to be good at it from the start. [...] It takes time to get used to pair programming so don't worry if it feels awkward at first.”
Learning to slow down enough to explain ideas to a partner has taken some work. Prior to pair programming my usual approach for solving a problem was to try whatever came to mind first, with little to no planning and preparation. While that approach is still possible with pair programming, it seemed to negate some of the methodology’s benefits when I encountered the situation. As the driver, if I did not explain my idea and where I was going, the navigator had a harder time pointing out mistakes in my logic and reasoning. As the navigator, when the driver took off on an idea without explaining it to me, I was left feeling lost and in turn disinterested. It became harder to pay attention when I could not understand where my partner was going with the idea. Avoiding these situations has taken work, and I am still learning to be better at it. Pair programming requires partners to communicate efficiently and express their ideas with clarity.
Working with different people every day has also been difficult to adapt to. When our team decided on our methodology it was also decided that we would switch pair programming partners periodically instead of always working with the same person. This is an attempt to make sure more than two people understand each part of the system. As an introvert, working with just one other person for long amounts of time can be hard, but switching partners and interacting with multiple partners in one week is harder. Over the two years that I have been using pair programming I can say for a fact that I have gotten better at working with other partners. My first experience with pair programming I actively avoided having to work with new people, and worked only with one specific person whenever possible. This semester I have tried very hard to be more open to working with other people. It is still difficult for me, but it is getting better. Sometimes when I am working with a partner, I get so immersed in writing code that I forget my reservations about working with new people all together.
Overall I have no doubt that pair programming has contributed to the quality of our team’s code. I have experienced its power to reduce small mistakes, and also to discover creative solutions to difficult problems. The experience has been wonderful at best and interesting at worst, and has helped me become a better programmer. While I do sometimes wish I could just work alone, adhering to the pair programming process was a good choice for our team and our project. Pair programming might be hard work, but it has been worth it.


Sources:

[1] Atwood, Jeff, and Tom Dommett. "Pair Programming vs. Code Reviews." Coding Horror. 18 Nov

[2] Braught, Grant, Tim Wahls, and L. Marlin Eby. "The Case for Pair Programming in the Computer
Science Classroom." ACM Transactions on Computing Education. 11. (2011).

[3] Jeffries, Ron. "Pair Programming."XProgramming.com An Agile Software Development Resource.

[4] Wells, Don. "Pair Programming." Extreme Programming. 1999.

No comments:

Post a Comment