Customer Reviews

4.4 out of 5 stars
Extreme Programming Explained: Embrace Change, 2nd Edition (The XP Series)
Format: PaperbackChange
Price:$36.66 + Free shipping with Amazon Prime
Your rating(Clear)Rate this item

There was a problem filtering reviews right now. Please try again later.

22 of 24 people found the following review helpful
on December 23, 2004
The release 1st edition of this book is still considered by many to be the kick start for the growing adoption of a software development process called Extreme Programming. After 5 years, the 2nd edition faces a much different world but also with much different content and approach. The world has learned much and so has the author. I'm glad to see that this 2nd edition reflects that development.

Beck has revised his thinking throughout the book. Some obvious examples include his current preference towards using ideal time over abstract time units in estimating, the fifth value among the initial four, the new set of principles, and the rehash of the practices.

Extreme Programming Explained is not a detailed how-to for adopting the process it describes. Actually, it doesn't really describe a process at all. What it does describe is a system of values and principles and a set of practices to support these. Even though Beck does give each practice (divided into primary and corollary practices in the 2nd edition) their share of explanation, the focus is still strongly on the "what" and "why" instead of the "how".

As someone who has read a dozen books on the topic already, I was delighted to find almost every page to provide something intriguing that either created or challenged my own thoughts. Especially the latter half of the book, dealing with topics such as TOC, scaling, Taylorism, the Toyota Production System, and the hot potato itself -- offshoring -- offered a lot to think about.

This is what a 2nd edition should be like, every single chapter reflecting new insight gathered over the years.
0CommentWas this review helpful to you?YesNoSending feedback...
Thank you for your feedback.
Sorry, we failed to record your vote. Please try again
Report abuse
16 of 17 people found the following review helpful
on August 14, 2005
When I read the first edition several years ago, my first thought was how XP needs a name change. It seems as if Beck said, "Lets take a bunch of common 'best practices', develop a methodology around performing them consistently, and then give it a name that will scare away managers".

XP is not a silver bullet, not is it 'evil'. If you develop software and you work in an environment where you always seem to struggle with issues that prevent your team from operating effectively, then this book is for you. Extreme Programming is about taking several core 'practices' and 'values', and turning that into a methodology - perhaps even a philosophy - of software development, team interaction, and process improvement. I don't care if you end up falling in love with XP or if you end up following RUP, CMMi or some other improvement framework, reading this book is an excellent first start to pull yourself out of the doldrums that most software development shops operate in.

Yes, I am a fan of XP and this book. I think the first edition was better. This book seems to digress a lot into touchy-feely subjects, rather than staying on the subject of software development (for example, there are a few pages about personal relationships in the workplace, including dealing with issues that cross the line into HR management - not appropriate for a book that is supposed to be about XP). Beck also seems to flip-flop between describing XP as a solid methodology and a loose collection of his own ideas. I think that XP would greatly improve if it grew up and formalized itself a little better... XP should not be defined with the primary author's telling of anecdotal stories, as appear in this book.

Read it with a pragmatic eye, and figure out what is relevant to your situation. Trying to apply these (or any) ideas dogmatically will probably solve some issues while creating far worse ones.
0CommentWas this review helpful to you?YesNoSending feedback...
Thank you for your feedback.
Sorry, we failed to record your vote. Please try again
Report abuse
34 of 43 people found the following review helpful
on February 17, 2005
I have been using Agile programming methods for some time, so I decided to find a book to describe the details of Extreme programming. Extreme programming is an important variant of Agile programming so it is worth studying in more detail.

I bought this book with the expectation that it would be a serious description of how to apply extreme programming and how it relates to other methods. No such luck. The book does explain practices and philosophies, but is primarily an emotional pep talk in favor of Extreme programming. This is to much "Zen" for me. And it seems that the pep talks mostly compared it to the trational waterfall model. In this comparison it is no wonder that extreme programming seems so good. But the book gives seriouos indication of why this method is best; as it claims it is.

So overall, it is an adequate book that does fairly good job presenting what extreme programming is all about but it could have been so much better.

Whatever you do, don't read this book as your first book on software engineering. For that purpose I recommend Steve McConell: Rapid Development. Reading books on agile development should happen after that - otherwise it might be hard to see things in the right perspective.
11 commentWas this review helpful to you?YesNoSending feedback...
Thank you for your feedback.
Sorry, we failed to record your vote. Please try again
Report abuse
11 of 13 people found the following review helpful
on March 23, 2005
In Kent Beck's first edition he articulated a manifesto for lightweight methodologies. These methods today are referred to as Agile Methodologies; which Extreme Programming is only one.

