Extreme Programming Explained: Embrace Change (Paperback)

by Kent Beck (Author)

Editorial Reviews

Amazon.com Review
Kent Beck's eXtreme Programming eXplained provides an intriguing high-level overview of the author's Extreme Programming (XP) software development methodology. Written for IS managers, project leaders, or programmers, this guide provides a glimpse at the principles behind XP and its potential advantages for small- to mid-size software development teams.

The book intends to describe what XP is, its guiding principles, and how it works. Simply written, the book avoids case studies and concrete details in demonstrating the efficacy of XP. Instead, it demonstrates how XP relies on simplicity, unit testing, programming in pairs, communal ownership of code, and customer input on software to motivate code improvement during the development process. As the author notes, these principles are not new, but when they're combined their synergy fosters a new and arguably better way to build and maintain software. Throughout the book, the author presents and explains these principles, such as "rapid feedback" and "play to win," which form the basis of XP.

Generally speaking, XP changes the way programmers work. The book is good at delineating new roles for programmers and managers who Beck calls "coaches." The most striking characteristic of XP is that programmers work in pairs, and that testing is an intrinsic part of the coding process. In a later section, the author even shows where XP works and where it doesn't and offers suggestions for migrating teams and organizations over to the XP process.

In the afterword, the author recounts the experiences that led him to develop and refine XP, an insightful section that should inspire any organization to adopt XP. This book serves as a useful introduction to the philosophy and practice of XP for the manager or programmer who wants a potentially better way to build software. --Richard Dragan

Topics covered: Extreme Programming (XP) software methodology, principles, XP team roles, facilities design, testing, refactoring, the XP software lifecycle, and adopting XP.

Product Description
Software development projects can be fun, productive, and even daring. Yet they can consistently deliver value to a business and remain under control.

Extreme Programming (XP) was conceived and developed to address the specific needs of software development conducted by small teams in the face of vague and changing requirements. This new lightweight methodology challenges many conventional tenets, including the long-held assumption that the cost of changing a piece of software necessarily rises dramatically over the course of time. XP recognizes that projects have to work to achieve this reduction in cost and exploit the savings once they have been earned.

Fundamentals of XP include:

* Distinguishing between the decisions to be made by business interests and those to be made by project stakeholders. * Writing unit tests before programming and keeping all of the tests running at all times. * Integrating and testing the whole system-several times a day. * Producing all software in pairs, two programmers at one screen. * Starting projects with a simple design that constantly evolves to add needed flexibility and remove unneeded complexity. * Putting a minimal system into production quickly and growing it in whatever directions prove most valuable.

Why is XP so controversial? Some sacred cows don't make the cut in XP:

* Don't force team members to specialize and become analysts, architects, programmers, testers, and integrators-every XP programmer participates in all of these critical activities every day. * Don't conduct complete up-front analysis and design-an XP project starts with a quick analysis of the entire system, and XP programmers continue to make analysis and design decisions throughout development. * Develop infrastructure and frameworks as you develop your application, not up-front-delivering business value is the heartbeat that drives XP projects. * Don't write and maintain implementation documentation-communication in XP projects occurs face-to-face, or through efficient tests and carefully written code.

You may love XP or you may hate it, but Extreme Programming Explained will force you to take a fresh look at how you develop software.

See all Editorial Reviews

Product Details

• Paperback: 224 pages
• Publisher: Addison-Wesley Professional; US ed edition (October 5, 1999)
• Language: English
• ISBN-10: 0201616416
• ISBN-13: 978-0201616415
• Product Dimensions: 9.1 x 7.4 x 0.4 inches
• Shipping Weight: 12.2 ounces
• Average Customer Review: 4.0 out of 5 stars See all reviews (126 customer reviews)
• Amazon.com Sales Rank: #525,810 in Books (See Bestsellers in Books)

Customer Reviews

Most Helpful Customer Reviews

45 of 46 people found the following review helpful:

5.0 out of 5 stars A clear and balanced treatment of XP., November 4, 1999

By A Customer

