Rating: 
Summary: Good discipline for implementation but lack of modeling
Review: Ken expose here very clearly and efficiently a new way to think about process, entirely based on code and hardly iterative cycles. One could say (and I am one of them) that this discipline missed model usage, because the author prefer CRC cards. Nevertheless, the author don't pretend to get the ultimate graal, but simply expose his ideas. I think that there are a lot of good ideas here, especially when you deal with implementation. Moreover, the book is efficient, short with short chapter, and even if you don't buy the author's ideas, you will not waste your time.
Rating: 
Summary: Great book on one approach to software development
Review: I believe in the "think first, program later" school, but the author Ken Beck makes a strong case for what I call "design a little, then test, then program, then repeat many times" school of incremental programming. The author calls it "extreme programming."I thought the book was easy to read yet contained very important topics. Even if you don't agree with the author on releasing many small versions of your software, you will find many useful ideas here. At least I did. I don't fully agree with the author, but I can see several kinds of situations where it applies (where specifications are unclear, for example, which is often). His approach would not be considered prototyping. The approach relies on many software builds, and the use of automated testing to reduce risk and increase confidence in the software. His comments on options pricing models and software was excellent, but could have been developed more. I think this might have been confusing for non-financially oriented readers. I plan on using several of his recommended techniques. The only weak point of the book, was that I didn't fully understand how to implement the automated testing that he recommends. This looks very powerful, after he described the ramifications on the software cost curve. I guess I'll have to learn this from another source. I see that another book is anticipated by the author in December of 2000. I plan on getting that book as well. Overall, I highly recommend this book. John Dunbar Sugar Land, TX
Rating: 
Summary: XP = the Psuedo Revolution
Review: The claim, in one of the reviews here, that this book is going to rank w/the Gang of 4 book is patently absurd. This book attempts through a kind of Jonathan Edwards Fire and Brimstone approach to convince the reader to get its religion, but when you sum it all up, there isn't much religion to get. All the pillars of the methodology have little or no exposition in the book (unit testing, pair programming, constant builds). They are all mentioned and meekly argued for, but none of them are actually examined. Furthermore, I remember quite distinctly reading about pair programming in Larry Constantine's far better Peopleware a LONG TIME AGO! Let me add one other crucial point here: this book attempts to achieve acceptance with the reader through creating an impression of both an epiphany and validation. I found that a lot of things that were being espoused here are things I've been doing a long time. I believe many people will find that to be true and consequently will like the book because of the sense of validation it gives. However, when I was done, I couldn't help but think about how much more could have been done here! How about talking about actual unit testing examples? Why not talk about structure within groups; it's far too easy to just say everyone should be doing everything. Profiling, for instance, is clearly not something everyone should be doing. Like so many things in the modern world, this is largely a retread wrapping itself in the cloak of a revolution.
Rating: 
Summary: XP considered harmful
Review: The XP approach to development is just another weak rationalization to explain why hacking is an OK approach. Design doesn't enter in until you've hacked yourself into a corner. While making bold claims, such as the claim that the cost-curve for early versus late changes to a product is actually flat (at least using XP), the key claims relied on in the book are never verified or quantified in any manner. Another annoyance of the book is that it seems to talk about *all* software development, but in actuality really only ever deals with issues of concern to IT organizations. Granted, that is a huge chunk of the industry, but the author never so much as acknowledges other application areas. There are some good things in the book, but only a very experienced engineer would be able to sort them out from the rest.
Rating:
Summary: A Must Read For All People Involved with Software
Review: This is a great book on an important subject. It is only 179 pages but more worth than a lot of books with more than a 1000 pages. It is well written. It is a classic. Well worth reading every year for the next years to come.
Rating:
Summary: Radical zeal but concise, simple, courageous
Review: No doubt the ideas brought forth in Beck's work will generate controversy. He writes as he preaches, simple and courageous. I read the book in 3 hours and am still thinking heavily about its message. Current technological advances may actually allow his approach to work but it will be a tough sell to any customer comfortable with current methodologies. Beck's zeal is contagious but it comes across as rationalization for the lazy way I want to code. Frankly, what he espouses could be downright dangerous (not courageous) if the test bed environment is not extremely robust. I would have loved more facts and figures behind the one-paragraph arguments. I agree with other reviewers, this is just a large article, not a book, but oh does it generate some radical thoughts!
Rating:
Summary: real process for rapid development in a dynamic environment
Review: I develop software in a dynamic (i.e. chaotic) environment where customers are rarely sure of what they want software to do for them. If we were able to completely blueprint a design and have the customer sign off on it, the requirements would likely have changed the next day. Extreme Programming Explained puts forth the concept that software is and should be very malleable. It seems to be a variant of the spiral development process, with a chief distinction being that each cycle results in an actual integrated, deployed piece of software. A main differentiator is that XP offers a body of complementary techniques and principles that make very rapid development in a changing world possible. Competition is too great for companies to risk nine months (of time and dollars) waiting for software that may not meet its needs by the time it is delivered. Getting working software in front of a customer in a very short period of time is critical. However, the overhead of proper reviews and testing cycles is usually too much for an ideal 2-3 week spiral cycle. Pair programming and automated tests, two important concepts that XP promotes, are specific techniques that purport to solve this problem. One other major positive of this development "methodology" is that it centers around the fact that software is developed by teams of humans -- something most other processes almost never take into account. XP is not geared toward teams of hotshot, superstar developers. It instead realizes that most development organizations are a wide mix of capabilities and experience levels -- something extremely important in this age of a severely limited developer resource pool. A few of the ideas presented are a bit nebulous, but I suspect that's to pave way for the followup books which will go into depth on actual practical application of the concepts. Lacking for me, personally, was a discussion on integration testing and the organizational shakeup that introducing of XP will definitely create. I'd also like to see more documented case studies. Otherwise, the book is a quick, enjoyable read.
Rating: 
Summary: The Electric Kool-Aid Acid Programming Test
Review: There has been much discussion of late about making the practice of programming into an engineering profession. The current state of programming has been described as being similar to electrical engineering in the early 20th century. (see IEEE Annals of the History of Computing, Vol 19, No. 4, 1997). In that age and our current age there are two camps--one camp believed that there is a scientific basis that can be applied to the 'art' of electrical engineering (Heaviside) and the other camp, the so called 'practical' men lead by Preece, who once said, "I cannot recall to mind one single instance when I derived any benefit from pure theory." This book ignores evidence of proven programming practices that actually work. Practices that have actual empirical evidence to back up their claims. Evidence that software development can and should be a consistent, predicable endeavor. If you read this book and no other you would not believe that software could ever be an engineering profession. This book celebrates programmers as craftsmen rather than engineers. This book has some interesting ideas. The author's writing style is reminiscent of a over zealoted high priest. I guess this is understandable in that no evidence is given and we have to prodeed on faith.... In summary, skip this book and buy After the Gold Rush by Steve McConnell.
Rating:
Summary: Good concepts, Bad book
Review: I've been using most of the techniques from this book off and on for the last three years and I think they're quite effective. Like the author said, if code reviews are good, do them all the time (programming in teams). If testing is good, do it all the time. Nothing earth-shattering there but I think this style is much more efficient if you have the right team members. However, I thought the book was weak. I'd agree with the other reviewer that said this would have made a better article than a book. If I had paid $30 to read this book, I would have been disappointed. I would much rather have a five page article version I could pass around to other developers.
Rating:
Summary: possibly life-altering
Review: It is difficult to say anything about this book that will not sound like crass exaggeration. Let me restrain myself and say only that it contains a readable description of some ideas that I cannot resist investigating further. For a taste of what's in store, use a search engine to find references to "extreme programming." On the down side, you will definitely have to investigate further. The book is a bit light and brief, a manifesto for a new approach to development. The author is loosely collaborating with a group that plans to publish several books to fill this gap, among them the already published and quite excellent "Refactoring" by Martin Fowler. Beck and some co-authors are at work on a follow-up called "Playing to Win."
| 
