Extreme Programming Explained

While I've been sitting on this for a little while, chromatic has been patient. Yes, it's his review of Kent Beck's Extreme Programming Explained. The publisher is Addison-Wesley, and the book is for all those people out there who need to do programming but don't have time to do the engineering phase. Interesting book - click thru to read more.

Extreme Programming Explained
author	Kent Beck
pages	179
publisher	Addison Wesley, 09/1999
rating	7/10
reviewer	chromatic
ISBN	0201616416
summary	Extreme Programming Explained explains the virtues of the Extreme Programmer and shows you how to develop them.

The Hook

Want to write better code? How about working less overtime, getting along with your team better, meeting customer demands more quickly and accurately, spending less money, and having more fun?

Extreme Programming may be for you.

Be prepared to make some adjustments and sacrifices. Individual code ownership? Gone. Programming for the future? Slow down, cowboy. Working on your own? Grab a partner and dance.

What's the Scoop?

Extreme Programming is a way to improve software development by focusing on what really matters. If it will cost you $50,000 to implement a feature now that may not be used for two years, and it will cost you $55,000 to implement it in two years, hold off. If running test suites is good, write tests for every significant piece of the system. If multiple pairs of eyes make bugs shallower, program in pairs. If you enjoy meeting deadlines (and not working your fingers to the bone every night for weeks to do so), make shorter deadlines.

It sounds simple, even deceptively so. It may also set your teeth on edge at first.

Imagine that your customer has the time and the manpower to send a representative to sit with your programming team. He is actively involved in the design, writing 'stories' about how the system works for the end users. Every morning and afternoon, your programmers meet to decide which tasks to tackle, and they pair off, sharing one computer between them. One person codes and the other watches, and they switch off as necessary.

With every change to the system, the previous tests are rerun until they work perfectly, and new tests are added to test new functionality. Changes are not commited until all tests run successfully.

Releases are started early (six months, for a big programming project) and continue quickly after that (every couple of months). With a customer sitting in with the programmers, feedback can be instantaneous. The initial investment pays off quickly, while expenses are spread out over a greater period of time.

With no one owning a particular section of code, and with everyone working with different partners from day to day, everyone should have a good overview of the system as a whole. This can lead to better programming, from less bugs to very quick refactoring. New programmers can also be brought in and up to speed much more quickly.

What's to Like?

The book is clear and readable -- even funny. Chapters are short and to the point. Beck uses the metaphor of driving to bring his point across. (Driving is not about pointing in the right direction and maintaining that course, it's about making slight corrections all of the time.)

The bibliography is a great place to find some classic works (including books by Brooks and Knuth and even the movie 'The Princess Bride' -- no, really!).

Extreme Programming itself has a lot of promise. Some of the principles (programming for today, releasing early and often, peer review, community code ownership) fit in pretty well with open source/free software. Some of the other ones would be nice to see....

What Might Annoy You?

It's not clear where Extreme Programming fails. To the author's credit, he mentions this and gives some guidelines, but the choice and the implementation ultimately rest with the managers and bean counters. There will be some resistance at first, but Beck's enthusiasm is infectious and his clarity of explanation might be enough to overcome it.

The Wrapup

If you're a member of or a manager of a moderate programming team, you ought to read this book. It will go nicely on the shelf next to "The Mythical-Man Month". If you're curious about new ways to look at programming (especially in a group), you'll want to pick it up.

Purchase this book at fatbrain.

Table of Contents

1. The Problem
   1. Risk: The Basic Problem
   2. A Development Episode
   3. Economics of Software Development
   4. Four Variables
   5. Cost of Change
   6. Learning to Drive
   7. Four Values
   8. Basic Principles
   9. Back to Basics
2. The Solution
   1. Quick Overview
   2. How Could This Work?
   3. Management Strategy
   4. Facilities Strategy
   5. Splitting Business and Technical Responsibility
   6. Planning Strategy
   7. Development Strategy
   8. Design Strategy
   9. Testing Strategy
3. Implementing XP
   1. Adopting XP
   2. Retrofitting XP
   3. Lifecycle of an Ideal XP Project
   4. Roles for People
   5. 20-80 Rule
   6. What Makes XP Hard
   7. When You Shouldn't Try XP
   8. XP at Work
   9. Conclusion