Pair Programming

Pair Programming

An explanation of the pair programming technique for software development, including a discussion of the associated benefits and risks in using it over more conventional programming practices.


Nick McCurdy

April 02, 2013


  1. Pair Programming Nicolas McCurdy

  2. • Two developers work together at one computer. • One

    developer acts as the driver, while the other acts as the navigator. • Developers may occasionally switch positions. • Pair programming is a powerful work relationship that promotes tight teamwork between two developers. • Popular in agile software development teams. What is pair programming?
  3. The Driver • Writes code, focusing on his/her strategy for

    solving a problem. • Asks the navigator for help when needed. • Sits at the computer with a keyboard and mouse.
  4. The Navigator • Sits next to the driver, reading his/her

    code as he/she works. • Helps the driver solve problems when needed and gives him/her constructive criticism. • Acts as the driver’s safety net, checking for issues regarding typos, potential bugs, bad practices, and distractions. • In some cases, the navigator may also have a keyboard and mouse.
  5. What is the purpose of pair programming? • Force developers

    to work very closely to each other and build strong professional relationships. • Improve the quality of code. • Turn pairs of developers into focused and efficient teams.
  6. Benefits: Shared Knowledge • The two programmers can work together

    while using each other’s strengths to their advantage. • When the driver asks for help, the navigator already knows what he/she is working on. • The driver spends less time researching topics he/she does not know. • The navigator can train the driver for specific tasks whenever it is needed.
  7. Benefits: Quality Assurance • The driver does not have to

    worry as much about quality control, since this is the navigator's dedicated role. • The navigator can spot bugs, typos, and alternate solutions that the driver may not have noticed otherwise. • The driver is encouraged to stay focused, stay honest, and follow good practices. • This increased level of quality saves a lot of time from doing additional quality assurance on the produced code.
  8. Benefits: Work Environment • Does not cost much to implement

    (besides work hours). • In larger teams, different pairs can be formed between developers with different skillsets. • When code needs to be revisited, multiple people are familiar with it.
  9. Benefits: Building Work Relationships • Forms a very close level

    of communication by forcing developers to work tightly together. • Helps developers quickly learn from each other while applying their new knowledge immediately. • Increases morale, since developers are not working alone.
  10. What makes a programming pair effective? • They should share

    at least basic skills, though it helps for them to have different specialties. • Effective communication skills. ◦ Frequent constructive feedback. ◦ Can clearly discuss issues without being offensive. • Focus.
  11. Risks • It takes time for developers to get used

    to working in pairs. • Consistency of code quality can be difficult to achieve. • If one developer feels far less comfortable with the technologies he/she is using than the other developer, the pair might turn into a much less effective mentor/student relationship. • The navigator spends time helping the driver instead of working on code separately.
  12. Risks: Communication Issues • Pair programming is a social skill,

    and more introverted developers may not be a good fit. • Because of how often pair programmers need to communicate with one another, ineffective communication can waste time, leave problems unfixed, and cause disputes between developers.
  13. Conclusion • Pair programming can be a very powerful and

    productive work relationship. • Being an effective pair programmer is a skill that must be learned. • The benefits of pair programming overlap with some of the benefits of its alternatives. “If the programmers like each other, they play a game called ‘pair programming’. And if not, then the game is called ‘peer review’.” - Anna Nachesa (@ashalynd) on Twitter
  14. Works Cited Atwood, Jeff. "Pair Programming versus Code Review." Effective

    Programming: More Than Writing Code. San Francisco, California: Hyperink, 2012. N. pag. Print. Hevery, Miško. "What Pair-Programing Is Not." Web log post. Miško Hevery. N.p., 12 June 2009. Web. 27 Mar. 2013. Hilton, Rod. "I Love Pair-Programming." Web log post. Absolutely No Machete Juggling. N.p., 21 Feb. 2009. Web. 27 Mar. 2013. Wells, Don. "Pair Programming." Extreme Programming: A Gentle Introduction. N.p., 1999. Web. 01 Apr. 2013.