Rating: 
Summary: This book is a great read that even I could understand
Review: At one of Kent Beck's talks I went to, he described Xp in terms of "building software like software" instead of like archetectur or craftmanship or mathmatics or anything else. Reading this book, though, it would seem that programing is actually like raising kids. You have to start small, use the simplist thing that could posibly work, make sure everyone does only their job, that everyone contributes and no one is overworked. In a very real sense, everything you need to do Xp, you learned in kindergarten. Take turns, work together, if you break something, fix it, none of the concepts are that dificult, which makes you wonder why some people hate it so much. If you really want to learn the philosiphy behind Xp, take a look at his bibliography. It is a magnificent document on it's own.
Rating:
Summary: A clear and balanced treatment of XP.
Review: A few years ago, Nathaniel Borenstein wrote a fine little book called "Programming as if People Mattered", which is mostly about user interface design. It's almost a shame that the title has been used, because it's also an apt description of Kent Beck's new book. This is a development methodology that acknowledges that developers matter, and that customers matter, too. And they matter in both good and bad ways: Extreme Programming acknowledges that people have rights and strengths, but also that they have weaknesses, and it works with those weaknesses rather than against them. This is a welcome contrast to most of the mainstream software methodologies, where only the methodology seems to matter. Beck and the other Extreme Programming advocates have been in "evangelism mode" of late, and their zeal has occasionally seemed excessive. This book, though, is well-reasoned and balanced. The limitations of XP are freely acknowledged, and Beck argues that in some cases and situations, XP is probably not appropriate. His goal, as the title states, is to explain XP, to help readers understand it so that they can decide whether it's for them. I think he succeeds completely. For such important material, the book is light and easy to read. It's also short and direct. Spend a day or two reading this book, and then spend a week or two thinking about its recommendations in light of your current project. You owe it to all of the people associated with your project who matter.
Rating:
Summary: A dramatic shift in thinking for software development
Review: Kent has pulled off quite a feat: He's come up with a theory of software development that is actually unique, exciting, and inspiring - to managers, to programmers, and to end-users. I first looked into XP around June of this year, on the WikiWikiWeb (c2.com), and was admittedly skeptical. Over the summer I began to look at the problems in my own projects, [I slept at my office 2/3 of the month of July doing overtime] and realized how much practices like unit tests, paired programming, and user stories would help me deliver things on time & without losing as much sleep. XP is one of the most important things to happen to development in years - it will make you WANT to be a programmer (or even a project manager) again. Peter Drucker, in 1964, said: "There are only two things we know about the future: 1) it cannot be known, and 2) it will be different from what exists now and from what we expect. Any attempt to base today's actions and commitments on predictions of future events is futile. But precicely because the future is going to be different and cannot be predicted, it is possible to make the unexpected and unpredicted come to pass. To try to make the future happen is risky; but it is a rational activity. And it is less risky than coasting along on the comfortable assumption that nothing is going to change, less risky than following a prediction as to what "must" happen or what is "most probable". The purpose of the work on making the future is not to decide what should be done tomorrow, but what should be done today to have a tomorrow." Extreme Programming is a way to make the future happen.
Rating:
Summary: The Center of the Universe Has Shifted
Review: XP is to the traditional software development practices as Copernicus' solar system is to Ptolemy's earth-centered system. That is to say XP builds off of what worked well in the past but does not hesitate to throw out the old prejudices that don't carry their own weight.
Rating:
Summary: If nothing else this book has interesting ideas.
Review: Some people will attack it as being a return to cowboy coding, which it isn't. It is instead a new methodology that focuses on creating tests before you code, working in pairs to get an instant code review and other innovative ideas. The methodology seems like it would work with small teams of well motivated people, but it probably wouldn't work in cases where morale is poor (ie: bad management) and it remains to be seen how it will scale up to larger teams. Another part that seems weak is the transition from a rapidly growing system to a stable system with only maintenance work being done. This part is glossed over largely because the author doesn't seem to have had much experience with this (he mentions never being on such a project). Lastly, the question of how big the effect of the Smalltalk origins of the methodology are make it hard to judge their applicability to a non-Smalltalk dev team.
Rating:
Summary: Guaranteed to be a (controversial) classic in SW development
Review: Most "software development" books focus on one of two things: "Big Design Up Front" (BDUF) or "Nitty Gritty Details of Programming" (Hacking). This book does neither. It challenges the idea that disciplined software development implies lots of drawings and a CASE tool. It challenges the idea that "design" is a waste of time and you just need a good code hacker which you slide pizza to under the crack in the door. It speaks for the quietly successful minority of software developers who believe software that is worth anything is built by teams who communicate, and constantly pay attention to all the details necessary to make sure software development is successful in the eyes of both the customer and the software developer. It speaks to those who know "there's got to be a better way" than the way typical software is developed, whether BDUF or hacking. And, oh, how it does it. Kent Beck masterfully makes the developer understand the concerns of the sponsor. He also masterfully makes the sponsor aware of what is necessary to get quality software that meets their changing needs. If you think software is already done right, and refuse to allow this notion to be challenged, ignore this book... you'll hate it. Everyone else having anything to do with software, read it NOW. It will change the way you look at everything you do.
Rating:
Summary: The reader from Irvine, California is ignorant.
Review: XP Projects involve just as much design if not more design than projects using other methodologies. The design takes place at a different time but it exists and is central to XP. I doubt the reader from Irvine, California calling this a hacker guide even read the book. It is also evident that the Irvine reader has not been part of an XP project. Make no mistake about it, this is NOT a hacker guide. Buy this book. You'll be happy you did.
Rating:
Summary: At last a methodology that works!
Review: I highly recommend this book! This book is all about following a strict (but simple) software methodology that actually works in practice to ship quality software. The XP focus is on customer satisfaction with team spirit as a free dividend. The author explains the process eloquently citing real world examples from his extensive experience. XP works, and this book will be the standard XP "Bible" for years to come.
Rating:
Summary: Landmark Book in Software Development
Review: Since I partipated in may of the disussions on the Wiki Wiki Web site and had many of the objections in the begining that the first reviewer had, I feel I am very qualified to give this book a review. It DOES turn everything that those so-called Methodologists sprout on their ear but that is what we need. It is a well-defined process to get software done on schedule and done correctly. Here is my review from Wiki: 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: At Last! A Methodology Book for Greeks
Review: There has always been a dichotomy among programmers: there are the Greeks (who create) and the Romans (who copy the Greeks and build empires). The Greeks wonder why 100 Romans have to sit around and discuss a project for a year before they can start on it when 5 Greeks can sit down and build it (with better quality) in six months. This book tells you how to be a Greek.
| 
