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