Slide 1

Slide 1 text

Pair Programming Nicolas McCurdy

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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.

Slide 4

Slide 4 text

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.

Slide 5

Slide 5 text

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.

Slide 6

Slide 6 text

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.

Slide 7

Slide 7 text

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.

Slide 8

Slide 8 text

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.

Slide 9

Slide 9 text

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.

Slide 10

Slide 10 text

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.

Slide 11

Slide 11 text

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.

Slide 12

Slide 12 text

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.

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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.