A few years ago, Nathaniel Borenstein wrote a fine little book called "Programming as if People Mattered", which is mostly about user interface design. It's almost a shame that the title has been used, because it's also an apt description of Kent Beck's new book. This is a development methodology that acknowledges that developers matter, and that customers matter, too. And they matter in both good and bad ways: Extreme Programming acknowledges that people have rights and strengths, but also that they have weaknesses, and it works with those weaknesses rather than against them. This is a welcome contrast to most of the mainstream software methodologies, where only the methodology seems to matter.

Beck and the other Extreme Programming advocates have been in "evangelism mode" of late, and their zeal has occasionally seemed excessive. This book, though, is well-reasoned and balanced. The limitations of XP are freely acknowledged, and Beck argues that in some cases and situations, XP is probably not appropriate. His goal, as the title states, is to explain XP, to help readers understand it so that they can decide whether it's for them. I think he succeeds completely.

For such important material, the book is light and easy to read. It's also short and direct. Spend a day or two reading this book, and then spend a week or two thinking about its recommendations in light of your current project. You owe it to all of the people associated with your project who matter.

28 of 29 people found the following review helpful:

5.0 out of 5 stars This book will change the way software is developed, October 29, 1999

By A Customer

This book will challenge your preconceptions about how software should be developed. It is a direct challenge to the old way of software development where we talked about "Freezing Requirements". It asks us to use the power of Object technology to Embrace Change instead.

Extreme Programming is a methodology that allows developers and customers to work together in a synergistic manner. It takes the idea of Incremental and Iterative development and shows how to effectively apply it in the real world to produce business value.

This book explains how small teams of developers can work together using a set of self reinforcing practices that enable great productivity and quality.

It is about time that a developer has written a book that questions the high ceremony, document centric software development methodologies. What we need is a balance between developer friendly practices such as testing your ideas out using code (often derided as "hacking"), and the need a business has of knowing that their investment in the software will pay off. Not all problem domains will benefit from eXtreme Programming, but that is true of any methodology (and at least eXtreme Programming is up front about the need to check if the process is applicable).

To those critics that accuse this book of promoting hacking and ignoring all we have learnt about how to develop software, I suggest that it is time to apply scientific thinking. Try some experiments with your current process, then try some eXtreme Programming experiments and see which give the best results.

In summary, a Great Book, Buy it, Read it, Think about applying the lessons of eXtreme Programming.

20 of 20 people found the following review helpful:

5.0 out of 5 stars A new approach to software development, June 23, 2000

By	Kevin W. Parker (Greenbelt, MD) - See all my reviews (REAL NAME)

This approach to programming was much bandied about and a little controversial at a software engineering conference I recently attended. Beck's premise is to take proven good practices in software development and max them out:

- if code reviews are good, do code reviews constantly by having another programmer look over your shoulder.

- if testing is good, write your test plans first and then test each time you implement another feature

- if integration is good, integrate almost constantly so that the system always works

The underlying premise is that the old, familiar cost curve that says it costs a thousand times as much to fix a mistake in the testing phase as in the requirements phase is no longer accurate: we have much better tools now than when that curve was formulated, we're living in Internet time, and the customers don't know what the heck they want anyway. So we might as well go ahead and try to give them something, then fix it up later, rather than trying to divine their goals now.

The problem I see with this is that there's not much time allowed for doing analysis and design. Beck specifically counsels against trying to anticipate capabilities, but if you know what you're doing, anticipating capabilities can save you a lot of time down the line. (His rejoinder is that it can also cost you a lot of time in implementing and debugging features that don't work and may never be used.) No matter how clever you may be, doing design as you code seems to me to be one cut above the worst sort of hacking.

Still, there are some marvelous ideas in here: pair coding sounds intriguing, writing test plans first is a must-have, and I've always held the position that the system should be constantly integrated, that there should never be a big push at the end to get all the pieces to fit together.

He also has other, related advice: developers should not work overtime for more than one week in a row (that's a way to become less productive, not more), you should have a customer representative onsite with the programming team to answer lesser questions about how to implement capabilities, and so on.

In summary, this book is very worthwhile for anyone who wants to improve their software development practices (and who doesn't have problems with their software development practices?). It's particularly good if you're in an environment where the customer wants a quick response to what they want when they want it even as they're not sure what they want. I wouldn't recommend adopting the approach wholeheartedly and automatically (and neither would Beck), but take what makes sense and go from there. As Beck himself says, figure out where your biggest problem is and adopt XP practices there first.