The Second Edition builds on the first edition but has a distinctly different tone. In the first book XP was a described as 12 practices that may or may not have been new but the aggregation of the 12 brought together something that as whole changed the way many people wrote software. In this book more emphasis is placed on the whys behind the practices which include values and principals. For example, here is a quote from the book, "Values bring purpose to practices". Kent goes on to say that if he told you to follow practices blindly some people would but most people want to know why you might do a practice. Here is where the values and principals come in to give you the reasoning why a practice is useful. Overall given the renewed emphasis on values, principals, and practices I thought the book itself was much more approachable than the first edition which hopefully will encourage the people who had been on the fence to try out the practices on their next project.
0CommentWas this review helpful to you?YesNoSending feedback...
Thank you for your feedback.
Sorry, we failed to record your vote. Please try again
Report abuse
10 of 12 people found the following review helpful
Whether or not interested in Extreme Programming, a software developer should certainly read this book. As a warning, the book is not a detailed techinal guide of how to apply XP. It's more of a emotional guide of how to better ourselves as being a programmer. This book reminded me that, I am a human who have values and ideals, not just a machine, writing code only to make some money. If you have huge amount of technical knowledge and experience and still feeling something is wrong, this is the book which will enlighten your path.
0CommentWas this review helpful to you?YesNoSending feedback...
Thank you for your feedback.
Sorry, we failed to record your vote. Please try again
Report abuse
8 of 11 people found the following review helpful
on February 19, 2006
This book is a good introduction to different aspects involved in extreme programming.

The author is the initial proponent of XP. First part of the book explains the present day software development realities(like deadlines etc) and the pitfalls that take place due to these time sensitive expectations. Author moves onto explain the necessity for XP and what are the basic guidelines of XP.

The author should be commened for covering where XP is impractical and should not be used. The book explains the life cycle of a XP project and different roles that are part of this radical process.

XP is not suitable for many present day organizations(due to age old approaches that are already implanted in the system); but should be considered for time sensitive deliverables. This book will definitely give a headsup on how to approach XP.

Small negative: The book takes too much time on what is wrong in other traditional approached to software development(for the size of the title:about 200 pages)
0CommentWas this review helpful to you?YesNoSending feedback...
Thank you for your feedback.
Sorry, we failed to record your vote. Please try again
Report abuse
5 of 7 people found the following review helpful
on December 5, 2004
This is a complete re-write.

The only thing that is the same is the title (with the appended Second Edition). The old foreword is included as well though Erich Gamma wrote a new one. Amazon seems to be re-using the back cover words from the first edition which is misleading because even that is different. I would also suspect that are many reviews here by people who haven't read this second edition, thinking it's just a revision.

I must admit that I liked the bravado of the first edition, and even more so the first inklings of XP on the Portland Pattern Repository. However, I like the authenticity of this second edition more. There is a much greater sense of "Whole Team" while in comparison, the first version is an expression by programmers.

Probably the key thing is that this was written with the context of a lot of people who have tried XP or at least tried to go in that direction, in the five years since the first edition was published.

Much clearer communication of the relationships between values (universal), principles (domain-specific), and practices (concrete). Values and principles are "Why" and practices are "How". I would suggest that much of the resistance to XP comes from a disagreement over values and principles, though it manifests as a disagreement over practices. XP is a change in culture, in relationships, not just a change in technique. This is why it is so appealing to some, and so frightening to others.

It's interesting to see how much of what the community has learned is incorporated into this edition. There's mention of Theory of Constraints, Toyota Production System, etc.

"I hope that in reading and applying this book you will come to a deeper understanding of why you are involved in software development and how you can find satisfaction from this work."

I can honestly say that this book helps restore my hope that we can make a difference for the better.
0CommentWas this review helpful to you?YesNoSending feedback...
Thank you for your feedback.
Sorry, we failed to record your vote. Please try again
Report abuse
on June 24, 2014
I have read many software development books, but there are only a handful that had such an impact on my life that they fundamentally made me look at software development differently. Today I have to add Kent Beck’s Extreme Programming Explained 2nd Edition to that elite group.

The physical book looks deceptively thin - one hundred and sixty odd pages with an easy text and thick margins. Firstly, the thick margin were useful because they are now covered with notes and between those pages I believe there is a message worth gold.

