Rating: 
Summary: Some very good ideas and some questionable ones
Review: First off let me say that this book is well written. Whether or not you agree with the ideas I do not think that you will find a better presented description or argument in favor of the methodology.The book has a lot of plain common sense (which is not really all that common): Work with simple designs and short release cycles; build testing into the development process; do integrated testing all the time; always get someone to review the code design and check the final code. My biggest complaint is the attitude toward documentation - namely that it is unnecessary. What happens when the program completes all the tests and the design team disbands to work on new programs? A few months later the client is prepared to pay for enhancements. I know that when I move on to a new project my memory of the previous one evaporates. I sure wouldn't want to have to reverse engineer the program specifications from the test plans. The good news is that the documentation need not be very complex. A few data flow charts do a good job of giving the big picture. In-line documentation is not difficult once you get in the habit of doing it as you code. There should be two levels of in-line documentation - one for someone who wants to just make use of an object and one for someone who may need to make modifications. The higher level of documentation is also good for code reuse. Why bother writing something new if code already exists that does what you want? The detailed level of documentation helps to answer the question of how big a procedure should be. The documentation should read like a simple story; it should not take more than a minute or so to get a general understanding of how the procedure is put together. If it takes longer the procedure is too complex. I recommend reading this book for both programmers and managers. Just keep an open mind for both its strengths and weaknesses.
Rating: 
Summary: Well Thought Out Developmental Methodology
Review: While short, terse, and delightfully well written, Kent Beck has put together a book which describes a carefully thought out and revolutionary approach to software development. You wouldn't be sitting there reading this review unless you were already perplexed by the difficulties of traditional waterfall and phased development models. Those of us that have lived through countless mega-million dollar corporate efforts that have suffered from poor code and misunderstood design have known for a while that something is wrong with the paradigm, but we are too willing to blame the problem on customers or managers to consider that we might have been doing it wrong. Beck offers a very effective, rapid iteration model that really can produce working results in short order. This is based on a set of practices, some of which are a bit surprising, but which work together quite well. Beck proposes that business drivers, coupled with technical estimates, used iteratively drive the planning. He emphasizes small releases, simple design, and a coherent system metaphor. Automated, continuous unit testing, based on requirements builds a test set which encourages refactoring of the code. Refactoring plus frequent (even daily) system building and testing helps to reduce late project test crises. Beck feels that pair programming, a limited work week, and a sense of collective ownership build effective development teams. Other important factors are the presence of on-site customers and good coding standards. Whew! Sounds like a lot. But Beck makes sense of it all, and presents his approach clearly and with winning style. This is a very easy read, and one that may change your whole approach to development.
Rating:
Summary: Interesting!
Review: After years of developing software and praying for the day I get to actually do a project right: spending 60% of the time designing, up front, and then spending 25% of the time cranking out the code and another 15% testing - to deliver the perfect software package on time... I never really thought that maybe we were just going about it all wrong. Extreme Programming (or XP) is a conglameration of ideas about software development that aren't new but are proposed in a coherent manner to actually create a new methodology. The fundamentals are: always code to the existing design - throw out code that anticipates future needs, never work overtime (unless it's for a very specific reason), code in teams so there is 100% code review, always end the day with a working build. The methodology is much more realistic (according to my experience) and Beck provides a great introduction to it.
Rating: 
Summary: The "gossip magazine diet plans" style of programming.
Review: This book reminds me of the "gossip magazine diet plans", you know, the vinegar and honey diet, or the fat-burner 2000 pill diet etc. Occasionally, people actually lose weight on those diets, but, only because they've managed to eat less or exercise more. The diet plans themselves are worthless. XP is the same - it may sometimes help people program better, but only because they are (unintentionally) doing something different. People look at things like XP because, like dieters, they see a need for change. Overall, the book is a decently written "fad diet", with ideas that are just as worthless.
Rating: 
Summary: If you're really that curious about XP.....
Review: I would recommend this book to any software modeler-geek that just loves to read books about the software development process. Certainly XP is not a lazy alternative to UML. If you are new to programming I would pass up this book without a second thought. I do not care for XP, so I could'nt recommend this book to anyone but the serious, serious software development process GURU who wants to have read everything. But if you're really that curious this book will (try) explain it to you.
Rating:
Summary: Excellent Read
Review: This has been my favourite book which I have been carrying around. The size of it is just nice for reading on the bus or on the train. This book describes about what XP is, without being biased. It is enjoying to see how several simple concepts are being put together to make software development a joyful process for everyone, the programmers, the management as well as the customers. I have been advocating XP in my company without much success. If only they can be less sceptical and less biased and pick up a copy of the book to read, I believe everyone would benefit from it. I urge you to do so also. This book is IHMO one of the best book I have ever read.
Rating:
Summary: a refreshing alternative to traditional methodologies
Review: Many see XP as the nemesis of the Rational Unified Process when in fact these two methods when combined provide the synergy needed to boost your software development projects to a new level. eXtreme programming explained is a very good introduction to XP, an innovative method of developing software that is beginning to revolutionize the previously held thoughts that a development method has to be a bulky and heavy process to implement in the new wave of high tech projects. XP is a methodology that is based on making the process of programming complex systems as simple as possible while at the same time maintaining quality through the use of unit testing and iterative integration throughout the development process. Of all the great ideas that XP presents, probably the most significant is the notion that the cost of change curve has gone from an exponential curve to one with an initial high rate of positive change and then a flattened curve with a decreasing rate of change. Beyond this being a very strong statement backed by great minds such as Martin Fowler, it is something that goes against what many other great minds have come to expect from software development. This is based on the fact that new programming languages and environments along with better design principles such as component based development allow software to remain resilient to change, thereby making that exponential cost of change curve a factor of times past, so much for our Software Engineering classes in college. So in general, XP presents some new ways of thinking for engineers who are used to more traditional ways of developing software. XP explained is a good book to get you introduced into the methods but not nearly enough to get you started in XP projects, for that you'll have to check out one of several web sites with more in depth examples and case studies that will help guide you through your own projects. Never fear though, there are a couple of books coming out soon to help you out in implementation details, you can get them right here on amazon, just search for extreme programming, I've read the final draft for one of the books and if you are at all interested in XP these books are must gets. I also highly recommend reading " The Rational Unified Process, An Introduction, second edition", also available here on amazon. This book provides a different perspective on developing software, one that must be taken with a grain of salt and an open mind, much like XP. I recommend anyone interested in improving their development process to try and look at as many methods as possible and try to see the similarities in them to get a better perspective on what makes for a good process method. For those of you who need help getting a handle on these subjects, feel free to drop me an email and I'll be glad to help anyone out and guide you to more information online.
Rating:
Summary: for all developers
Review: This book is for an understanding of XP, not an how-to book, as author explains. Book is organized of short chapter(3-4 pages), each makes you think of problems you previously had in software projects. Author explains the problems we all have in software projects very well and states easy solutions. I think this book is a great introduction to XP.
Rating:
Summary: Explained is the key word...
Review: This book does a very good job of explaining what eXtreme Programming is. It does not promise to provide all of the details of successfully implementing and using XP (which is stated in the Preface), but it does give a very good introduction to XP. If you are considering XP, this is a good book to help you decide. Perhaps, other books in the Beck/Gamma series would provide more details (I haven't read any others yet.).
Rating:
Summary: Read this book with an open mind
Review: I love this book. When I first read it, I agreed with many points discuss in the book, but I was also skeptical about many points Kent was trying to make. Overtime, I noticed that a lot of problems in my previous organization can be solved by adopting methodology discussed in this book. I suggest anyone reading this book to be open minded and notice how XP can solve problems in your organization. I believe ideas in this book can make any software development group better.
| 
