Pair
From CS315
Introduction
The purpose of “All I Really Need to Know about Pair Programming I Learned in Kindergarten,” by Laurie A. Williams and Robert R. Kessler, is to convince readers that pair programming is beneficial and to aid readers in their transition from lone programming to effective pair programming. The authors of the paper emphasize that the principles of pair programming mimic the lessons that everyone has already learned in kindergarten. These lessons can be found in the poem “All I Really Need to Know I Learned in Kindergarten” by Robert Fulghum. The pair programming process can be briefly described as two programmers working on one program while sitting next to each other in front of one computer.
Pair Programming: Evidence of Success
Pair programming was used in a software development methodology called “Extreme Programming” or, simply, XP. XP was used to develop the largely successful Chrysler Comprehensive Compensation system over a decade ago. Furthermore, after four unsuccessful years in development, the Ford Motor Company used XP to finish the Vehicle Cost and Profit System (VCAPS) in less than a year.
An experiment by Temple University Professor Nosek showed that pair programmers completed challenging problems 40% faster, more effectively with better algorithms, and in less time than lone programmers. Collaboration improved not only performance, but also the enjoyment of the experience.
Principles of Pair Programming
Following the guidelines in Fulghum’s poem:
Share everything.
Two programmers are in charge of completing one project. While one programmer has control of the keyboard and is writing or typing the program, the other is constantly checking for errors and providing support. Both programmers are equally responsible for the successful completion of this project. When one fails, the other also fails. When one succeeds, the other also succeeds.
Play fair.
The “Driver” is defined as the programmer with control of the keyboard. The “Passenger” is defined as the programmer that is constantly checking, analyzing, and reviewing the program. It is very important that both partners take turns at being the Driver and the Passenger, even if one partner is substantially more experienced than the other.
Don’t hit your partner.
Nowadays, some of the biggest wastes of time include applications such as Instant Messenger and Facebook. As a lone programmer, it is often tempting to wander off into these massive time-wasters. Using pair programming, each partner is waiting for the other to provide quality input. Both partners motivate each other to stay focused on the project, which leads to greater time efficiency and increased quality.
Put things back where they belong.
Pair programming allows each partner to improve their programming skill. Lone programmers can sometimes fall into a viscous cycle of thinking “I’m a terrible programmer,” and then feeling insecure about every line of code they write. Conversely, lone programmers sometimes think “I’m the best programmer ever. There’s no way I could make a mistake. I don’t need a partner.” In both situations, these thoughts should be garbage collected, as both partners should openly discuss the design of the code and provide helpful feedback in checking each others work.
Clean up your mess.
Pair programming makes it easier to detect errors in coding that are often made and unchecked in lone programming. If left unchecked, these sometimes simple, but hard-to-find, errors build up and can cause lone programmers to alter working parts of the program, causing even more errors.
Don’t take things too seriously.
In order to be effective pair programmers, each partner must find the optimal balance between too much and too little ego. An excess ego prevents programmers from considering the ideas of others. It also causes programmers to overreact to criticism, even leading to mistrust of their own partner. On the other hand, pair programmers should avoid constantly agreeing with each other in order to avoid tension. A healthy amount of debate should occur when discussing the design ideas of the project.
Say you’re sorry when you hurt somebody while moving furniture.
Effective pair programmers should sit side-by-side so that both partners can see the computer screen and share the mouse and keyboard. Only one computer should be between the pair of partners.
Wash your hands of skepticism before you start.
Some programmers are skeptical of the benefits that pair programming could potentially offer. Skeptical programmers leave the door open for inefficient or lack of collaboration and even tension between the partners. The pair programming experience will be greatly beneficial for both partners as long as both are have an open mind towards success and are willing to help each other attain that success.
Flush.
Some pair programmers may decide to spend some time programming alone. Ultimately, both partners should meet to review and incorporate their independent work into the final project. In the past, Extreme Programmers have decided to flush and rewrite any code written alone. In the aforementioned Chrysler Comprehensive Compensation project, a lone programmer was the cause of the only defects through unit and functional testing.
Warm cookies and cold milk are good for you.
Periodic breaks are recommended in order to maintain efficient pair programming. As much as some would like to believe, we are not machines. So, take five minutes to go approve that friend request on Facebook while eating those warm cookies and drinking that cold milk!
Live a balanced life – learn some and think some and draw and paint and sing and dance and play and work every day some.
Although computer scientists would rather be left alone to finish their algorithms, some communication, even in the form of informal discussions, has proven to be beneficial. Communication is pertinent for effective exchange of ideas and transferring of information. In pair programming, the nearest person to communicate with should be no more than three feet away!
Take a break from working together every afternoon.
It is acceptable and can even be beneficial to work alone 10-50% of the time. This lone programming time may be used for experimentation or rote coding in order to increase effective pair programming.
When you go out into the world, watch out for traffic, hold hands and stick together.
The partners in pair programming should not feel that they are in competition with each other. They should support and trust each other. When one fails, the other also fails. When one succeeds, the other also succeeds.
Be aware of the power of two brains.
Since humans are only capable of a limited amount of knowledge, it will be beneficial to share our knowledge and skills with each other. Experience has shown that two brains working together have come up with more than twice as many possible solutions than two brains working alone.
Written by Anh-Khoi Dang
