Customer Reviews

Extreme Programming Installed

5 star:		(17)
4 star:		(10)
3 star:		(2)
2 star:		(2)
1 star:		(0)

 

 

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.

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.

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.

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.

This book, as well as "Extreme Programming Applied" by Ken Auer and Roy Miller are the two which should be read by a developer after the introductory "Extreme Programming Explained" by Kent Beck. XP Explained will encourage a reader to the new way of thinking, without bothering with technical details. For a manager it is OK, but for the developer, a bunch of questions will arise. "XP Applied" and "XP Installed" are to answer these questions, providing lots of tips, tricks and case studies.

The only disadvantage is that all the useful examples in these book contain code in SmallTalk, while C++ and Java are popular nowadays. SmallTalk has a distinct, unique style and may frighten C++ or Java developers. That's why I've rated the book four stars.

I would recommend this book to any XP'er.

I'm an XP believer, no doubt about that. And, it's hard to be the one who says something negative in the context of all the positive hype surrounding XP and this book in particular. But, I have to say it: for a methodology that's all about simplicity, this book describing it is vague, chatty, and downright weak in many spots.

The book does not exactly teach you how to do XP. Mostly, it gives you a meandering, blurry outline of XP, throws in an inadequate number of facts and tasks, and fills in the rest with a folksy, down home chattiness about how to approach software engineering. This chattiness can be entertaining at times, but more often it ranges from silly to grating. It gets particularly grating when you realize that you are spending your time reading someone's idea of humor/advice instead of real facts on how to do XP. It starts to bug you after awhile that these people tell you to strive for simplicity and "saying what you mean" in your code, but fail to do the same thing in their book.

Some key facts that are either vague or missing in this book are: what is the relationship between the "points" for tasks in iterations versus the "points" for stories in releases? Is a point really a week or not? How many iterations should one fit into a release (they say about 2-3, but this really needs more discussion)? Acceptance tests, acknowledged by the authors to be a crucial part of XP, get almost no attention or description at all. There is no brief outline that shows how an XP project should run, from beginning to end.

The annoying prose really comes to a head when talking about the aforementioned "points" system, which seems to be the heart of XP planning and estimation. Not only are the authors unclear about "points" in the way I mentioned above, but just look at the place where they introduce the concept:

"We'll estimate story difficulty, using a simple point system. Local naming rules for these points apply. Some teams call them perfect engineering weeks . . . Some projects call them Gummi Bears. No, really . . . Ron's favorite name, this week, is just to call them points. You'll see in a bit that we recommend doing initial estimates by thinking in terms of time. Pass over that for now . . . "

Here we get all the shortcomings of the book wrapped up into one: lack of clarity, a cavalier attitude toward important concepts, and annoying humor. How are we supposed to sell the customer or manager on a controversial new methodology, when the key book describing the methodology casually tells you that you can measure the most important metric of the process with "Gummi Bears", if you'd like? Rest assured that despite what the authors say above, the book never really goes on to elucidate the relationship between points and time. Or, maybe it does, but I lost it in the midst of all the meandering, jokes, and folksy phrases.

Finally, there are a couple of chapters that just do not bear reading: Chapter 7, "Small Releases," is full of a lot of obvious common sense; and Chapter 14, "Test First, by Intention" - what should be a crucial illustration of unit testing - is unreadable to anyone who doesn't know Smalltalk, despite the authors' reassurances to the contrary.

XP is a great methodology, but this is not a great XP book. It could easily have been half as long and twice as informative. I guess I need to look elsewhere in the rapidly growing XP book "franchise" for a clear, no-BS illustration of the process.

This book provides a good parellel to Beck's manifesto (XP Explained), but falls a bit short of Beck's book.

The authors make an effort to try and explain how to apply XP to your job, and succeed fairly well, but infuse their opinion on how some things should be done throughout.

Nonetheless, this is as essential a volume as Beck's, and should be considered worthwhile. Like XP Explained, this one is well written, simple but never childish, and filled with information.

I've read several of the original XP books (Explained & Planning) and to me this is the one that best explains XP and how to implement it. This book was a revolution for me, and I haven't looked at software development in the same way since I read it. It's hard to convert a company (especially managers) to XP, even at a new company on a new project. Managers typically want developers to agree to schedules based on business goals. XP will show you how to do this, but XP won't let you do the impossible. There are tradeoffs, functionality for time. Less time equals less functionality. Sometimes managers just don't understand this (they want it all and they want it now). In that case, it's best to find a new job! But if you are able to apply the XP method, you will love your work, your customer and manager will be happy, and software development will be a pleasant and enjoyable experience.

A final note, I've read this book twice and several sections probably over a dozen times. It can be a little skimpy on details and examples in a few places. I've recently glanced through the new XP books and they give examples and fill in details, but they're expensive and you'd have to spend hundreds of dollars to buy them all and get all the details! Instead look to the web. There's an XP newsgroup (search for it with Google). This book won't take you 100% but it will get you close enough to make it the rest of the way. And of course if you can afford to buy XP Explained and Planning XP I think they're worth it.

I had hoped this book would give practical development techniques for XP theory as presented in Kent Beck's Extreme Programming Explained. Unfortunately, this book takes a step in that direction and then veers sharply off the path. There are some good ideas and new concepts here, but everything is so vague you have to fill in a lot of gaps to arrive at anything useful. Also, I have to say, the tone of the book is so smug and self-congratulatory at times that it really turned me off.

I found Rick Hightower's Java Tools for Extreme Programming offered much more useful XP coding advice. Mr. Hightower's book explains how to use open source tools Ant, JUnit, Cactus, JUnitPerf, and others. He explains where each tool fits into the XP methodology, and gives buildfiles, complete tests, and techniques for using the tools together to build an XP software development process. This book helped me put the XP methodology into practice.

If your a Java programmer, my advice is to forget Extreme Programming Installed, and pick up Java Tools for Extreme Programming.