Customer Reviews


10 Reviews
5 star:
 (4)
4 star:
 (2)
3 star:
 (2)
2 star:
 (1)
1 star:
 (1)
 
 
 
 
 
Average Customer Review
Share your thoughts with other customers
Create your own review
 
 

The most helpful favourable review
The most helpful critical review


12 of 12 people found the following review helpful
5.0 out of 5 stars The first edition
If you already know XP, you perhaps want to know whether to buy this book. I'll try to answer that question.
The first edition of this book marked a watershed in the way I thought about software. I did leave many questions unanswered, however, as our team struggled to implement the practices 'out of the box'. Perhaps a bit too much revolutionary zeal.
The...
Published on 3 Aug 2005 by D. Poon

versus
6 of 6 people found the following review helpful
3.0 out of 5 stars Embrace the 1st edition
I have to disagree with one of the other reviewers. The first edition of Kent Beck's book was a model of simplicity and clarity. The second edition however seems far less clear, and yet in places is also more dogmatic.

Whereas in the 1st edition there was a simple list of twelve practices, in the second there are 13 primary practices and 11 corollary practices...
Published on 14 Aug 2006 by Peter Hearty


Most Helpful First | Newest First

12 of 12 people found the following review helpful
5.0 out of 5 stars The first edition, 3 Aug 2005
By 
D. Poon - See all my reviews
(REAL NAME)   
Verified Purchase(What is this?)
This review is from: Extreme Programming Explained: Embrace Change (Paperback)
If you already know XP, you perhaps want to know whether to buy this book. I'll try to answer that question.
The first edition of this book marked a watershed in the way I thought about software. I did leave many questions unanswered, however, as our team struggled to implement the practices 'out of the box'. Perhaps a bit too much revolutionary zeal.
The breadth of the second edition is far greater. It explains the principles so that you can adapt them to your own circumstances, without subverting their original intent. As such it is a far more usefull book than the first edition, even if it lacks the bold audacity of the former - or maybe the ideas of XP dont seem so left of field anymore.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


6 of 6 people found the following review helpful
3.0 out of 5 stars Embrace the 1st edition, 14 Aug 2006
Verified Purchase(What is this?)
This review is from: Extreme Programming Explained: Embrace Change (Paperback)
I have to disagree with one of the other reviewers. The first edition of Kent Beck's book was a model of simplicity and clarity. The second edition however seems far less clear, and yet in places is also more dogmatic.

Whereas in the 1st edition there was a simple list of twelve practices, in the second there are 13 primary practices and 11 corollary practices. The lists of principles differ between the two books too, making it hard to understand what some people mean when they talk about XP.

Much of the management discussion has also been removed from the 2nd edition and migrated into a second book.

If you want a clear, unambiguous description of XP, I would strongly recommend trying to find a copy of the first edition.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


6 of 7 people found the following review helpful
5.0 out of 5 stars Missing the point, 30 Mar 2006
By 
Peter Moss "themusicsnob" (Herne Bay, UK) - See all my reviews
(REAL NAME)   
This review is from: Extreme Programming Explained: Embrace Change (Paperback)
Most of the negative views here really miss the point and, personally I believe this is down mostly to ignorance or resistance to change. To the reviewer who says "nothing new" - well that is half the point; XP is revolutionary because it is common sense applied to the experience of seeing how things have worked for the last 30 years (also if you studied this book at university I guess you have no or little real world experience of commercial development). Also XP was one of the first of the "new" ideas - it is getting a bit 'old' now but just because most punk sounds like the Ramones that doesn't make the Ramones unoriginal.
To those who say pair programming is impossible you've not tried it your just resistant to an idea that seems wrong as a manager (but you don't have to do pair programming). To those who say "You cannot always be ready to ship, some bits of applications takes weeks until they are just ready for a proper compile" then it is you who needs putting in the humour section as you've missed the point. Unit tests, continuous integration, disciple and good management means you can be ready to ship on a hourly basis (we are in my shop). That doesn't mean it's a completely finished product in terms of features but every feature is finished and works and can deliver business value.
I feel some critism of XP is valid (pair programming isn't right for everyone - but that doesn't mean its wrong) and it doesn't work on large teams (but then large teams may be a 'bad thing') but the truth is most critism sounds like the people who poo-poo'd (and still do) source and change control even though now you are considered a real idiot for not having them - that's the same with unit tests and CI.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


