Pair Programming

This is not a joke. Two developers should look at the code at the same time. There is one driver role and one observer role. Driver writes and observer observes the code.
One of them can not touch the code if other does not exist.
Driver and observer role have to be changed in a day. (This will produce more readable code.)

Pair Programming is a XP discipline.
It should be handled in 3 ways.

1) Motivation to this discipline
2) Source Usage
3) Result

I talk with one of the managers of Avrupa YAZILIM which uses XP in their software development process.
He said that, at the beginning, it is hard to motivate our developers to concentrate on pair programming.
And after 5 or 6 months, they feel very comfortable with working in pairs such that they are jocking as i can't write without my pair :)

When you look at source usage you can say that one task is done by two employees and this removes quality of source usage.
It has been proven that: if we say solution of defect on development process has cost 1 unit of job, defect catched on test results with 3 units of cost,
(since tester will loose time to catch this defect, and after you fix she will again test it, and you will debug to find errored line) defect that is catched on production results with 40 units of job. Operation, loosen prestige of company, customer, reverse test process, redevelopment, loose of courage , etc ..

In Pair Programming it is harder to make error, since both of your developers should make same error in the same time. This is really hard if pair programming is applied well.

How to apply Pair Programming well? :)

ok , Both of your employees in a pair should be in same level.
If you are thinking as "this is experienced developer and we should put an in-experienced one next to him." You lack of everything. You don't understand what xp is?
XP does not aim to grow people, It only and only aims to finish the goal. Need will be succeed as the customer requires in that time. Not more, not less. Simple.

Therefore if you have in-experienced pair they should be given more usual, straightforward tasks.

I haven't got published article on that but, it is said that, while one developers productivity and performance is %40 with pair programming it rises up to %115 ..
This brilliant note given to me by XP manager.


XP pairs should be changed. But this change should be consistent with the level of employees. One ten year programmer, cannot write program with the one, starts his work life yesterday.

Immediate reasons :
1)New guy will slow old guy.
2)Old guy will fly on code, new guy does not understand anything.
3)New guy will not have the capacity to debug and correct the old guys errors
4)New guy (Source), w,ll be garbage and cannot take the driver role from old guy.
5)Old guy will have one more role, Teach to new comer what he does...
...
..

Pairs will change among the project life cycle , this change will force Collective Code Ownership. Information Change.

Note: I know you are asking how new one learn?

Don't forget. I wrote this in my previous posts.
XP should not be mixed with agile strategies.
XP is special method and it needs special requirements.

Stess , Tension , Limeted time , un-determined customer needs, changing requirements.
These conditions are the ones what XP wants.
If you have straightforward stuff you do not need to apply XP and don't apply it :)
Then you can grow your guy :)