Rating: 
Summary: Purely amature
Review: While "Extreme Programing" has a number of sensible suggestions, the net-effect of it is quite marginal. I read numerous positive reviews and was hopeful when ordering the book, but was rather disappointed in the end.The prose of the book is quite poor, almost to the point of annoying. Everything in the book is referred to as "Extreme Programming" or "XP" which really nullifies the term. The author also has very little support for most of his arguments, which leads a reader to wonder if some of the ideas presented are mere whim. If you don't already own this book, then save yourself the bother. There are a number of books along the premise of "Extreme Programming" which are much more useful in the end: "Rapid Development" and "Code Complete" (both by Steve McConnell) "The Pragmatic Programmer" (Andrew Hunt).
Rating: 
Summary: Buy this book!
Review: No, this isn't a programming book per se. However, it's the best book that I have ever found on the process of developing software. I used a similar process to build a product called SalesLogix. It worked and worked well. The idea of building in increments is invaluable and a much better idea than the big bang approach. The team programming concept is also gold. Buy it. Buy it. Buy it.
Rating: 
Summary: Anti-Methodology Culture Formalised
Review: I have been writing software for 17 years and now realise the past 10 years were cursed by the rise of formal methodologies. This book provides useful ammunition so that programmers can protect themselves from the chattering classes of the IT Industry and get on with the job. No doubt the Rational Rose crowd will spend millions of corporate dollars in an effort poor scorn on the title. The ideas presented in this book will be debated for years, let's hope more skilled communicators take up the Extreme Programming baton and publish further titles. One star dropped due to the shallow presentation and poor organisation, but then a well-structured book from this author would have been almost disconcerting!
Rating:
Summary: Radical ideas!
Review: Kent Beck explores some interesting ways of improving the software development cycle. If you are not interested in some big changes, then this book is not for you. One of the more intersting concepts that Kent is pushing is this book is the concept of programming in pairs. This means that whenever code is written that you have 2 people working on the same computer to write code. My first thought was that this would slow down the process, but Kent explains that it does not actually slow down the process, and it actually speeds things up. This book contains many radical ideas that would really change the development process. For instance Kent explains that its better to meet the requirements as they exist at the end of the project, rather than the requirements that have been set at the begining of the project. In a day time when progress is measured in "internet time" and requirements are constantly changing, Extreme Programming provides some usefull ideas.
Rating:
Summary: This book has changed my attitude to work
Review: ... and has probably been the most influential book I read for some time. Highly readable, Extreme Programming seems to give back the fun to software development that was drained out of it by the fear of touching the code to early. The main thing lacking is a cookbook on how to apply XP in today's over-outsourced and over-distributed web-development environments. Who is going to write about this?
Rating:
Summary: XP will change what is possible with quality software.
Review: XP redefines the relationship between software developers and their customers. Better said, it defines that relationship when up time now it has been characterized by tension and blaim. XP defines simple rules, and simple roles that allow for better communication and higher project success rates. XP gives Project Managers the tools to measure and manage a project. XP gives Software programmers the tools to deliver a higher quality product.
Rating:
Summary: The latest fad
Review: If you've never considered heavily testing code, or writing with a partner, or interacting heavily with the customer, you might have something to gain by reading this book. But overall I was quite disappointed. There's no attempt to quantify the gains of the methodology, and no indication that the author has ever heard of the "Hawthorne Effect" (a well-known phenomenon that changing the work environment increases productivity no matter what the change is). The price is outrageous for 166 pages of text, much of which is padding. As an article in CACM, this could have been useful; as a book, give it a pass.
Rating:
Summary: Extreme programming is not so extreme
Review: Extreme programming really is not what the name suggests. In many ways, it is a throwback to the earlier days of programming. When I was teaching at the college level in the decade of the eighties the first thing that we told the students was the classic principle that goes back to the beginning of civilization. When faced with an extremely difficult task, divide and conquer. Works in war, politics and software development. In extreme programming, this principle is applied to the largest of projects. The iterations are parceled into as small a unit as possible, with the cycle being: design a little, code a little, test a little. Something like the baby step approach to software development. In particular, "Code is integrated and tested after a few hours - a day of development at most." However, this must only be a rule of thumb, as there are times when it takes longer than a day to create the code update. Which is what I see as the problem with extreme programming taken to the stated level. In all the stages of development, there are tasks that simply cannot be broken down into the "baby steps" needed for extreme programming. An even better example is testing. Even with a superb design that is heavily encapsulated, it is possible to make a "simple" change that would require days of testing to verify.
Another throwback is simply, make the programmers talk to each other. Note that the word was talk, not communicate. Electronic messages are fine, but humans still transfer information and resolve differences much better when there is mutual visibility. The core of this point is what the author refers to as pair programming, where the tasks are parceled out into teams of two. Ideally, the two will complement each other, where one can code while the other analyzes. All fine in theory. Like so many other theories, it ignores the reality of human nature. If you create a team of two and place them in a stressful situation, there must be a great deal of mutual respect, tolerance, understanding and they must complement each other. If one possesses a greater skill set or more simply, a dominant personality, then the total will not be greater than the sum of the parts. There is also the problem of breaking ties, which will fall to a manager, who may not be as cognizant of the issues as the members of the pair.
The four principles of extreme programming are: communication, simplicity, feedback and courage. Sound advice for almost anything you wish to undertake. However, not everything is simple, feedback is sometimes difficult, impossible or wrong; communication is both positive and negative and courage can get you fired. I have no doubt that these principles will work, but only of they are used as general guidelines and not as fixed rules. It is worth reading, but there are better books available.
Rating:
Summary: The Jonathan Livingston Seagull of software development.
Review: It is freedom, on a mission
Rating:
Summary: Disappointing
Review: I don't recommend this book for someone on a real OO project of any size. While there are parts of the book that might be useful, many of the suggestions are downright wrong IMO from the many OO projects I've been on. CRC cards are all well and good, but they don't scale to significant commercial projects. Open group areas with desks pushed together is a bad thing, not a good thing. As much as the author wants everything to center around programming, it doesn't. Some thought in analysis and design and refactoring @ that level is more powerful. Programmer pairs is an interesting idea to try (though I think it's taken too far in the book). There are much better books out there (e.g. Larman's OOA/D book; Fowler's UML book) - get them and leave this one on the bookstore's shelf!
| 
