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.
● 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?
● Writes code, focusing on his/her strategy for solving a
● Asks the navigator for help when needed.
● Sits at the computer with a keyboard and mouse.
● Sits next to the driver, reading his/her code as he/she
● 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
● In some cases, the navigator may also have a keyboard
What is the purpose of pair
● 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
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.
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
● 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
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.
Benefits: Building Work
● 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
What makes a programming
● 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.
● It takes time for developers to get used to working in
● 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
● The navigator spends time helping the driver instead of
working on code separately.
● 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.
● Pair programming can be a very powerful and
productive work relationship.
● Being an effective pair programmer is a skill that must
● 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
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.
No Machete Juggling. N.p., 21 Feb. 2009. Web. 27 Mar.
Wells, Don. "Pair Programming." Extreme Programming: A
Introduction. N.p., 1999. Web. 01 Apr. 2013.