6 of 7 people found the following review helpful
4.0 out of 5 stars The White Book..., 9 Feb 2006
By 
Kat Crichton-seager (Dorset, United Kingdom) - See all my reviews
(REAL NAME)   
This review is from: Extreme Programming Explained: Embrace Change (Paperback)
Its an easy read, if you can stomach the slightly painful marketing-speak. XP brings silly little things like humanity and respect back into programming.
If you've not pair-programmed or test-driven before then you are missing out on the ideas that Microsoft are still desperately scrabbling to understand. Kent may be walking on the shoulders of giants, but this book has been a watershed for responsible, non-reactive software development.
This, the second edition is even more practical, improving on the original book with a more pragmatic and cooperative business attitude.
There are people out there enjoying their work, helping their businesses to thrive without working all-hours under threat of violence or redundancy. Why not join us?
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


5.0 out of 5 stars Already a classic, but always current and fulll of good advice, 25 Feb 2014
Verified Purchase(What is this?)
This review is from: Extreme Programming Explained: Embrace Change (Paperback)
Very well written, a must-read for software developers and people in the software development business.

Would recommend it to anyone.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


4.0 out of 5 stars Useful revised edition, 30 Mar 2012
This is a revised edition of the classic, controversial work that put the spotlight firmly on lightweight, iterative software-development methodologies that collectively became known as "agile".

The first edition of the book was published in 1999. Although iterative methodologies were being used at that time, the waterfall process was predominantly used. Although Royce does in fact describe a partially-iterative approach, most implementations were strictly waterfall in application: the phases of requirements specification, design, construction, integration, testing, installation, and maintenance were each executed, then frozen and signed-off in strict order.

At the same time, software-development toolsets were becoming more powerful. In addition, some programming languages, such as Smalltalk and Java, where becoming flexible enough to model real-world problems and to generate and deploy code from these models. This ability to generate software rapidly, and to elicit feedback quickly from the end-customer, allowed software developers to:
* Iterate the waterfall process many times in one project by implementing a software system incrementally;
* Be able to deal with requirements that change as a response to business change rather than having them frozen at the beginning of the project.

This approach, along with other features, coalesced into XP. XP has a number of features in common in with other software-development methodologies and a few unique ones. The common features are that projects are iterative, ie they repeat the same activities in a cyclical fashion, incrementally deploying the system at the end of each iteration, resulting in rapid feedback of any issues. It puts emphasis on intense communication between end-customers and developers.

The features that are unique to XP are:
* a simple documentation set, especially for requirements and design - the key artefacts are automated tests and code.
* visible artefacts on public display in the work environment, so that newcomers can see the status of the project in a few seconds. This is an idea derived from Lean process of business improvement.
* pair programming, where two developers sit at the same workstation and work on the same code. The idea is to lower the number of defects without having a lengthy, off-line code review.
* to aim to develop the simplest thing that could work.

The projects to which XP is best suited have the following characteristics:
* highly uncertain or rapidly-changing requirements;
* having lower formality - for example less likely to be of a mission-critical nature and less likely to have a high systems-engineering element;
* a high degree of human-computer interaction (GUIs), rather than, say, a real-time messaging system;
* the stakeholders (especially the developers) have experience of, or are willing to support, highly-collaborative methods of working;
* having a contract that supports iterative working and promotes customer-supplier collaboration.

XP has been subjected to a number of criticisms - some more justified than others.
The most common criticism is that it encourages "hacker" indiscipline. This would certainly be justified if XP's other practices were not followed. However, the practices of pair-programming, the emphasis on testing and limiting the hours of the working week seem far-removed from the work of a lone hacker.

However, another criticism - that pair programming (mandated by XP) is not suited to all developers - has more credence. The statement that those who do not wish pair are shown the door may not be workable (or desirable) in some environments.

Another criticism is that system design is ignored. Certainly, the first edition or the book downplayed system design. The new edition states more clearly the importance of design but that it should be as lightweight as possible. For this to work efficiently, the team needs to be seeded with a number of experienced XP practitioners.

Another criticism is that XP is silent over how projects interface with other corporate planning activities such as corporate reporting and programme management. This is a valid criticism but links can be made to recognised governance frameworks such as (PRINCE2), either directly, or via other practices such as DSDM or Scrum.
So why did this book create such a stir when it first published in 1999? Several other iterative methodologies where in use before this date: Evo (60s); Spiral model (80s); RAD, DSDM, Scrum, RUP, ICONIX (all early- to mid-90s).

Several factors contributed to XP's notoriety. It had a polemical tone; it was a developer-led call-to-arms against a perceived bureaucracy. This was felt to prevent direct contact between developers and end-customers and lead to a lack of rapid feedback, leading to frustration in both camps. In addition, some non-XP practitioners became irritated at the publicity XP received. These people re-stated the (sometimes-justified) criticisms - which of course led to more publicity for XP.

