Extreme Programming Explained: Embrace Change

Rating:
Summary: It is about the Journey not the destination
Review: 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.

Rating:
Summary: This is what a 2nd edition should be like
Review: 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.

Rating:
Summary: Not just for programmers!
Review: This book updates basic concepts that don't need to be reserved for programmers. Working on a lot of ERP/APS projects, I appreciated reading an approach that accepts that change happens, no matter how much upfront planning you do. The traditional approach has a lot of overhead -- management, documents, design -- and makes responding to needs difficult and in many ways actually detracts from the value of the ultimate deliverable, a functioning system.

I worked on a project (before reading this book) that reflected some of the tenets: don't build for the future but for current requirements, have testing going on all the time (automated and manual), work with others as much as possible, don't be afraid to try something different, etc. The project culture was very supportive. As a note, our programmers were all offsite, but very responsive -- since they worked together we could always reach someone who could address our issues. I think there is some leeway for the onsite customer requirement given the sophistication of technology today.

The main drawback to XP is that it relies on the strengths and compatibilities of people. If the environment in which you are trying to introduce this approach does not have a positive culture and talanted people (learning is allowed!), you've got issues that will negitively affect any undertaking -- it may simply be covered up better in all the clutter.

Rating:
Summary: We're growing up
Review: 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.

Rating:
Summary: Down to earth, common-sense values, principles and practices
Review: 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.


Rating:
Summary: A must have for an intermediate programmer/developer.
Review: This book is undoubtedly a classic. One of the neatly ordered book I have read in a while. It presents to a novice planner on becoming more productive. However, if you are a novice who has just stepped into the world of programming...then maybe this is not the right time for you to read this book. Maybe after 2 years, once you are comfortable in makind informed sensible decisions, this book becomes a MUST READ.
Any manager, senior developer or anybody who leads a bunch of programmers...yes...a MUST READ.

As much as this book advises on what to do and what not to do for XP....towards the end, it gets a bit too cautious. The author tends to playing it safe by telling that XP is not for everyone. Though, I admit to the fact that he is not trying to say anywhere that XP is THE WAY...but he does not reinforce that XP is a nice way very often.
The book contains many words of wisdom...and as you read through it gives you the opportunity to review yourself as a programmer. The book describes programmer attitudes and smart people working in a team following XP. While the author tells what a good programmer practicing XP should do, he also points out to the plain facts...as to what programmers in the initial stages of XP do...
Though not directly related to code, the author describes a few practices while developing code, that can be followed even when one is not coding "XP-STYLE"

This book is certainly a classic....but as a word of caution...do not read the whole book if you have just begun to program. The wait is really worth the philosophy the book preaches.