$30 off During Our Annual Pro Sale. View Details »

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. 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