Extreme Programming Installed

People are starting to take XP very seriously simply because it delivers quality code instead of just documents about code. The core philosophy can be summed up: "A feature does not exist unless there is a test for it." (P.83) This means that coders (pairs of programmers in XP) first construct unit tests of product features before the attempt to code the features. What this means in practice, is that the code that XP delivers (continuously in 3 week long iterations) can never be broken! I'll say that again just to make sure you read it: XP code can never be broken! I really think XP's adaptive, test-first philosophy is the best thing that has happened to software engineering since Dijkstra told us that the "Goto Statement is Considered Harmful" in 1968.This book is the best of the XP series if you've actually made the decision to use XP. If you're not sure about what XP is or what it's limitations are, go to google and do your homework. When you're ready to actually install an XP project, get this book.

Extreme Programming (XP) is a software development methodology. This is no ivory tower, academic exercise; the authors have used XP on large-scale projects and seen it work. This book is an introduction to XP for programmers. Chapters tend to be short and easily digested. The language is somewhat casual.XP advocates unit testing and code review. Okay, what's so extreme about that? Unit tests are fundamental to the process. Tests are frequently written before the code to be tested. There should be a test for anything that could possibly break. Tests are run frequently and must run at 100% before integrating code. Note that refactoring (see Martin Fowler's "Refactoring") is an XP practice and is sensible only where there is an extensive collection of tests. Code review takes the form of pair programming. That is, two programmers sitting side-by-side, one driving and the other paying close attention to the task at hand. So, it's continuous code review.Some of the other practices are simple design, coding standard, continuous integration, small releases and forty-hour week. All of the practices are directed toward simple, quality code with the highest business value (as determined by the customer) written against milestone deadlines that become increasingly accurately gauged.I highly recommend this book. I would expect other experienced programmers to react as I do that XP makes good sense. It may be difficult to sell, but it is worth the effort.

Once the theory has been assimilated, it comes time to execute. From the theoretical side, Extreme Programming(XP) is intuitively obvious. However, as we all know, theory and practice sometimes have only a passing acquaintance. Implementing and maintaining the principles of XP requires many traits, some of which are all to rare. Since XP does not allow for the slipping of a deadline, it is sometimes necessary for someone to summon up a good deal of courage. It may be necessary to go to a supervisor and lay the cards on the table and say you can't have it all. Since those cards would contain a list of the requested features, this is guaranteed to make you unpopular. If that supervisor is one whose idea of motivation is to raise the level of fear and hours of uncompensated overtime, then it could be your last act at that company. That possibility is the one area where I have concerns about this book and XP in general. To implement it requires the commitment of all persons in the chain of command. If at any point someone at one level gives up the faith, then it is hard to see how it can be recovered. This book is a story of how XP looks when it is being used as described. Although somewhat idealistic in its premise of forty hour weeks, limited overtime and keeping the goals within reach, there is no doubt that as described here, it does work. In fact, to most programmers, it sounds like the ideal work environment. For some time, I have pondered the choice of the word extreme to describe this mode of programming. After reading this book, I now understand why it is applicable. Using the XP method to build software requires extreme commitment from all parties to the endeavor. From the customer to the programmers up to the highest levels of management, everyone must believe in it. In the end, XP will rise or fall based on the performance of those who adopt it. If they create programs cheaper, better and with more features, then it will be adopted. If not, then we will see a return to the locked in the cubicle mentality. However, it must be implemented in its entirety to be properly tested, and this book will show you how to do that.

I am writing a new review. I mentioned, in my previous review, that I am acknowledged in the credits as having contributed, but I don't think I wrote a clear review. In a nutshell, this is one of the few programming books I keep right next to my keyboard for sound advice on Unit Testing and a variety of software construction, even though the company I am at does not do full XP (yet). The book assumes you have bought the concepts in "Extreme Programming Explained." While that is a great book, it is theory and one is still left with "Well, how do I do it?" This book shows you step by step. One of the problems I had in the previous book and on the Web, was understanding User Stories and User Story Estimation. This book leads you through the process. One of the wonderful things about Extreme Programming is that it is a lightweight, yet rigorous process. In this day of huge process like CMM and ISO9000, which most programmers totally reject, XP is light enough and common sense enough to be adopted. In fact, many of the pratcices in this book are totally useful even if you have not totally adopted XP. Example: At my current company, we need to add Unit Tests fast. This book gave me the step by step procedures to do just that. The book covers in detail all the XP practices with examples. One of the only downfalls of the book is that a lot of the examples are in Smalltalk, a language that the authors favor, but few use. I had a hard time with the examples, however I finally understood them, and there is a Java section. Overall, XP is a revolution in software development and this book is the guide!

This is the second(or was it the third?) book in the XP series. If you are a manager, try to decide whether to use XP, try the "XP Explained" book instead. This book is for people who buy the concept of XP, and wants to know how to implement it in their workplace. But this book is definitely beneficial to anyone, as they are applicable everyday, even if you are not practising XP. While books like "The Unified Software Development Process" left me in a complete daze, XP Installed leads me step by step on how to go about doing XP. An good example would be getting "User Stories"(comparable to Use Case), XP Installed teaches you what a "User Story" is, and how to go about writing one.This book is again, of the correct size, easy for carrying around. The authors wrote the book in a concise, no-nonsense matter. There's never a case of you seeing merry-go-rounds :) Unlike other books, this book was previously released to the XP community for reading, feedback and suggestions. The result of it, is a better XP book minus all the flaws which could have been left undetected.This book is a must-have for your bookshelf.