Ron Jeffries | Ann Anderson | Chet Hendrickson | Ronald E. Jeffries
1 Good solid content, but not the best book to start with
This book is part of a series with "Extreme Programming Explained" and "Planning Extreme Programming", and needs to be viewed in that context. "Extreme Programming Explained" is the manifesto, designed to get you fired up about the subject but thin on detail. "Extreme Programming Installed" covers some of the same ground, but focuses on real-world examples and advice on how to make Extreme Programming really work.
Jeffries and the team are not afraid to face up to things people have trouble with in real situations. The book covers dealing with difficult managers and customers, deciding what needs testing, making pair programming work for you, and lots more. The bulk of the book goes through the practices of Extreme Programming step by step, but some of the most useful stuff is contained in the so-called "bonus tracks" which appear at the end. The book also has a large and interesting annotated bibliography. Well worth reading, but I'd recommend that you start with "Extreme Programming Explained", then read this one if you like the idea, but want a more practical approach.
2 One book, many authors
There's a certain amount of repetition in this book. It makes me feel that perhaps each of the three authors took their assigned chapters and wrote them, much like they would take their assigned "story cards" at the beginning of a project.
But there's good practical advice here.
Take out a yellow highlighter and resolve: "OK, I'm going to highlight at least one good idea on every page". You'll be able to do it.
3 If you read only one book on XP, this should be it.
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.
4 Accurate, Practical
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.
5 The only usable programming methodology I know
This book gives you a viewpoint, how to organize and execute successful IT projects. I use only a few principles from it, but they help me a lot.
Big hello to the authors!
6 Actually Doing XP? Here's an OK reference
"Extreme Programming Installed" provides information on the practice of extreme programming in your organization. It's meant for those already using XP, rather than a casual reader wanting to get more insight. The confusing writing style and layout of the book make it a difficult cover-to-cover read.
The content is useful, but the chapters are not tied together well, skipping from one topic to another seemingly at random. This causes a great deal of confusion on the part of a reader intent on reading the book sequentially. The detail level varies wildly, from excellent 50,000 foot overviews of concepts, to confusing minute by minute minutia of detailed work. The extremely conversational stream of consciousness tone and constant cross references muddy the points the authors making -- the reader's too busy trying to figure out what they are trying to say. This is a useful reference guide to groups who have already begun to implement extreme programming, but I cannot recommend it to those who want to learn more about this exciting lightweight methodology.
7 Best yet
CLearly written and a better into that XP Explained if you are trying to get to where you can use the process
8 XP Good. XP Books Waste of Money
There is no information in this book that is not available for free on the web. The only reason to buy this book is to give something back to the authors for their contributions to the XP community.
9 Wonderful, but not a practical tutorial
I just love this book. However, I don't give it a 5 because it's a bit too verbose. I recommend it for people who want to get excited about XP - or to get someone else excited, which has worked for me. For that - making you *want* to use the methodology - it's great. But it is less than perfect to put you on track to actually do it.
I've been told (second-hand, haven't actually read them) that if you want a practical guide you should get either the green book (for managers) or the orange book (for developers). (Check ...(this website) list of related books on this page to find them)
10 A step in the right direction, but there are better books
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.
11 Great methodology, book should be shorter and clearer
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.
12 good for medium-size teams
The concepts in this book are very simple. The testing and integration technique alone is more valuable than all the management and testing theory together that I have read so far! BUT...
DO NOT (I repeat, DO NOT) read this book before you read its predecessor, Extreme Programming Explained! You WILL NOT understand key points, otherwise. As in the other book. you must implement all of this technique or none of it -- with the exception of testing and integration. The theory is exceedingly simple, but you must have stick-to-it-iveness (otherwise known as self-discipline) to make it work.
Although I have not proven this, I believe that the testing and integration technique will work with any size group, including one-man teams. The rest is optimized for medium-size teams, and NOT extremely large (definitely not extremely small) teams.
13 Solid book with great XP coverage
Words cannot express how good a book this is. At the beginning of the book, the spirit of the XP Practices is conveyed well. In the middle, the mechanics of how to do XP is well covered. Near the end, valuable insights are shared.
14 Maybe the best of the series
Much better than XP Planned. Its decent but a little expensive relative too its small size. It explores XP more deeply that XP explained.
15 Will Change How You Think
This excellent book changed not only the way that I approach software development, but also how I approach problem solving in general. It is well written and completely accessible. The authors repeat important concepts over and over again to the benefit of the reader.
If you're looking for concrete practices that will make developing software easier and more fun, this is the book to read.
16 Best of the XP series, but still wordy
The books in the series have a lot of whitespace and are chatty andrehashes of each other and this cuts down on the amount of information they impart. Contrast that with Steve McConnells books.
This is the best book of the series with some great ideas. They addressed many of the software engineering concerns I had.
17 GOOD
XP is a nice fresh way of looking at the software development process and this book explains XP concisely and clearly. You may or may not agree to -all- of the principles they advocate, but if you have any interest in your work at all, you will find parts of this gripping. Especially the emphasis on unit tests and the test-first programming idea. And so useful in practice too! Anyone involved with making software, or indeed anyone else who is interested in increasing the quality of what you're working on whatever it is, should read this! So better borrow it from your neighbour (reading once is sufficient, no need to own this book).
18 I just got XP installed into me.
For someone who has only heard of XP before reading the book, I reckon that the book has done a great job explaining the concepts of XP and helping me internalize them. It is for the programmer who wants to be better. The book is highly readable. The book list at the end of the book is indispensable too.
19 The best of the serie
From a practical stanpoint, this book takes you step by step into the implementation of XP. Follow it step by step and you'll have an "XP development process". In my opinion, it is best to start with XP explained, followed by XP Installed, and then XP Planning.
20 Best Commercial Practices . . .
What do you want me to say? This book is but one of a series. It is not a panacea for all your ills. It only talks about developing quality software when you're under the gun. My colleagues agree that these guys put together the best commerical practices of the past 20 years into one adaptive methodology. The cool thing about this is that you don't have to impliment the thing en todo to get the results you want. Find what you like and start there.
Overall I found this book a delightful read. The chapters are short, like XP's iteration cycle. Short is sweet when you're an over-worked programmer like me. At first I was underwhelmed by this approach, but it works! The annotated bibliography in the back of this book (and others in this series) helps understand the author better and give you context.
This book offers practical advice.
21 Practical Simplicity, Communication, Feedback & Courage
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.
22 Good discussion of how XP works.
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.
23 Extreme Success
We have a small team of four developers. We have had the rare opportunity to develop our process and our web application (using Apple's WebObjects) from the ground up. We chose XP, were guided by this book primarily, used jUnit for testing, COCOMO for long-range estimation, and it looks like we're meeting with extreme success. We'll beat the COCOMO model with default parameters. In only a month, we were able to hit the ground running with the streamlined, clear XP process. For small teams such as ours, XP is guaranteed to enable you to outpace other teams with less mature processes and also those with more process overhead. XP Installed delivers.
24 Highly recommended
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.
25 Excellent and Quick Reading...
I'm a member of a development team totaling 4. So some of the book wasn't very useful because it talked of larger teams but many of it's principles can still be applied to my team. I especailly found useful the chapters and information on estimating deadlines and reaching those deadlines. I also picked up a lot of things along the way that were helpful. Although I'm not completely convinced of switching the book was worth the tips I picked up for increasing the accuracy of my estimated time-to-completions as well as programming tips.
26 Good practice but can managers give up?
I have programmed in projects from "Cowboy style" to "User case and big document styles". Until now, XP introduced a real good practice to us. However, good practice doesn't mean people will use it. For example, in "user case and big documents approach", managers become manager and business analysors and they produce a lot of documents. In one project, 70% project time has spent on documents of so called "detailed user cases", which are a strange mixture of requirement and scenarios. Managers and business analysors were busy while programmers has little to do at these 70% project time. If XP is used, what can managers and business analysors do? They can only do "use cases" and cannot write codes or draw dynamic diagrams. But they have the say. Do you think they will use XP? The politics could finally decide what to use. And managers certainly like "big document approach". Those documents will not be used in coding at all.
27 Achieveable programming utopia is described
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.
28 Very useful whether you do XP or not
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!
29 Definitely a must-have
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.
30 It's great to see that XP is actually being implemented
I've seen people speaking about it and know of small projects trying it out, but now that Chet Hendrickson and Martin Fowler are working for the same company, I hope to see many more books on really impressive success stories. I am telling my managers to read this book!
