Drinks & Food
They were just splendid. Thanks to EuropeLoan?.

Talks
- VeraPeeters gave an introductory talk on Pair Programming
- Patrick Steyaert (MediaGeniX) showed the feedback e-mail messages he got from his developers on Pair Programming
- Winston Wolff, (Europe Loan Bank) talked about his experiences with Pair Programming from a managers perspective and raised the question of what are the costs and benefits
- Alain Ravet talked about the people issues in Pair Programming

I made some notes on the different presentations, hopefully they are useful.

Vera Peeters
- Pair Programming (PP) is code review all the time.
- Switch pair roles when necessary (switch keyboard often).
- Rotate pairs often, so everyone is “always” up to date with everything. (this can be discussed in morning stand up meeting).
- PP results in better knowledge distribution.
- The pair programs with combined skills of both people.
- PP increases the truck factor (number of people that have to run under a truck before project is in danger).
- PP makes sure that the team acts as one team with one style one style.

? Do you let people decide themselves with who they can pair: Yes
? How do you make sure there everyone is doing enough driving, thinking (at least switch every half day): The people themselves will notice that
? Is this not only applicable for “easy straightforward” projects ? what to do with people that want to have an important effect on the project (they own the code): They danger the project

- First practice applied within Europeloan when starting with XP was PP
- Not all people like PP.

? What do you do with people that don’t like it. 59 %: They left the project eventually

- From an experiment done by Prof. Williams it shows that pairs had much less LOC for same functionality, which is a good thing. Less LOC, means easier to maintain, less possibility for bugs.

Vera showed some self made, real life pictures from collegues in a Pair Programming session. The results were astonishing, you can find them on this website http://www.xp.be/bexpug/meeting4/pairprogramming/LudovicAndDaniel/

In PP you cannot be lazy

Patrick Steyaert
- His development group contains 15 developers
- it is project oriented
- pair programming was never pushed
- Pushing unit tests, but never everyone should do this
- Pair programming tables – people choose themselves
- Half of the people do pair programming voluntary
- Couple of die hards
- Rotation is the obstacle

Comments from developers
- For repetitive tasks it is an overhead (when is it repetitive)
- Good thing to involve managers into the development
- Don’t put very senior with very junior, or not for very long
- 2 different kinds of junior, ones that can learn fast, others that don’t

- there are no phones on pair programming table

- people hesitate to disturb 2 people instead of one, ..
- you don’t read your mail
- time constraints: it forces people to make agreements about overlapping time, so they automatically start in reasonable hours
- juniors learn a lot from seniors in pair programming

All the actual comments are available on this website
http://www.xp.be/bexpug4presentations/ps/ps.htm

Europe Loan comment: Daniel was doing useful stuff on his first day and up to speed in 2 weeks.

Winston Wolff
Communication is very important (some don’t want to listen)
Programming – dev. environment – releases – business
Also do Pair interviewing and Pair Testing (doing tests in pair)

Is it worth the money?

Not for simple tasks
Not in the short run
But definitely in the long run
- continuous learning,
- quality, reduced bugs, better solutios
- communication

The 2 slides used by Winston in his presentation are available at
http://www.xp.be/bexpug4presentations/ww/ww_files/frame.htm

Alain Ravet
- By the book: sometimes not easy, can be very tiring
- 2 people & differences:
personality, character, habits, smell, …
- 2 it professionals:
smart/less smart, skilled/less skilled, experienced/less exp, junior/senior, you are always good and bad in different topics
- 2 roles:
driver, co driver
- How to avoid:
pair watching, full time pair mentoring, senior frustration, junior, frustration, endless debate, performance loss
- Full day is too much.
You want some real action after a lot of explanation.
Find a balance between high/low speed.
- Synch granularity ?
- incompatible characters

a Type of pairs & risk
- senior/senior
- senior/junior – not too long
- junior/junior – need coach

- In the worst case 2 hours of work once took me 16 hours in pair
- XP is not for everybody

? The junior apparently needs this amount of teaching, is reading a book abou the subject a better solution ? Or is teaching "just enough" (during pair programming) to do the task at hand, a more optimal solution
? Is teaching not an essential job of the senior pairing with a junior

- Coach is needed, partner is not the right person to tell that his partner is not taking the keyboard enough.
- PP is very demanding, break after a few iterations

And also Alain was so kind to provide us with his presentation material
http://www.xp.be/bexpug4presentations/ar/ar_files/frame.htm

My personal comments: I think this evening was very worthwhile. Several interesting issues were raised regarding pair programming. From my personal experience I know it is not easy to find a lot of developers that agree on pair programming right away. I think you need the right people to do XP and especially pair programming. You can go as far as selecting them on the basis of their XP potential (when hiring). Maybe this is an interesting subject for a next meeting, finding out what personality and skills an XP programmer needs. ( DavidGrietens )

Feel free to add your comments/changes to this page