Extreme Programming Installed Ch 1-3

Reference Information

Title: Extreme Programming Installed

Authors: Ron Jeffries, Ann Anderson, Chet Hendrickson

Publisher: Addison-Wesley Professional, October 2000

Summary

The first chapter, "Extreme Programming," discussed the basics of the extreme programming approach to project design. Extreme programming is described as "the discipline of software development with values of simplicity, communication, feedback, and courage." The chapter describes the role of various participants in the software development, including the customer (whose job is to choose what is needed to produce business value, builds stories, and specifies acceptance tests), the programmer (whose job is to estimate difficulty, design, test, program, and integrate the system), and the manager (whose job is to bring the customer and programmer together and to keep the process running smoothly). The rights of each participant are then spelled out, including such things as the right to produce quality work or to see progression.

The second chapter, "The Circle of Life," outlines the project flow process using Extreme Programming, in which the customer defines what has value and the programmers build it.

An example of the project life cycle. Source: Extreme Programming Installed.

Chapter three defines the role of the customer more definitively, arguing that the customer should be on-site full-time, in order to have more effective conversations with the programmers, leading to more satisfaction for the customer. If the customer cannot be present, someone should be there to represent them, they should be there for planning meetings, and code should be released frequently.

Discussion

Extreme Programming seems like a good idea for software development, making sure conditions are right to have high-quality, working products. For example, with paired programming, programmers have the chance to easily discuss problems with someone, and the two programmers can collaborate together to create better code than one person could have. However, this is highly inefficient. When put together, people are prone to distracting each other or conflicting with each other, leading to the result that paired programming would make programming take much longer than it would with the two people working individually. And while having an on-site customer would alleviate many problems and could lead to a highly useful product, it is very inconvenient. Most customers just want to hire someone to create a product, then leave them to it. The customer may have to lose out on valuable work time while being present on-site, making this idea a good one, but an impractical one.