Extreme Programming Installed Ch. 10-12

Extreme programming installed
Chapters 10-12
Ron Jefferies, Ann Andreson, Chet Hendrickson
 Editors: ?

 Summary:
In chapter 10 the authors disuss quick design sessions. In these sessions the programming team meets to come up with a design for tasks that they are unsure how to implement. Ideally, the team should be able to think of a design within 30 minutes and use that design to begin coding the task. A quick design session should utilize all of the programming team member's skills to come up with a solution.

In chapter 11 the authors discuss aspects of the programming phase. In extreme programming all coding should be done in pairs, with one programmer doing the actual coding and another team member watching and providing input. Extreme programming also requires the pair to write unit tests before they begin and coding on the task. This allows the pair to assure the validity of their code before they commit it to the repository for the rest of the programming team to use. According to the authors, no programming team member should assume ownership of any piece of code. Any team member should be free to modify any line of code from anywhere in the project. This encourages team members to understand the system as a whole, rather than just learning the individual tasks that they are assigned. In order to facilitate the team's collective understanding of the system, a coding standard should be established. The coding standard should address aspects of the code including commenting, capitalization, indentation, naming conventions, and so on. Commenting should not be used to explain poorly written code, rather the code should be self explanatory and easy to follow, using comments only for special cases.

Chapter 12 returns to the idea of pair programming and discusses it in detail. The idea behind pair programming is that it produces better code than is produced by two people individually writing code. Pair programming also has the added benefit of furthering the team's collective knowledge of the system since both of the team members participating in pair programming will understand the piece of code that they are coding. The team member not writing the code, the partner, is tasked with spotting errors and  giving ideas and feedback to the driver, the team member that is writing the code. The driver needs to accept feedback and actively engage with the partner in order for both members to be actively engaged in the coding process. The authors also suggest that the partner and driver switch places occasionally in order for both members to remain interested in the project.

Discussion:
The main part that I find interesting about this reading is the idea of pair programming. I have used pair programming before at work and I can attest to its usefulness. Hearing more about the advantages that it can bring makes me wish that more team projects at A&M encouraged the use of pair programming. This reading does not have any faults, however I would have liked to see more about the quick design session discussed in chapter 10. This reading can be applied to our project in capstone. Right now the team is very divided on what tasks they are assigned, which will most likely result in team members becoming the resident expert on a particular topic. If we were to use pair programming it would allow more team members to understand different aspects of the project.