Extreme Programming Installed

Pair Programming

Chapter 10: Quick Design Session
Summary
This chapter gives out a tip about making quick design decisions. When the programmer does not know how to implement a particular task, it is recommended that he discusses this with his co-workers for about 10-30 mins (30 mins max). After the discussion, it is time to start coding so that the coding will guide the flow of the development.

Chapter 11: Programming
Summary
The programming chapter of this book talks about the methodologies used to write software in XP. Software is written in pairs and it is integrated several times a day (acquiring the name of continuous integration). Also, the tasks' test are written first and the code of the programmers intend to make sure the tests run at 100% success all the time; this includes tests from other modules. The rest of the chapter discusses certain requirements of XP such as simplicity of code, collective code ownership, adhering to coding standards, and working weeks of 40 hours. Also, the author mentions the principles of refactoring which basically involves improving code previously written.

Chapter 12: Pair Programming
Summary
The concept of pair programming was briefly discussed in the previous chapter. In chapter 12, the author provides some details about the mechanics of this technique. In pair programming, there's a driver and there is a partner. The driver is responsible for coding, while the partner is responsible for making sure the driver is going in the right direction. This can encompass remembering names (variable or methods) for the driver, or simply making sure the code is readable. Towards the end of the chapter the author provides some tips on how to work in pairs.

Discussion
Chapters 10-12 discussed the actual programming part of the XP methodology. Its really interesting that XP encourages (or enforces) pair programming. I always thought that programming was a one-person's job, but I would not be closed minded to the possibility of working in pairs.