Extreme Programming Installed Ch 10-12

Reference Information

Title: Extreme Programming Installed

Author: Ron Jeffries, Ann Anderson, Chet Hendrickson

Editor: Addison-Wesley Professional, October 2000

Summary
Chapter 10 discussed the quick design session, a technique to help programmers move forward with courage. After the story is broken into tasks, the team can proceed to test-first programming, but if more clarification is needed, a quick design session can be held. The session should only be a few minutes long, and involves sketching out the design. The idea is to understand what is about to be done, and how to implement or change the processes involved in order to achieve the task at hand.

The next chapter discussed how programming should go about being done in Extreme Programming. Paired programming is established, and each pair works on one task at a time. After completing each task, it is integrated with the existing software, all unit tests are run, then the tests and code are released into the repository to complete continuous integration. In addition, collective code ownership occurs, where code is shared and owned by all so that anyone can easily make changes to whatever they might need changed. Simple design is used when programming, and refactoring occurs often such that code is always kept simple. Finally, a coding standard must be established so that everyone's collaborative code is similar.

Chapter 12 discussed paired programming in detail, where the person programming is the "driver" and the person observing and  keeping track of things the driver can't keep track of is the "partner". The partner makes sure the driver's strategy is consistent, and the driver makes sure the partner is actively engaged. They each switch roles every once and a while. The idea is that through paired programming, better code can be generated faster.


Discussion
I like the practices put forward for programmers, such as sticking to a coding standard (ugly code gets really annoying to look at!) and having continuous integration. However, I feel that some of the ideas would just be confusing or time-consuming in practice. For example, collective code ownership is great in theory, but what if someone misunderstands how someone else's code is working, modifies it with that misunderstanding, and then either breaks the code piece they changed, or breaks many other classes because of it. It seems like it could become a major issue if that happened. Also, paired programming just seems like it would waste more time than it would gain. There are many people that when put with others, tend to just talk or get distracted, which would lead to the programmer being distracted, thus accomplishing nothing. Also, if one of the people doesn't understand what's going on, the other one would spend most of their time explaining it instead of getting work done. I do see the benefits though, where one programmer can catch the other's mistake and such, but many computer scientists just prefer to work alone.

A comic mocking the potential distractions pair programming offers. Source: agilegamedevelopment.com