






Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Pair programming is a software development technique where two programmers work together on the same project, with one acting as the driver and the other as the navigator. This approach offers numerous benefits, including overcoming difficult problems, decreased management risk, fewer interruptions, improved morale, and teaching and sharing knowledge. In pair programming, the drivers make all the changes to the program while the navigators observe, spot problems, and offer suggestions. They take turns at the keyboard and communicate constantly. The benefits and mechanics of pair programming, including different pairing styles and steps in the process.
Typology: Slides
1 / 12
This page cannot be seen from the preview
Don't miss anything!







PRESENTED BY- PRAWESH DHUNGANA
(^) Overcoming difficult problems. (^) Decreased management risk. (^) Fewer interruption. (^) Improved morale. (^) Teaching and sharing knowledge.
(^) In PP, two programmers must always work together in a system. THE DRIVER : (^) One programmer is the "driver": that person is at the keyboard, and is in charge of all changes made to the program. THE NAVIGATOR or OBSERVER (^) Sitting next to the driver is the "navigator", who observes all the code that is entered, spotting problems, thinking of simplifications, helping with programming style, debugging errors, inventing/verifying tests, and generally helping with the problem solving needed to write programs.
(^) Both programmers work closely together, chatting the whole time, jotting down reminders of things to do, and pointing out pieces of code on the screen. (^) Programmers take turns at the keyboard, usually swapping over with a phrase like, "No, let me show you what I mean.“
As a driver you should: (^) Think out loud: “When I solve this with A now I won’t have to refactor B before I can see if it works” “I’m running the test before fixing the properties file, we can do that later” (^) Voice your expectations: “This test is going to pass now” “This should give me three invocations on this mock because I’ve simplified x” (^) Ask the obvious: “What’s next, ah yes we still need to fix that properties file” “Can we commit like this?” (^) Give a heads up: “When we have done this we’ll see some trouble in module A, we need to fix that too”. And then trust your navigator to worry about it while you get there as fast as you can.
As a navigator you should: (^) Follow the storyline and stop the driver if it doesn’t make sense (^) Actively confirm or reject assumptions (^) Ask for arguments if a driver takes a non obvious solution: “Why are you doing that, if we change this property it already works, right?” (^) Look for the nearest exit: “If you fix that test now we can do a commit first, the build will be green” (^) Think ahead: If the driver gives you a heads up, he might not see a dead end. Think it through for a few seconds and then tell him if you don’t think you’re heading to a solution. (^) Find a way out before you get blocked.
Benefits of pair programming: (^) Fewer Mistakes and Bug Hold Ups (^) Harder to Procrastinate (^) Shared Best Practices (^) Faster On-Boarding (^) Identify and Reduce Bad Hires (^) Increase Employee Satisfaction (^) Reduces debugging cost and time.
(^) Stuart Wray: “How does pair programming work?” published on:18 August 2009 and published by: IEEE and available on: https://ieeexplore.ieee.org/ (^) Sam Harris: an article on pair programming available on: https://medium.freecodecamp.org/ (^) https://en.wikipedia.org/wiki/Pair_programming