Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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
Tweet

More Decks by Nick McCurdy

Other Decks in Programming

Transcript

  1. • 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?
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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
  13. 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.