- Author: Kent Beck
- ISBN: 0-201-61641-6
Software development projects can be fun, productive, and even daring. Yet they can consistently deliver value to a business and remain under control.
The book consists of three main parts made up of 27 chapters, all crammed into 166 pages (not counting the glossary and index). The first part explains the problem with current software development practices. The second part covers how Extreme Programming (XP) provides a solution to the problem. The third part covers how your team can make the switch to XP.
Beck uses the act of driving a car as a metaphor for the XP software development process. Carefully pointing a car in the right direction, locking the steering wheel in a death-grip and flooring the accelerator is seldom a good way of getting from A to B. Sure, you must have the "big picture" idea of where you're going and how to get there; but you should be ready to apply constant small adjustments to the direction, brake, and accelerator as you go along to make sure you stay on the road. Additionally, prepare to ask for directions unless you know exactly where you're going.
One concept introduced early on is the four variables of a software development project: cost, time, quality and scope. To successfully develop a high-quality project on time and to budget, external forces (customers and managers) get to decide the value of any three of these variables and the development team gets to decide the value of the fourth. Beck explains how quality and time tends to suffer when external forces get to pick the value of all the four variables, leaving you with crappy software behind schedule.
The book stresses the importance of testing, refactoring, pair programming, and short release cycles throughout; as well as keeping a constant dialogue with the customer. Also covered is how to manage an XP team, as well as the "specialist" roles (coach, tracker, tester, etc) within the team itself.
One feeling left after reading this book is that the term Extreme Programming is a terrible misfit. The term, at least to me, conjures up an image of tireless programmers holed up in a cave of computers programming hard & fast for 36 hours a day. However, this is not at all an accurate image. In my opinion, the processes and concepts described in this book are better described as Extremely Sensible Programming. Hardly as catchy though.
Should you read this book? Yes, I think so.