Customer Reviews

Extreme Programming Explained: Embrace Change (2nd Edition)

5 star:		(10)
4 star:		(2)
3 star:		(2)
2 star:		(1)
1 star:		(0)

 

 

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.

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.

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.

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.

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.

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)

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.

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.

I loved this book. I loved the style of Kent's writing, entertaining examples and even boring stuff is put in very nice way. I have read it quite a while ago, but I still can remember relevant parts.

Another great thing is exactly as short/long as it should be. You'll finish the book without getting bored and you'll know just enought about extreme programming.

I believe the basis in software development for business is in this book.
You can have the technique, the skills, and the money, but you will need the human side for any agile way of working.
This is not the silver bullet, but you NEED to read this book.