- 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 prepared to apply constant small adjustments to the direction, brake and
accelerator as you go along to make sure you stay on the road. Additionally, you better be
prepared 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 importance of testing, refactoring, pair programming and short release cycles is
stressed throughout the book, as is keeping a constant dialog with the customer. Also
covered is how to manage an XP team, as well as the various “specialist” roles (coach,
tracker, tester, etc) within the team itself.
One feeling I am left with 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.