If you changed the environment in which someone works then they change the way in which they work. That is in human nature.

To give a non-IT world example, drivers give cyclists who don't wear helmets a wider berth resulting is fewer cyclist/motor vehicle incidents. However if an incident does occur then its much more likely to go badly wrong for the cyclist.

Anyone recall the jokes about Volvo drivers being the worst in the world! Their cars were so damn safe they thought they were immortal!

I don't think anyone is advocating putting an artificial constraint on programmers but I do think pair programming is much more likely to yield better quality coding.

Incidentally I did ask a very experienced technical lead developer what his experience was with pair programming. His take was as follows: -

• Initially it slows everyone down
• 80% of the work is done by 20% of the staff. Pair programming can have a dramatic negative affect on team performance as it inevitable (and desirable) to pair an 80percenter with a 20 percenter
• Once it beds in the weaker developers get an accelerated learning experience from the better ones leading to a much stronger team
• The stronger team results in higher code quality, fewer post implementation hot fixes

The benefits go beyond the immediately apparent.

• If fewer fixes are needed then the development team are available to move on to the next business deliverable
• Providing a quality deliverable is a morale booster for the team
• Business satisfaction increases partly due to the ability to move onto the next deliverable but also without the corrosive effect of small and often minor errors drip-feeding the perception of poor quality