- Home
- Introduction
- Values and Principles
- Practices
- Supporting Practices
- Evolving Practices
- Process Cycle
- Pair Programming
- Roles
- Activities and Artifacts
- Rules
- Additional Features
- Scrum + Extreme Programming
- Tools
- Useful Resources
- Quick Guide
- Useful Resources
- Discussion
Extreme Programming - Pair Programming
Pair programming is a style of programming in which two programmers work side-by-side at one computer, sharing one screen, keyboard and mouse, continuously collaborating on the same design, algorithm, code or test.
One programmer, termed as the driver, has control of the keyboard/mouse and actively implements the code or writes a test. The other programmer, termed as the navigator, continuously observes the work of the driver to identify defects and also thinks strategically about the direction of the work.
When necessary, the two programmers brainstorm on any challenging problem. The two programmers periodically switch roles and work together as equals to develop a software.
Pair Programming – Advantages
The significant advantages of Pair Programming are −
Many mistakes are detected at the time they are typed, rather than in QA Testing or in the field.
The end defect content is statistically lower.
The designs are better and code length shorter.
The team solves problems faster.
People learn significantly more about the system and about software development.
The project ends up with multiple people understanding each piece of the system.
People learn to work together and talk more often together, giving better information flow and team dynamics.
People enjoy their work more.
Pair Programming Experiments
Use of pair programming practice has been demonstrated to improve the productivity and quality of software products.
Pair Programming research reveals that −
Pairs use no more man-hours than singles.
Pairs create fewer defects.
Pairs create fewer lines of code.
Pairs enjoy their work more.
University of Utah conducted experiments on pair programming. The results revealed that −
Pairs spent 15% more time on the program than individuals.
Code written by pairs consistently passed more test cases than code written by individuals.
Pairs consistently implemented the same functionality produced by individuals in fewer lines of code.
Learning how to program in an environment where there are rapidly tangible results is fun and allows one to learn faster.
Adapting to Pair Programming
Most programmers are used to solitary work and often resist the transition to pair programming. However, with practice they can ultimately make this transition.
According to Laurie A. Williams and Robert R. Kessler, in their book, ‘All I Really Need to Know about Pair Programming I Learned in Kindergarten’, it is well explained of how to nurture the skills that we all have learnt in Kindergarten to establish team cohesion, in general and pair programming in particular.
The transition and on-going success as a pair programmer often involves practicing everyday civility.
The following sections are an excerpt of this publication that help you in becoming effective pair programmers.
Kindergarten lessons
In Kindergarten, we have learnt the following −
Share everything
Play fair
Do not hit people
Put things back where you found them
Clean up your own mess
Do not take things that are not yours
Say you are sorry when you hurt somebody
Wash your hands before you eat
Flush
Warm cookies and cold milk are good for you
Live a balanced life – learn some and think some and draw and paint and sing and dance and play and work every day some
Take a nap every afternoon
When you go out into the world, watch out for traffic, hold hands and stick together
Be aware of wonder
Next, we look at the principles of Pair Programming in the context of the above given teachings.
Share everything
In pair programming,
Two Programmers sit together and jointly produce one artifact (design, algorithm, code, etc.)
One person is typing or writing, the other is continually reviewing the work. Both
Are equal participants in the process
Responsible for every aspect of the artifact
Own everything
Play fair
In pair programming,
One person drives, i.e. has control of the keyboard or is recording design ideas, while the other is continuously reviewing the work.
They switch these roles periodically, even when one of them is significantly more experienced than the other, to ensure equal participation.
While the person who is driving is thinking about implementation, the other continuously reviews code, thinks about a possible simpler design that is possible, how the current development fits in the overall system as of date.
Do not hit your partner
In pair programming,
Ensure that your partner stays focused and on-task.
You stay focused and on-task.
Ensure your partner follows the prescribed coding standards and thus maintains the commitment to the rest of the team.
In the pair programming survey, it is found that tremendous productivity gains and quality improvements are realized. This is because −
Each one keeps their partner focused and on-task with no possibility of slack off.
Each artifact is reviewed continuously as it is being produced ensuring quality.
Put things back where they belong
In Pair Programming,
You need to believe in your skills and your partner’s skills as well. Any negative thoughts in this aspect are to be put in trash can.
You have to be sure that you express what you know and are open to learn from your partner when required. You can learn from your partner by observing him or taking his feedback instantly.
You need to have the confidence that −
Wherever there is a possibility of lagging, you can immediately pick up from your partner.
Together as a pair, you can solve problems that you could not solve alone.
You can help improve each other’s skills.
Clean up your mess
In Pair Programming, with the ‘watch over the shoulder’ technique,
You will find that it is amazing to know how many obvious but unnoticed defects are noticed by your partner.
You can remove these defects without the natural animosity that might develop in a formal inspection meeting.
Characterizing defect prevention and defect removal efficiency.
Do not take things too seriously
Having a partner to review design and coding continuously and objectively is a very beneficial aspect of pair programming. In pair programming, you need to ensure that you work without excess ego or too little ego.
This is necessary because,
Excess ego can manifest itself in two ways −
Having a “my way or the highway” attitude can prevent the programmer from considering other’s ideas.
Being defensive can cause a programmer not to receive constructive criticism or to view this criticism as mistrust.
Both these ways of ego manifestation damage the collaborative relationship.
On the other hand, a person who always agrees with the partner so as not to create tension also minimizes the benefits of collaborative work. For favorable idea exchange, there should be some healthy disagreement/debate when required.
Thus, a fine balance between displaying too much and too little ego is necessary. Effective pair programmers groom this balance during an initial adjustment period that can take hours or days, depending on the individuals, the nature of work and their past experience with pair programming.
Say you are sorry when you hurt somebody while moving furniture
The programmers must be able to sit side-by-side and program, simultaneously viewing the computer screen and sharing the keyboard and the mouse. Extreme programmers have a “slide the keyboard/don't move the chairs” rule.
To ensure effective communication, both within a collaborative pair and with other collaborative pairs, without much effort, programmers need to see each other, ask each other questions and make decisions on things such as integration issues. Programmers also benefit from overhearing other conversations to which they can have vital contributions.
Disown skepticism before you start
For success of pair programming, it is necessary that both the partners understand the value of collaboration in programming, the benefits, and the joy of the experience. Any skepticism in this regard needs to be stopped in the beginning itself.
Experience has shown that having one programmer, very positive and/or experienced in pair programming, can lead the pair to become one jelled collaborative team victoriously.
The production of such a team is greater than that of the same people working in un-jelled form.
The enjoyment that people derive from their work is greater than what you would expect, given the nature of the work itself.
Once a team begins to jell, the probability of success goes up dramatically.
Flush
The pair programmers can work on something independently. However, when they rejoin, they have to either review the independent work before incorporating it or flush and rewrite the independent work along with continuous review of the work, which identifies additional defects.
Never incorporate any independent work without the review by the partner. This is for the reason that studies have indicated that the independent work has defects as compared to the work produced by the pair.
Warm cookies and cold milk are good for you
Pair programmers keep each other continuously focused and on-task. It can be very intense and mentally exhausting. Hence, periodically take a break to maintain the stamina for another round of productive Pair Programming.
During the break, it is best to disconnect from the task and approach it with a freshness when restarting. Suggested activities are checking email, making a phone call, browsing the web, or taking a Snack-break.
Live a balanced life
Communicating with others on a regular basis is the key for leading a balanced life. Informal discussions with your partner and with other programmers allows exchange of effective ideas and efficient transfer of information.
Take a break from working together every afternoon
It is not necessary to work separately every afternoon, but it is acceptable to work alone 10-50% of the time. This is because −
Many programmers prefer to do experimental prototyping, tough, deep-concentration problems and logical thinking alone.
Simple, well-defined and routine coding is done more efficiently by a solitary programmer and then reviewed with a partner.
Watch out for traffic, hold hands and stick together
In Pair Programming,
There should be no competition between the two. Both must work together as if the artifact is produced by a single mind.
The Partners need to trust each other’s judgement and each other’s loyalty to the team.
A partner should never blame the other partner for any problems or defects.
Be aware of the power of two brains
When two are working together, each has their own set of knowledge and skills, comprising of −
A common set of this knowledge and these skills that enables them to communicate effectively.
Unique skills that allow them to contribute to accomplish their tasks.
Together, a pair will −
Come up with more than twice as many possible solutions than the two would have when working alone.
Proceed more quickly to narrow in on the best solution.
Implement it more quickly and with better quality.
Thus, pair programming is a powerful technique as there are two brains concentrating on the same problem all the time. It forces one to concentrate fully on the problem at hand.