Pair review process - It should be better than pair programming

I am a supporter of XP process with unit test, TDD etc practices without pair programming. I learned the XP practices last year, reading many articles with statistical data about the benefits of pair programming. I used to believe the pair programming is the good way to improve code quality, share knowledge and senior developers can teach junior guy via pair programming but I changed my mind recently. There are some reasons I think that it is hard to apply pair programming in practice (at least in my works and other associates I used to work with):

- The different speed of working among associates. The clever can interfere much the thinking of other and developers are not peer but teacher and student relationship. With teacher-student relationship, it takes time for senior to work the same workspace with less mature one and we have other types of training instead of pair programming.

- Pair programming should not applied in ‘political’ or unfriendly environment. People tends to protect themselves and try not show their weakness to others.

- Some people just like to work lonely. They do not like any involve during they code until their works are finished.

- We do not need two guys do for simple works.

- Sometimes people need relax, other member will force them work while they are tire. There are some guys can work without relax within 4 hours but others need, the different focus level in work can cause people tire and protect against pair programming.

With above reasons, I do not see pair programming can be applied to many teams especially the big team because they are many tyles of working, any fail in one pair can impact to others. However, without any close cooperation among developers than current, it also cause issue about quality and knowledge management, the result is clear: code is not reviewed well (code review session is not effective because people only select random source file for code review in meeting), people can not share knowledge of coding and works etc. The simple thing we can improve our works to full code review to all source codes, two people understand the same code base is performing the peer review regularly. Instead dividing into pairs for coding, we let pairs do review only, one will code and other will review their works at the end of day.

Pair review should be performed every day because when some pair leave works not reviewed daily basics, they tend to select random files for review only when managers request and the effectiveness is not much. Review other works in daily basic will take much time at the beginning, but it takes more speed in future when people is aware with other’s source code, business domain. We also sure each line of source code are ‘done’ by pair (one code and one do inspection), if there is any conflicts in pair, the technical lead will join to solve the issue. One drawback of pair review with pair programming is the response time for fixing defects, pair programming do faster but I believe the benefits of pair review is worth for pair and it overcomes the limitations of pair programming to make it can be applied more wider area.