Rating: 
Summary: One of the most important programming books of the 90s
Review: I've been following XP for a few months since the first article or interview in C++ Report. Unfortunately, my primary development platform is VB, and I am trying to see how to do XP effectively in VB - we already do many aspects of XP, originally based on experience and the necessities of the business environment rather than any particular methodology or philosophy. I eagerly await the sequel: Playing to Win, because Embracing Change doesn't really give a lot of concrete help on implementation details like how to actually do the automated tests in any environment (Smalltalk has advantages being used in author's environment, but even an implementation in Smalltalk is not detailed). I can't believe anyone gave this one star. This book, along with Alan Coopers' About Face and Inmates, tilt that balance back to goal-oriented software production, acknowledging that we produce software for real needs and real users in the real world. Methodologies' goals aren't always in line with business and user needs. I still give 5 stars for content and ideas, despite failings as a DIY guide for your project. The lack of details should not detract, since implementation will have to be learned in each case, and the importance of the ideas in this book should not be overlooked.
Rating: 
Summary: Maybe the most important book of the year.
Review: Kent has a knack for looking at things in new ways and explaining them simply and clearly. He is showing us the "middle way" between the usual alternatives of kludging without design and designing as if only the paper mattered. Thanks, Kent!
Rating:
Summary: This book will change the way software is developed
Review: This book will challenge your preconceptions about how software should be developed. It is a direct challenge to the old way of software development where we talked about "Freezing Requirements". It asks us to use the power of Object technology to Embrace Change instead.Extreme Programming is a methodology that allows developers and customers to work together in a synergistic manner. It takes the idea of Incremental and Iterative development and shows how to effectively apply it in the real world to produce business value. This book explains how small teams of developers can work together using a set of self reinforcing practices that enable great productivity and quality. It is about time that a developer has written a book that questions the high ceremony, document centric software development methodologies. What we need is a balance between developer friendly practices such as testing your ideas out using code (often derided as "hacking"), and the need a business has of knowing that their investment in the software will pay off. Not all problem domains will benefit from eXtreme Programming, but that is true of any methodology (and at least eXtreme Programming is up front about the need to check if the process is applicable). To those critics that accuse this book of promoting hacking and ignoring all we have learnt about how to develop software, I suggest that it is time to apply scientific thinking. Try some experiments with your current process, then try some eXtreme Programming experiments and see which give the best results. In summary, a Great Book, Buy it, Read it, Think about applying the lessons of eXtreme Programming.
Rating:
Summary: cleans up the cobwebs in your software development
Review: This is a great book that promotes a set of disciplines that support the management and development of the software artifact. Be warned - this does not promote hacking. But instead, stresses the adherence to a set of disciplines that are geared towards mitigating risk and improving the quality of your software while improving the productivity of the developers. This book promotes continuous attention to the software that is being developed versus a point and shoot (then magic happens) approach. Those that make their money off of promoting big process will criticize this book for its lack of attention to the artifacts that their particular methodology promotes. Yet many of these methodologies do not stress the discipline in evolving the actual software artifact that the XP approach does. This book is very pragmatic in the way it addresses software development. It promotes a shift to cleanup the cobwebs in our current development practices. This shift will cause people to react in different ways (as does any paradigm shift). Many will lash out. Many will find new productivity and enjoyment in their programming. This is a must read regardless of whether you agree or disagree with all of its principles. You owe it to yourself as a developer to understand these ideas. It is a great complement to Fowler's Refactoring book. This book is very approachable for all developers. It provides disciplines that you can quickly apply without having to buy any expensive supporting tools. I am very interested to see how this approach to software development evolves.
Rating:
Summary: A dramaticly different paradigm in developing software
Review: First, this book is not a reference book but instead more of a story. I look forward to Kent writing a more reference-oriented book that cites examples. Some of the concepts, therefor, are vague and left to the readers imagination; I would have preferred if he talked more about testing as it is one of the fundamentals of XP. That being said, there are some unique changes to the standard approach in development. Most specifically: pair programming, automated testing, story-telling, and last but not least, collective ownership. My first reaction to his concepts were both negative and skeptical. As I read on I saw him explain those the things that always bothered me about current design and development approaches that simply never worked (i.e. designing abstracts for the future is just guesswork and often incorrect after a year passes). As I continued, his ideas went from being odd to pragmatic and began implementing them at the company I'm currently working for. We are now starting to better understand XP, and we are in a VB and C++ environment which makes it even more challenging. My team is starting to embrace the concepts and already are looking forward to pairing up and watching the tests run. Its not clear this early in the project the short-term advantages, but if this pans out I can see long-term being far more flexible than our competitors when we need to steer our product down a new path in order to follow our client's needs.
Rating:
Summary: A Monumental work in Software Development
Review: This is an important'' and ''monumental book. I think that this book will have as much of an impact on development pratices as GOF did with Patterns. I can't remember when if ever (maybe UmlDistilled) that I read a technical book all the way through in just two sittings. I've had my share of troubles understanding the essence and even the pratices of XP online here at Wiki. I found some of the topics here too philosophical for me to understand. Not so with this book. What Kent has done so brilliantly is capture XP and explain it in simple terms. It's a small book, it has small chapter, so it is a joy to read. These things really helped but the writing style is so clear and lucid. I found that I couldn't put it down and my excitement growing with each page. The thouhts flashed to convincing everyone I know to read this book as well as Wow! What if I really could work in an XP enviornment! I found particuarly exciting the 40-hour week pratice as I don't think I have seen it discussed anywhere here. "Work no more than 40 hour weeks as a rule. Never work overtime a second week in a row." I just think of all the frenzied places I've worked and their feeling of total loss of control. But even more importantly, this book made me feel excited about being a programmer again.
Rating: 
Summary: an "extreme" departure from well-respected methodologies
Review: This book advocates extreme coding. It's a disguised way to legitimize "dive-into-coding" with no proper analysis and design. This author advocates little if any comments, documentation etc. He actually states that "design is in the code" and documents get out of date and that's an excuse not to do it. How is that in comparison to the "traceability" principle advocated so strongly by Jacobson and Rumbaugh who believe that the final code should be traced back to the analysis documents (use cases in Jacobson book) He advocates programming in pair instead of code reviews! In short, this book gathers the industry "worst practices" exactly the opposite of OMT, OOSE, RUP etc.
Rating:
Summary: This is a hacker guide to the old "dive into coding" extreme
Review: This author is trying to destroy all the great works in object-oriented software engineering that was developed by the great methodologists (Booch, Jacobson, Rumbaugh, B. Meyer, Coad, Yourdon, etc.) This book is trying to bring back chaos and dive-into-coding hacks under a desguised name to make it acceptable. Make no mistake. This is no RUP or OMT or OOSE. This is an attempt to legitimize hacking and chaos that happened many decades ago. Don't waste your money on this and go read the books by Booch, Jacobson, Rumbaugh, Coad, Yourdon, Odell, and Meyer.
Rating: 
Summary: Too emotional for it own good
Review: I have been using Agile programming methods for some time, so I decided to find a book to describe the details of Extreme programming. Extreme programming is an important variant of Agile programming so it is worth studying in more detail.
I bought this book with the expectation that it would be a serious description of how to apply extreme programming and how it relates to other methods. No such luck. The book does explain practices and philosophies, but is primarily an emotional pep talk in favor of Extreme programming. This is to much "Zen" for me. And it seems that the pep talks mostly compared it to the trational waterfall model. In this comparison it is no wonder that extreme programming seems so good. But the book gives seriouos indication of why this method is best; as it claims it is.
So overall, it is an adequate book that does fairly good job presenting what extreme programming is all about but it could have been so much better.
Whatever you do, don't read this book as your first book on software engineering. For that purpose I recommend Steve McConell: Rapid Development. Reading books on agile development should happen after that - otherwise it might be hard to see things in the right perspective.
Rating:
Summary: An expanded vision of XP
Review: If the first edition of this book was a warning shot across the bow of heavyweight methodologies, then this new edition is a call to arms for any team that wants to develop better software faster, and have fun doing it. XP is now being used by teams and in contexts unthinkable when the first edition of this book was published.
This edition is a completely new version of the book. For example, there are new chapters on Taylorism, lean manufacturing, and the theory of constraints. There are many new ideas and XP is now explained more in terms of its values and principles than through strict adherence to twelve specific practices.
In this new edition, Kent Beck expands on the vision of the first and shows us how XP--through the application of its values, principles and practices-has become more than just a lightweight method for small to medium teams. XP represents an evolving way of thinking about software development. I can think of no better person than Kent Beck to show the way.
| 
