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.

Transcript

1. Pair Programming
   Nicolas McCurdy
   

   View Slide

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?
   

   View Slide

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.
   

   View Slide

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.
   

   View Slide

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.
   

   View Slide

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.
   

   View Slide

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.
   

   View Slide

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.
   

   View Slide

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.
   

   View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

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.
    

    View Slide