PairProgramming

UserPreferences

Pair Programming is:

• Two developers writing code at one terminal.
• Pair design.
• Continuous inspection.
• Cross training:
• Experience with product.
• Experience with technology.
• Experience with XP.
• Pair-pressure -- adhere to standards
• Communication

Much of the benefit from pair programming actually comes from pair-designing.

"Pair-pressure" is not allowing the pair to skip the unit testing, continuous integration, simple design and refactoring practices.

"Problems with projects often can invariably be traced back to somebody not talking to somebody else about something important." Beck

These two programmers are NOT thinking on the same level:

• One is thinking about the syntax of the line he is typing in.
• The other is thinking about design, refactoring needed here, refactoring needed elsewhere, test cases needed, test data needed, bugs being introduced by the other guy, etc. He may also be keeping method signatures and member variable names in his head to supply when the other guy is ready for them.

Switch who has the keyboard very often. If you are getting bored, then you aren't pair programming: Grab the keyboard, ask a question, do some of the thinking mentioned above, or stop sitting there.

Pair programming is not sitting beside someone else for 8 hours per day. There are a lot of tasks that don't require pairing, such as debugging. You've got to just sit and think sometimes, and you can't do that with a pair hanging around.

DO YOUR PREP WORK before setting down to pair.

If code reviews / inspections is a "best practice", then why don't people do it?

• formal inspections are boring, time-consuming, not cost effective
• informal review are boring, time-consuming, not cost effective
• PairProgramming is:
• scary
• hard to believe
• exhausting
• PairProgramming requires:
• good breath
• good team
• good personalities

How is it any different if done "eXtreme"?

• all production code is written in pairs
• continuous inspection
• continuous cross-training
• all designs are done in groups of 2 or more
• no roles like DBA, QA, GUI, Install, I18N?
• may still need to call on specialist from time to time?
• switch pairs frequently ( n times per day)

What other practices support this practice?

• CommonVocabulary helps pairs communicate, especially with naming and design
• SustainablePace (pair programming is exhausting, we need to be well rested)
• SimpleDesign means more understandable code, means more fun
• UnitTesting aligns our understanding of the problem and the design
• UnitTesting makes pairing more fun
• Refactoring makes pairing more fun?
• CollectiveOwnership makes pairing easier and faster
• more programmers know more of the code
• CodingStandards prevents arguments

What other practices are supported by this one?

• improves estimation accuracy for ThePlanningGame
• gives you confidence that it is SimpleDesign, not Stupid Design
• gives us courage and encouragement for Refactoring, and makes it safe
• encourages good UnitTesting
• makes CollectiveOwnership effective (spreads knowledge)
• makes ContinuousIntegration safe and decreases by half the number of streams to integrate
• encourages adherence of CodingStandards

How do I get started?

• find a pair willing to give it a try (for more than one month or 3 iterations)
• (it takes a while to get used to it; then, it takes a while to notice the benefit from it)
• Facilities: good table, good location, no phone, fast computer, big monitor, etc.
• see http://www.pairprogramming.com/

Next: CollectiveOwnership

Pair Programming tends to be a controversial topic around ISS. My suggestion is to just try it for 3 or 4 iterations with different partners and then decide if you like it or not. Opinion is no substitute for experience.

-- GregHouston - 03 May 2001