We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 11
Pair Programming: Collaborative
Coding for Efficiency and Quality
According to Nissim Hadar (1996) -■ I was leading a team of 4 programmers working on flight simulator in 1996. Each programmer was assigned a separate aircraft system. ■ The programmers came to me and told me that, as they were always helping each other (this was FORTRAN on a weird system...), they wanted to work in pairs on each system. * This seemed inefficient to me at the beginning, but the big improvement came when the weaker programmers improved within a short time and there were fewer bugs in the fixed time we had for the project What is Pair Programming?
• A software development technique where two
developers work together at one computer. • One person (Driver) writes the code, while the other (Navigator) reviews the code and thinks strategically. • The driver codes, the navigator is reading, checking, spell-checking and sanity testing the code, whilst thinking through problems and where to go next. Real-time peer review. Benefits of Pair Programming • • Improved Code Quality: Continuous review by Navigator. • • Knowledge Sharing: Both programmers learn from each other. • • Faster Problem Solving: Two minds can solve issues faster. • • Better Team Communication: Promotes active collaboration and discussion. Roles in Pair Programming • • Driver: Writes code, focuses on the task at hand. • • Navigator: Reviews the code, thinks about the big picture, and suggests improvements. • • Role Switching: Programmers regularly switch roles to enhance learning. When to Use Pair Programming? • • Complex or Critical Tasks: Ensures higher code quality. • • Onboarding New Team Members: Great way to teach and integrate new programmers. • • Tackling Bugs or Debugging: Two perspectives help identify issues faster. Why it works? • Two people have differing specialities, these skills are transferred.- "everybody has some expertise, some knowledge or ideas that are worth sharing.“ • Ad-hoc training occurs as one person shows the other some tricks and techniques, nice workarounds, etc. • Both developers are fully aware of the code, how it works, and why it was done that way. Why it works?
• Chances are the code is better than one
developer working alone, as there was somebody watching. • The code got written quicker and didn't require revisiting. And when it did need to change, more than one person was familiar with the code. • Continuous Code Review Benefits • Good for learning and training - Deeper understanding of why, how and what was done • Better Quality -Fewer bugs -Instant validation of ideas -Adherence to team conventions • Increased productivity -Fewer interruptions better focus -Pushing each other and motivating to achieve best results -Less procrastination and wasting of time • Improved morale -Greater confidence that their work is correct. • Better discipline and time management -Less likely to skip writing unit tests, spend time web-surfing or on personal email Challenges • To get the buy-in on doing pair programming from Management - Understand the benefits and cost • Everyone has to WANT to pair - They all at least need to be curious enough about it to give it a with the attitude of illustrating genuine shot - attempting pairing with it doesn't work will certain certainly show that it doesn't twork. • Environment - The developers need to be side by side, the same distance from the monitor (which needs to be large).* You might need more chairs. • Personal Preferences -Hygiene can be a serious problem.