Kent Beck’s explanation of the relationship between Values, Principles and Practices is as far as I am concerned a required reading for software developers going forward. I have seen teams struggle, debate and argue about various practices and whether they are good or bad - in the past I would have a hunch or could say what I had seen work in other teams - but for the very first time I feel I can now justify one practice over another, one tool over another and explain why one is fundamentally better than another.

The rest of the book continues to contain these gems that keep resonating with me - here are a few I underlined, but read the chapters related to get proper context:

pg. 38 - Practices are theories
pg. 38 - No matter what the client says the problem is, it is always a people problem
pg. 40 - Cleanliness and order leave minds free to think about the problem at hand
pg. 42 - On pair programming hold each other accountable to the team’s practices
pg. 49 - Software has few certainties. The ten-minute build is as close as we get in software engineering.
pg. 52 - XP teams work hard to create conditions under which the cost of changing software doesn’t rise catastrophically.
pg. 52 - Without daily attention to design, the cost of changes does skyrocket
pg. 53 - Refactoring is a discipline of design that codifies these recurring patterns of change
pg. 65 - The five whys when establishing root cause analysis
pg. 79 - Trust two metrics to measure the health of XP teams. The first is the number of defects found after development. The second metric is the time lag between the beginning of investment in an idea and when the idea first generates revenue.
pg. 88 - The reward system and culture need to align with overall throughput instead of individual productivity for the change to stick.
pg. 91 - The importance of time available
pg. 92 - Plans and Prediction explanation
pg. 92 - Ingredients to planning
pg. 94 - On estimates… I prefer to work with real time estimates now, making all communication as clear, direct, and transparent as possible
pg. 95 - Many teams try to skip this step and go straight to a computerized version of the stories. I’ve never seen this work
pg. 98 - 2 Defect Reducing Principles
pg. 104 - Unfortunately, design in software has been shackled by metaphors from physical design activities
pg. 108 - Part of incremental design is figuring out how to stage design improvements
pg. 120 - If programmers won’t pair or if they insist on owning code, have the courage to fire them
pg. 132 - Explanation on the incorrect assumptions on taylorisms

To sum it up, I know I am going to read this book many more times and each time there will be a deeper insight. Thanks to Kent and all those involved for this inspiring read.
0CommentWas this review helpful to you?YesNoSending feedback...
Thank you for your feedback.
Sorry, we failed to record your vote. Please try again
Report abuse
4 of 6 people found the following review helpful
on November 26, 2004
The first edition of this book provoked me to get on an XP team and see if it really works. It does. In the ensuing years, I've worked on 3 teams which used XP values, principles and practices and achieved great success, and 1 team which did not and achieved some success at great human cost (the best members of the team burned out and left).

The new edition inspires me anew. My favorite new chapter is the principles. These reflect what the teams I've been on have learned through trial and error. What a bonus to start off knowing and applying these principles!

There are a lot of misconceptions about XP (see other reviews here - a common one is that there's no documentation). All I can say is, read this book, really understand and apply the values, principles and practices to a project. It's not any easier than applying any traditional methodology. The difference is that it really works. And the reason is that it's all about people and helping a team do its best work.
0CommentWas this review helpful to you?YesNoSending feedback...
Thank you for your feedback.
Sorry, we failed to record your vote. Please try again
Report abuse
2 of 3 people found the following review helpful
on January 10, 2005
In his second edition Kent has defined Extreme Programming as a journey and not a destination. This new edition is a realization that all projects start out with some good and some bad mixed together. This new edition also has more for people in enterprise situations.

Kent underscores his belief that a team's values are the most important criteria of a project. Extreme Programming is no longer a restrictive set of practices to be measured against. Kent encourages people to start with the set of practices he has seen work but then go even further by using the principles to create new practices for unique situations.

In the end what Kent has written down is more uniform practices, greater stress on the values, and a set of principles that are equal in importance to the practices. These are things I notice eluding people who read the first edition.
0CommentWas this review helpful to you?YesNoSending feedback...
Thank you for your feedback.
Sorry, we failed to record your vote. Please try again
Report abuse
Customers who viewed this also viewed
Extreme Programming Explained: Embrace Change
Extreme Programming Explained: Embrace Change by Kent Beck (Paperback - October 5, 1999)

Test Driven Development: By Example
Test Driven Development: By Example by Kent Beck (Paperback - November 18, 2002)

Planning Extreme Programming
Planning Extreme Programming by Kent Beck (Paperback - October 26, 2000)

Send us feedback

How can we make Amazon Customer Reviews better for you?
Let us know here.

Your Recently Viewed Items and Featured Recommendations 

After viewing product detail pages, look here to find an easy way to navigate back to pages you are interested in.