Rating: 
Summary: Great book on one approach to software development
Review: I believe in the "think first, program later" school, but the author Ken Beck makes a strong case for what I call "design a little, then test, then program, then repeat many times" school of incremental programming. The author calls it "extreme programming."I thought the book was easy to read yet contained very important topics. Even if you don't agree with the author on releasing many small versions of your software, you will find many useful ideas here. At least I did. I don't fully agree with the author, but I can see several kinds of situations where it applies (where specifications are unclear, for example, which is often). His approach would not be considered prototyping. The approach relies on many software builds, and the use of automated testing to reduce risk and increase confidence in the software. His comments on options pricing models and software was excellent, but could have been developed more. I think this might have been confusing for non-financially oriented readers. I plan on using several of his recommended techniques. The only weak point of the book, was that I didn't fully understand how to implement the automated testing that he recommends. This looks very powerful, after he described the ramifications on the software cost curve. I guess I'll have to learn this from another source. I see that another book is anticipated by the author in December of 2000. I plan on getting that book as well. Overall, I highly recommend this book. John Dunbar Sugar Land, TX
Rating:
Summary: This book shouldn't be useful
Review: But unfortunately it is..and badly! It is a
very clear, effective introduction to the development
style and discipline that 's trying to give control of software development back to programmers and away from dumb managers,
fluff vendors and the like. It does so through the application of a minimum of common sense and encouraging the creation of simple, effective software over the production of heavy, useless documentation. A useful conversation with a "good programmer with great habits".
Rating: 
Summary: Embrace change
Review: "Extreme" programming (XP) is a relatively new software development methodology which aims to allow small teams to produce higher quality software in less time, with less stress. The only thing that possibly exceeds the fervor of its adherents is the scorn heaped upon it by skeptics. _Extreme Programming Explained: Embrace Change_ is "the XP manifesto", which lays out the basic tenets of the XP idea, discusses the philosophy behind the principles, and delves into actually implementing XP in a programming team. I found the book to be a quick read, and I'm sure if you're about to start working with an XP team (in either a developer or a customer role), it would be a good place to start familiarizing yourself with the theory and practice of Extreme Programming. The first third of the book lays out the principles and the theory behind Extreme Programming, and reflects on how the realities of current software development don't match up with classic development methodology that well anymore (if they ever did). By the end of this section, if you've been involved with any sort of structured software development, you'll be nodding your head in agreement and/or cringing from the painful memories of past failed projects. The middle third of the book starts out with a high-level overview of the mechanics of the XP process, and then quickly gets into the nitty-gritty of carrying out the distinct steps: The Planning Game, small releases, pair programming, collective ownership, refactoring, testing, and all the rest. Even if you don't go for full-bore XP practices, there should be something in this section that will make you re-think some of your practices. The final third of the book deals with practical considerations of implementing the XP methodology for software development, including when you shouldn't try to use XP. This section, with recountings of commonly encountered problems, and descriptions of the different roles often filled by XP programmers, will be the most valuable for someone trying to actually turn theory into practice. Overall, I found the book to be a quick, interesting read, and it was fun to consider how some things at my workplace would happen differently if some XP practices were to be adopted.
Rating:
Summary: Great introduction to XP with practical examples
Review: In this book, managers, developers, interaction designers, and methodologists will all find a fresh perspective on the software development process, XP (extreme programming). At first, the usability world may look upon the ideas presented in this book as not only extreme, but also completely opposite of what they have found to be true with other more traditional methodologies. In fact, as you study the principles outlined in the book, you will likely find that they are simply a minimal instance of more traditional methodologies such as RUP (rational unified process). This book provides a clear and concise overview of twelve core 'best practices', which comprise XP. It then provides examples and techniques for implementing and promoting XP in a typical development environment. The XP process outlined may not be right for your team or project, and the author acknowledges this early and often throughout the book. Nonetheless, many teams around the world with 4 - 12 developers are achieving excellent results based on the principles outlined in this book, proving that XP is more than just undisciplined hacking or 'cowboy coding' without regard for architecture or usability. As usability practitioners, we are exploring ways to integrate usability successfully into projects adopting the XP process. Unfortunately, the book makes little mention of how to accomplish this critical step in delivering usable software. On a positive note, usability and XP share the common goal of not overdesigning your system. The book is a good starting point to discover if XP is right for your project and team or to take some of the principles outlined and apply them to your existing development practices.
Rating:
Summary: Develop Reliable Software Rapidly and Enjoyably
Review: In this short and delightful book, Beck presents the underpinnings of the discipline of software development called "Extreme Programming", or XP. He tells us why the discipline works and the basics of how to do it. (More books are forthcoming, but start here.) The book addresses lightweight approaches to customer communication, architecture, design, testing - the whole cycle of software development. XP isn't for everyone: it is for people who have been and want to be passionate about programming, who want to do a good job in today's fast business environment, who are team players, and who are willing to be disciplined about how they do their work. Hackery? Hardly. Those who fear that XP is "hacking" have not read or do not understand the book. XP is highly disciplined, including more customer contact, more testing, and more design than most projects ever see. Required Warning: I'm the "self-proclaimed least" of the folks working with XP and writing about it. So I'm biased. I'm biased for a particularly good reason: I had the chance to try XP in its purest form, on a project that had been in trouble. I wasn't sure everything would work - and where it didn't, we changed and improved the process. That learning is now in the book. I was often surprised by the way XP allowed a team of ordinary humans to consistently delight their customers. To get the benefits, you have to do the process. Beck has given us the first volume of information on how to build software better, faster, and with more enjoyment.
Rating: 
Summary: eXtreme buzzwording
Review: Maybe it's an interesting idea, but it's just not ready for prime time. Parts of Kent's recommended practice - including aggressive testing and short integration cycle - make a lot of sense. I've shared the same beliefs for years, but it was good to see them clarified and codified. I really have changed some of my practice after reading this and books like this. I have two broad kinds of problem with this dogma, though. First is the near-abolition of documentation. I can't defend 2000 page specs for typical kinds of development. On the other hand, declaring that the test suite is the spec doesn't do it for me either. The test suite is code, written for machine interpretation. Much too often, it is not written for human interpretation. Based on the way I see most code written, it would be a nightmare to reverse engineer the human meaning out of any non-trivial test code. Some systematic way of ensuring human intelligibility in the code, traceable to specific "stories" (because "requirements" are part of the bad old way), would give me a lot more confidence in the approach. The second is the dictatorial social engineering that eXtremity mandates. I've actually tried the pair programming - what a disaster. The less said the better, except that my experience did not actually destroy any professional relationships. I've also worked with people who felt that their slightest whim was adequate reason to interfere with my work. That's what Beck institutionalizes by saying that any request made of me by anyone on the team must be granted. It puts me completely at the mercy of anyone walking by. The requisite bullpen physical environment doesn't work for me either. I find that the visual and auditory distraction make intense concentration impossible. I find revival tent spirit of the eXtremists very off-putting. If something works, it works for reasons, not as a matter of faith. I find much too much eXhortation to believe, to go ahead and leap in, so that I will eXperience the wonderfulness for myself. Isn't that what the evangelist on the subway platform keeps saying? Beck does acknowledge unbelievers like me, but requires their exile in order to maintain the group-think of the X-cult. Beck's last chapters note a number of exceptions and special cases where eXtremism may not work - actually, most of the projects I've ever encountered. There certainly is good in the eXtreme practice. I look to future authors to tease that good out from the positively destructive threads that I see interwoven.
Rating: 
Summary: Extreme Bull
Review: Mr. Beck has managed to write a book based upon his own opinions and theories, not of which are based upon facts or solid research, and sell this idea as a development methodology/paradigm shift. More power to him for his own marketing ability. I do have some respect for him as a developer after reading Refactoring with Martin Fowler as the primary author. My Ph.D. work was done on how technology affects the coomunication and learning process. And I have 14 years of experience watching students work in teams on programming problems. What Mr. Beck writes about the paired-programming aspect is contrary to common sense and anyone even the slightest inkling of perception into the personality traits of developers. He does make some good points about manamgement, and time estimates. Unfortunately the good things are mixed in with the fantasy. I've yet to encounter a software/technology manager and very few developers that have the people skills; or any education or innate ability of learning and teaching styles that would be absolutely necessary for his suggestion to be sucessful. It was my unfortunate (depending on your viewpoint) experience to work with a development team at Intel trying to implement Extreme Programming for the first time. That experience is worth a whole book in itself. I suggest reading the book, take the good stuff, but please don't confuse opinion or limited personal experience as suitable justification for imposing bizzare practices on your development teams.
Rating:
Summary: A work of fiction
Review: The book presents extreme programming. It is divided into three parts:
(1) The problem
(2) The solution
(3) Implementing XP. The problem, as presented by the author, is that requirements change but current methodologies are not agile enough to cope with this. This results in customer being unhappy. The solution is to embrace change and to allow the requirements to be changed. This is done by choosing the simplest solution, releasing frequently, refactoring with the security of unit tests. The basic assumption which underscores the approach is that the cost of change is not exponential but reaches a flat asymptote. If this is not the case, allowing change late in the project would be disastrous. The author does not provide data to back his point of view. On the other hand there is a lot of data against a constant cost of change (see for example discussion of cost in Code Complete). The lack of reasonable argumentation is an irremediable flaw in the book. Without some supportive data it is impossible to believe the basic assumption, nor the rest of the book. This is all the more important since the only project that the author refers to was cancelled before full completion. Many other parts of the book are unconvincing. The author presents several XP practices. Some of them are very useful. For example unit tests are a good practice. They are however better treated elsewhere (e.g., Code Complete chapter on unit test). On the other hand some practices seem overkill. Pair programming is one of them. I have tried it and found it useful to generate ideas while prototyping. For writing production code, I find that a quiet environment is by far the best (see Peopleware for supportive data). Again the author does not provide any data to support his point. This book suggests an approach aiming at changing software engineering practices. However the lack of supportive data makes it a work of fiction. I would suggest reading Code Complete for code level advice or Rapid Development for management level advice.
Rating:
Summary: Embrace change
Review: "Extreme" programming (XP) is a relatively new software development methodology which aims to allow small teams to produce higher quality software in less time, with less stress. The only thing that possibly exceeds the fervor of its adherents is the scorn heaped upon it by skeptics. _Extreme Programming Explained: Embrace Change_ is "the XP manifesto", which lays out the basic tenets of the XP idea, discusses the philosophy behind the principles, and delves into actually implementing XP in a programming team. I found the book to be a quick read, and I'm sure if you're about to start working with an XP team (in either a developer or a customer role), it would be a good place to start familiarizing yourself with the theory and practice of Extreme Programming. The first third of the book lays out the principles and the theory behind Extreme Programming, and reflects on how the realities of current software development don't match up with classic development methodology that well anymore (if they ever did). By the end of this section, if you've been involved with any sort of structured software development, you'll be nodding your head in agreement and/or cringing from the painful memories of past failed projects. The middle third of the book starts out with a high-level overview of the mechanics of the XP process, and then quickly gets into the nitty-gritty of carrying out the distinct steps: The Planning Game, small releases, pair programming, collective ownership, refactoring, testing, and all the rest. Even if you don't go for full-bore XP practices, there should be something in this section that will make you re-think some of your practices. The final third of the book deals with practical considerations of implementing the XP methodology for software development, including when you shouldn't try to use XP. This section, with recountings of commonly encountered problems, and descriptions of the different roles often filled by XP programmers, will be the most valuable for someone trying to actually turn theory into practice. Overall, I found the book to be a quick, interesting read, and it was fun to consider how some things at my workplace would happen differently if some XP practices were to be adopted.
Rating:
Summary: Profound and Cohesive
Review: Kent Beck has pulled together many simple software development values and principles into a profound and cohesive book (and methodology). It is so simple yet I do see this as a real challenge for some IT departments to accept and utilize...but it's how software should be developed any more...or at least this should be the initial approach (keep it simple). He explains so well how, why and when it can and can't work. I really enjoyed the short and consice chapters. It's extremely easy to follow.
| 
