Rating: 
Summary: Concise yet thorough explanation of XP
Review: If you are considering Extreme Programming, you should read this text. The book is divided into 3 sections -- 1) The problem , 2) the solution, and 3) the implementation. The problem covers the 4 basic values of Extreme programming
1. Communication
2. Simplicity
3. Feedback
4. Courage And it also covers the basic practices that support these values -- namely incremental delivery, unit testing, collective ownership, and paired programming. The solution goes into more detail on the strategies behind the practices. Section 3 imnplementing XP covers roles for people, and strategies to make an XP implementation successful. If you are familiar with other agile approaches like Scrum, most of the material will be familiar to you. Unlike some other agile approaches, this is a full lifecycle approach and the author covers project management, design, programming, and testing.
Extreme programming advocates decentralized decision making, but there is a good section on the role of the manager or coach. Some of the practices depart from conventional SW Development wisdom. For example, there is a good explanation of how the cost of a change may not rise drastically over time. The text covers metric collection and discusses velocity -- ratio between estimated development time and calendar time. However, I wish there was more time spent on ways to communicate these metrics to the team and management. Overall, great introductory to Extreme Programming and a good reference.
Rating: 
Summary: A good read
Review: This book does an excellent job of painting an accurate portrait of a methodology that has been hyped as the salvation for all programming ills. It's clear that XP is just another methodology and is limited to very specific types of programming environments and corporate cultures.
Rating:
Summary: Great book and a Successful Philosophy
Review: Beck's book is an outstanding summary of a great development practice. I picked up his book for no real reason, but was so compelled by the arguments, that our little software development group implemented (most of) his suggested practices. Naysayers can say what you would like - 5 appplications and 5 contracts later, our company is growing, the customers are happy, the applications are in widespread and increasing use. This book describes a revolution built upon common sense.
Rating:
Summary: Embrace Change!!!!
Review: Kent presents controversial concepts into software design with some very interesting ideas that I wish I could observe to see if in practice XP would work. When I am reading the text I am thinking this is very idealistic and not realistic. It is not to say that a good group of people could chose to use such a system, however it is my opinion their are specific number of individuals in a development team who tend to be intellectual snobs, selfish knowledge hogs, selfish code hogs, ruler dominators of the project, or those whose knowledge is outdated that they resist change for the sake of job security. If XP were enforced these type of people would be blown away in the design team environment. XP is a collective effort where talents of the individual work for the greater good of the project, not for glory of the individual so that they look good and get raises or promotions or derive power. A concept foreign to most intellectual snobs who see the whole design but refuse to share information in order maintain control and power over the project. Therefore, for XP to work, one has put the project above his or her own ego. XP also demands the obliteration of office politics and the institutions that harbor power. Kent describes managers as guides not as enforcers, because no one likes to be told what to do. Being told what to do is counter productive. I agree! XP diffuses and replaces power with functionality and the byproduct is productivity. However again for this to work ego has to go and the project is place above the individual. I can see why those who love institutions, structure, those who love power, office politics, bureaucracy and build their careers on concrete absolutes would hate and denounce Extreme Programming. Extreme Programming short circuits the long time tested built pillars of "so-called best practices". Why would these PHD's, experts and long time die hards put their careers at stake? It would be like a hard core evolutionist, embracing creationism in forum of instituionalized evolutionists. The answer is because change means that they are no longer viable, if they do not change. Change will wreck everything! So, its better to stay in the horse and buggy age as long as it puts money in my pockets and puts food on my table. If there is ever a threat to interupt the institution which I support then all that oppose my security must be denounced. I agree with Kent Beck, let's "EMBRACE CHANGE"
Rating:
Summary: Very enlightened and enlightening
Review: I'm about halfway through this book and it is a joy to read. It is so beautiful in its wisdom and simplicity. Extreme programming seems to make a lot of sense as long as your mates are a) Marginal competent,
b) Don't think of pair programming as a struggle for dominance,
c) Can accept criticism without throwing a fit that would embarrass a toddler. Regrettably, none of these traits can be attributed to the pair I currently work with, so this book has inspired me to look for a new job. But I know I won't find myself in the same position since this book has showed me the red flags to look for while interviewing.
Rating: 
Summary: Hackers! Salvation is nigh!!
Review: It's interesting to see the phenomenon of Extreme Programming happening in the dawn of the 21st century. I suppose historians can explain such a reaction as a truly conservative movement. Of course, serious software engineering practice is hard. Heck, documentation is a pain in the neck. And what programmer wouldn't love to have divine inspiration just before starting to write the latest web application and so enlightened by the Almighty, write the whole thing in one go, as if by magic? No design, no documentation, you and me as a pair, and the customer too. Sounds like a hacker's dream with "Imagine" as the soundtrack (sorry, John). The Software Engineering struggle is over 50 years old and it's only logical to expect some resistance, from time to time. In the XP case, the resistance comes in one of its worst forms: evangelism. A fundamentalist cult, with very little substance, no proof of any kind, but then again if you don't have faith you won't be granted the gift of the mystic revelation. It's Gnosticism for Geeks. Take it with a pinch of salt.. well, maybe a sack of salt. If you can see through the B.S. that sells millions of dollars in books, consultancy fees, lectures, etc, you will recognise some common-sense ideas that are better explained, explored and detailed elsewhere.
Rating:
Summary: A picture is worth 1000 words
Review: #1
Perhaps the most illustrative anecdote is on page 78, where the author includes a picture of what pair programming looked like in "The DaimlerChrysler C3 work area". They trusted their payroll system to XP.
It's an unfortunate choice of words: "Extreme".
I'd use the phrase "Team programming" if you work for a corporation - that seems to fit right in.
#2
How would you feel if there were a button on your application labelled "test", and when you clicked on it, it ran a battery of tests that all returned 100% correct? Would that boost your confidence maybe? That's one of the concepts behind TDD (Test Driven Development). I call them diagnostics, because testing can be confused with "testing something before it goes into production".
This is for after it's gone into production.
"Is the system working?" asks the boss.
"I don't know, let me see" you say. You press the "test" button, and it returns a yes.
"Yes it is".
Similarly, any new development that you do must be accompanied with a test of its own.
Rating:
Summary: Interesting and informative reading
Review: The concept of extreme programming (XP) is new and interesting, though its probably not used in a lot of large software organizations, who tend to be bent on SDLC (for reasons that would become obvious when you read the text). It talks about design principles when building software that isn't considered critical (e.g. real-time applications) and when programmer count is less than 10. Has interesting principles on peer programming, testing, requirements gathering and refactoring. It kinda takes the approach of do what you have to do now, and worry about adding more functionality later, if necessary. Some of its philosophies can be adopted into the design principles you're currently using, but the author states that if you dont follow it all, then your not fully practicing XP. A good read, adds to your insight of the design processes out there. Its good to have an idea of different design processes so you can pick one that suitably applies to what you're currently working on. I applied it in a team of about 10 programmers on a school project, and when programming with a partner on a project, using XP was actually fun.
Rating: 
Summary: Good quick introduction to subject.
Review: This is a short simple explanation of the new discipline of 'Extreme Programming'. Fast to read, easy to understand. So much for the book. I have doubts about Extreme Programming, it seems either unworkable or something we already do anyhow (contradictory statement, i realize!).
Rating: 
Summary: Programming Malpractice Explained: Justifying Chaos
Review: To fairly review this book, one must distinguish between the methodology it presents and the actual presentation. As to the presentation, the author attempts to win the reader over with emotional persuasion and pep talk rather than with facts and hard evidence. Stories of childhood and comradeship don't classify as convincing facts to me. A single case study-the C3 project-is often referred to, but with no specific information (do note that the project was cancelled by the client after staying in development for far too long). As to the method itself, it basically boils down to four core practices:
1. Always have a customer available on site.
2. Unit test before you code.
3. Program in pairs.
4. Forfeit detailed design in favor of incremental, daily releases and refactoring. If you do the above, and you have excellent staff on your hands, then the book promises that you'll reap the benefits of faster development, less overtime, and happier customers. Of course, the book fails to point out that if your staff is all highly qualified people, then the project is likely to succeed no matter what methodology you use. I'm sure that anyone who has worked in the software industry for sometime has noticed the sad state that most computer professionals are in nowadays. However, assuming that you have all the topnotch developers that you desire, the outlined methodology is almost impossible to apply in real world scenarios. Having a customer always available on site would mean that the customer in question is probably a small, expendable fish in his organization and is unlikely to have any useful knowledge of its business practices. Unit testing code before it is written means that one would have to have a mental picture of what one is going to write before writing it, which is difficult without upfront design. And maintaining such tests as the code changes would be a nightmare. Programming in pairs all the time would assume that your topnotch developers are also sociable creatures, which is rarely the case, and even if they were, no one would be able to justify the practice in terms of productivity. I won't discuss why I think that abandoning upfront design is a bad practice; the whole idea is too ridiculous to debate. Both book and methodology will attract fledgling developers with its promise of hacking as an acceptable software practice and a development universe revolving around the programmer. It's a cult, not a methodology, were the followers shall find salvation and 40-hour working weeks. Experience is a great teacher, but only a fool would learn from it alone. Listen to what the opponents have to say before embracing change, and don't forget to take the proverbial grain of salt. Two stars out of five for the presentation for being courageous and attempting to defy the standard practices of the industry. Two stars for the methodology itself, because it underlines several common sense practices that are very useful once practiced without the extremity.
| 