The strident tone has been smoothed in the second edition: a more reflective and holistic view is evidenced. However, the practices seem as radical as ever, for example, the suggestion of making incremental software changes to live system on a daily basis.
Even in its second edition, Extreme Programming Explain remains a powerful and controversial read. Essential for all software and systems engineers - even if only to find out what all the fuss is about.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


2 of 3 people found the following review helpful
3.0 out of 5 stars Not fit for developers, 16 April 2010
By 
Verified Purchase(What is this?)
This review is from: Extreme Programming Explained: Embrace Change (Paperback)
I'm a software developer looking for ideas of how to implement a small project using XP approach.
This book is not for me or any developer. Kent Beck is introducing the concepts of XP to the audience. In my case, the book is trying to preach the converted. I was looking for advice on HOW to implement the Extreme programming concepts. Instead i got a slight overview of WHAT XP is.
If you know nothing about XP, buy this book.
If you know about XP and want advice on HOW to implement XP. DO NOT buy this book.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


1 of 2 people found the following review helpful
5.0 out of 5 stars A classic, 30 Dec 2008
This review is from: Extreme Programming Explained: Embrace Change (Paperback)
This second edition of Kent Beck's seminal book on extreme programming is even better than the first edition. Extensively rewritten, it now draws on the lessons of the last five years to deepen and extend the philosophy behind extreme programming.

I don't know why it is, but it must be significant, that of all the computing books I've read or reviewed in the last two years, the ones about agile and extreme programing stand out for good writing and an ability to project enthusiasm. This book is no exception. One caveat though, don't expect it to give you a checklist to tick off for extreme programming - this is a book concerned with the philosophy of extreme programming.

This book will be of use to a number of different categories of programmers. For those who would like to find out about extreme programming, it is a classy advocacy and explanatory book. For those who would like to introduce extreme programming into their workplace it is chock full of information that can help you win the struggle. Finally for those already practicing extreme programming, this book can fill in the gaps and give you ideas on how to take things forward.

Of, course, there are other things I would have liked to have seen in it. More discussion on large projects for instance, or at the other end, discussion of extreme programming practices for the lone programmer. As the only programmer in my company, I find it difficult to practice pair programming...

But these are not deficiencies - no reasonable sized book can cover everything - and I would heartily recommend this book to any programmer who wants to deepen his or her understanding of the craft. Just one question, Kent. How is it that the prophet of the short cycle and refactoring took five years and a complete re-write to produce the second iteration of his book?

Highly recommended.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


6 of 16 people found the following review helpful
2.0 out of 5 stars Unworkable and unrealistic in the most part..., 3 April 2005
By 
Geoff Hodge (Marple, England) - See all my reviews
(REAL NAME)   
This review is from: Extreme Programming Explained: Embrace Change (Paperback)
Don't get me wrong, this book did has some interesting ideas and concepts, but for 95% of people/teams/projects, it would be completely unworkable.
Some parts are just completely wrong. For example, he recommends pair programming all the time, swapping partners every hour, which will result in virtually no work getting done and people constantly losing track of what they are doing. Another factor is that you should never talk about anything other than work at any time or for any reason, nor should you have any sort of relationship with people on your team outside of the work environment (e.g. meet up with pub, arrange to do anything) and should immidiately change teams if you want to do so! Great way to destroy moral, destroy teams and make work an incredibly unpleasant environment.
This book has a few good ideas, but most should be ignored.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


9 of 27 people found the following review helpful
1.0 out of 5 stars The Emperor's New Clothes, 31 Oct 2005
By A Customer
This review is from: Extreme Programming Explained: Embrace Change (Paperback)
This book amazed me. Unfortunately this is not because of the outstanding quality, but because I cannot believe that Kent Beck managed to last 160 pages without introducing one single new concept, but simply regurgitated what every programmer has been doing for the last 30 years. I was recommended this book by my university lecturer, but it did not help me in any way complete my module project.
It was full of vague, non-specific, woolly comments about how amazing XP is, and how radical. But there are no new ideas in this book, any more than the emperor's new clothes were magnificent. I really wanted to like this book, but unfortunately it was just not worth it.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


Most Helpful First | Newest First
ARRAY(0xae000f0c)

This product

Extreme Programming Explained: Embrace Change
Extreme Programming Explained: Embrace Change by with Cynthia Andres (Paperback - 16 Nov 2004)
21.74
In stock
Add to basket Add to wishlist
Only search this product's reviews