Rating: 
Summary: Glosses over the negatives
Review: This book is simplistic. It glosses over the complete psychology involved in developing code with a team. I was very disappointed comparing what this book preaches and what it uses to substantiate its percepts. The analogical nature of the book doesn't allow one to anticipate problems and resolve them. As a programmer I don't think the book describes things as they are in team interactions. I'll keep my copy of the book. Some of the things written in it are so ludicrous as to be funny.
Rating: 
Summary: Interesting ideas
Review: This book puts forward some interesting ideas on the development process. Some I find persuasive, others I am not so sure about. The idea of pair programming. where two programmers sit together at a single screen to develop is certainly good. We have suffered too much in this industry from the concept that programmers work alone heroically producing code, that subsequently no one else can understand. That the code should belong to the team and not to the individual programmer is not a new idea but pair programming as a way of achieving this a genuine innovation. I have certainly found in practice that just talking about what I am doing to another person can help me solve programming and design problems, even if the other person says nothing at all. The approach to automated testing is also interesting. If you take the approach to its logical conclusion then in effect you would write all software twice, once for production and once for the testing. Whenever you get a different result then either the production software is wrong or the test rig is wrong. I am not a real time programmer but I understand that safety critical systems are already written in this sort of way. Introducing this approach to commercial software would certainly lead to a big improvement in quality. I can see it would be difficult to persuade management to take up Beck's ideas. I cannot see them accepting that to do a particular job you need two programmers rather than one. The advantages do not make themselves seen until later; reduced risk: when a programmer leaves or is ill there is always someone else in the team who understands the code, better quality: all the code has been reviewed. I don't think that this approach would actually result in lower productivity, in my experience putting two programmers to work on the same development separately usually only results in at best a 50% increase in productivity and we then face a lot of integration problems, especially if you are unlucky enough to encounter a programmer who insists that the code belongs to him. As I say, the big problem is persuading management. The idea that we should deliver as soon as possible the simplest design that will do something useful is I think a good one for smaller projects, but I find it difficult to see how this could be used for a very large commercial software project that requires a lot of analysis and design and a huge effort for development and implementation. The bibliography introduced me to some fascinating reading though I am not convinced of the direct relevance of many of the books he recommends to the subject in hand. Though I have long thought that computing and architecture are two professions with much in common, I fail to see the connection between Christopher Alexander's pattern languages and software development. I would definitely recommend this book, the ideas in it are interesting and provocative. I have already successfully tried some of the automatic testing approaches in practice. I would like to try pair programming, but how does one persuade one's management, when one is in a small team, under pressure to deliver?
Rating:
Summary: Slim volume is a good primer on a lightweight methodology
Review: Caveat: I have never worked in an XP shop, that is, a software shop that puts into place all the principles of XP. However, many shops I've worked in have put one or more principles described in Kent Beck's book into effect, and in those cases, those processes made a remarkable difference in the ability to deliver products on time and under budget. This thin book is a great place to get some great common sense -- e.g., that it's futile to assume that if you just spend enough time in "design phase" that the software project will go better. Very practically, every successful project I've worked on has had architects that coded, has had continuous integration and testing, lots of developer communication and cooperation, and strove always to maintain short development cycles with lots of customer feedback. Beck's book is direct, straightforward and undogmatic. It's also lighweight and concise itself, a considerable virtue in this field. I recommend it.
Rating:
Summary: Not Software Engineering.
Review: Any Engineering discipline is based on solid reasoning and logic not on blind faith. Unfortunately, most of this book attempts to convince you that Extreme programming is better based on the author's experiences. A lot of the principles are counter - intutive and the author exhorts you just try it out and get enlightened. I'm sorry but these kind of things belong in infomercials not in s/w engineering.
The part about "code is the documentation" is the scariest part. It's true that keeping the documentation up to date is tough on any software project, but to do away with dcoumentation is the most ridiculous thing I have heard. It's like telling people to cut of their noses to avoid colds.
Yes we are always in search of a better software process. Let me tell you that this book won't lead you there.
Rating: 
Summary: radical views on software development, food for thought
Review: Now this is a controversial book that has caused a lot of heated debate among developers. It starts out innocently enough, by stating the goals of XP which most everyone will agree on: correct, flexible software that adapts well to change in requirements and user-feedback, short development times and happy programmers and customers. It then goes on to explain how the techniques of XP try to help archive these goals. The practices include widely accepted ones, like a rigorous testing process, coding standards and continuous integration. But it also breaks quite radically with common programming wisdom by requiring things like an on-site customer, refactoring as a major component instead of a complete up-front design, pair programming (two developers sharing one keyboard and one screen) and collective code ownership (every one on the team is responsible for the whole codebase and allowed to modify every line of it). It is this mix of proven techniques taken to the extreme and new approaches presented in the book that Beck claims creates a special synergy which leads to a more successful and less strenuous software development process. The author puts forward very convincing arguments for why and how these synergetic effects occur and presents his personal experience using XP on one team as supporting anecdotal evidence. The book is written in an easily readable style and contains lots of sometimes funny anecdotes and quotes. And although it obviously is about the author's pet idea I didn't find it preaching, but rather refreshingly enthusiastic and energetic.
Unfortunately I have to admit that I haven't yet personally experienced all XP techniques in practice, main reasons being that it's very hard to convince management of it's merits ("What?! Two programmers on one keyboard?! No way!") and to get all team members willing to try something new. Maybe if they'd all read this book it would be easier...
In the unlikely event that the ideas don't intrigue you, you still have to buy this book to know what all the hype and controversy is about.
Rating:
Summary: XP - Highly recommended reading for developers
Review: According to Ken Back, Extreme Programming (XP) is a discipline of software development that is based on 12 practices. Most of the programmers out there have exercised some of these (if not all) XP practices for a long time, so these may not be new stuff to them and in software development, in general. However, using them as a guideline for a project is what makes a programmer an eXtreme Programmer. The book is very easy and fast to read. Take a look at it, you might improve your existing and learn some new programming skills. I would say, one of the strongest points in this book is testing. Testing is something I would, most of the time, like to pass on others or leave as a final step in the development face. Ken suggests to write the test first, and test your code at all times - think about it. Another valid point would be simple design. A program written with XP is the simplest program that meets the requirements. Other practices include: planning process, small releases, metaphor, refactoring, pair programming, collective ownership, integration, 40-hour week, on-site customer and coding standards. Enjoy!
Rating: 
Summary: Concise and Useful
Review: I started the book y'day, and by the time I finished reading the first few pages, I could draw parallels to my previous Work Experiences. The book is very clear and concise, and presents facts as they are. The XP paradigm is very useful for small to medium projects of 5 to 30 pple spanning around 3 to 10 mnths. The best part seems to be the emphasis on Testing as an Integral part of the Development and Communication are known facts too. Overall, I would give this book a thumbs Up, must read for all individuals, who have worked in small to Medium projects.
Rating:
Summary: Useful even for the unextreme
Review: Extreme Programming Explained is a great book even for those who don't care for extreme programming, because this book explores issues which are fundamental to programming. It then shows how extreme programming attempts to address the issues. Thus it will make you think, and likely suggest improvements to whatever methodology you are using. Also, if you don't know what extreme programming is, this book is an excellent introduction.
Rating:
Summary: Most important software development book this decade!!!
Review: I LOVE this book. The first time I heard of this book, I thought my buddy was joking. The title conjured up images of programmer's jumping off bridges with laptops. Needless to say, I did not read the book then (a big mistake). Later, I read it, and I really enjoyed it. My feelings are that this is a good book, but it is not complete. It introduces XP, but it is hard to apply XP with just this book. In my opinion, you need the book "Planning Extreme Programming" by Kent Beck, and Martin Fowler and this book to start really implementing XP. We implemented XP with just those two books. Don't worry, they are both small books and you could read them both in a weekend. My observation about XP: Pair programming is a tough concept to get and sell, but it can really help a team quickly grow in leaps and bounds! It helped our team a lot. We were amazed since everyone including myself was a bit skeptical about pair programming. I could go on a long time about the benefits of pair programming. Continous Integration (CI) and automated testing go hand in hand with refactoring. Without CI and automated testing you loose liquidity in your code base, and it is hard to add new features. Your project becomes rigid, and brittle without CI and automated testing. There are other key points I could go on and on about. This book is the most important software development book in the last ten years. Even if you cannot apply XP where you work, you should at least know what it is all about. XP has evolved since this book was written and I look forward to Kent Beck's next edition of this book (if one is in planning). Why are you still reading this? Go buy a copy of this book already.
Rating:
Summary: Good Book
Review: I bought this book; and believe me, it's a good guideline to Extreme projects. You don't need experience to read this book. It's an excellent teacher about practice reviews and explanation.
| 
