Extreme Programming Installed

Continuing with his campaign to rid the world of lousy software, chromatic is back with this review of Extreme Programming Installed. It sounds like what the authors are advocating is a truly programmer-centric environment; does anyone have experience in a workplace even close to this?

Extreme Programming Installed author Ron Jeffries, Ann Anderson, Chet Hendrickson pages 244 publisher Addison-Wesley rating 8.75 reviewer chromatic ISBN 0-201-70842-6 summary How to implement Extreme Programming, with strategies,examples, and practical advice. More interesting than it sounds.

The Scoop Last year's Extreme Programming Explained was a manifesto of sorts. Wouldn't it be nice if customers, management, and programmers could work together to produce good software on schedule and under budget? If planning, peer review, testing, and design are good, why not do them all the time? It even put forth the radical notion that customers should set business value while programmers create -- and revise -- technical schedules.

Yet another 'silver bullet' Fred Brooks debunked years ago? The authors of Extreme Programming Installed disagree. The book breaks XP into workable chunks, hanging flesh on the bones of Kent Beck's manifesto. It explains each element of XP in turn, based on the authors' personal and collective experiences.

For example, the Iteration Planning chapter describes planning meetings. The customer presents stories, the developers break the stories into tasks, and individual programmers estimate and sign up for tasks. Each element has further detail on best practices and potential traps. Finally, the chapter describes an average meeting.

What's to Like? As with other titles in the series, the text is clear and easy to read. The short chapters have no fluff, saying only what's needed. Concise explanations and a gentle, conversational tone add up to a book that can be finished in an afternoon.

This book is the most practical of the series so far. Drawing on personal experiences and data gleaned from early adopters, the authors distill XP practices into their purest and most essential forms. Anecdotes from programmers in the trenches line the pages. Though everyone practices the processes slightly differently, a clear picture begins to emerge.

Though listed in the table of contents as "bonus tracks," the last 11 chapters may prove the most valuable. Each track addresses a common concern or criticism of XP, from "Who do you blame when something goes wrong?" to "How do you write unit tests for a GUI?" and "You can't possibly make accurate estimates." This won't satisfy all the nay-sayers, but it adds a healthy dose of reality.

What's to Consider? The testing and refactoring sections, needing the most explanation, have a strong Smalltalk bias. While these chapters have strong supporting text, a decent programmer unfamiliar with the language will have to invest extra time to understand the examples fully. This is the most detailed portion of the book, and may be the hardest to read.

While some readers may like the open-ended nature of the presented techniques, others, familiar with more formal development processes, will want authoritative proclamations. XP actually installed, argue the authors, depends on the nature of the task and the team. The controversial axiom of embracing change by continually performing a certain few practices while discarding the rest, will raise some blood pressures. Clearly, this is not for the faint of heart.

Developers and managers interested in the whys of XP would do well to read Extreme Programming Explained instead. Though the authors present a brief business case for the process, most of the text assumes the reader has already decided to install it. Customers receive more text (a few chapters), though there's clearly room for an expanded treatment of their roles and responsibilities.

The Summary Extreme Programming Installed will not silence the critics, but it makes great progress in showing how XP can work, in the right places. Beyond that, it demonstrates the flexibility of the approach, with numerous real-world examples. This book deserves a place next to Beck's manifesto, showing off XP as it's actually practiced. Table of Contents

1. Extreme Programming
2. The Circle of Life
3. On-Site Customer
4. User Stories
5. Acceptance Tests
6. Story Estimation
7. Small Releases
8. Customer Defines Release
9. Iteration Planning
10. Quick Design Session
11. Programming
12. Pair Programming
13. Unit Tests
14. Test First, by Intention
15. Releasing Changes
16. Do or Do Not
17. Experience Improves Estimates
18. Resources, Scope, Quality, Time
19. Steering
20. Steering the Iteration
21. Steering the Release
22. Handling Defects
23. Conclusion

Bonus Tracks

1. We'll Try
2. How to Estimate Anything
3. Infrastructure
4. It's Chet's Fault
5. Balancing Hopes and Fears
6. Testing Improves Code
7. XPer Tries Java
8. A Java Perspective
9. A True Story
10. Estimates and Promises
11. Everything That Could Possibly Break

You can Purchase this book at ThinkGeek.

Comments

Re:My GF did this

[Salamander]

It sounds like they weren't really doing extreme programming then.

What a convenient and obnoxious rationalization. This idea that if you're not doing all of XP you can expect failure is offensive enough. Besides the Inquisitorial insistence on total adherence to every minor tenet of The One True Faith, if a methodology is so fragile that the tiniest deviation leads to failure then that methodology is worthless in the real world.

What's worse than that, though, is the way that, without knowing anything about what this fellow's GF's company did, you reason backward from the fact that they failed to the conclusion that they must not have been doing XP "properly". That's just nauseating.

FYI, we just had a fairly detailed discussion of XP here last week, in the Making Software Suck Less thread. Of particular interest might be my XP is no panacea post, which contains a lot that would be directly on-topic in this thread (but I prefer linking to copying).

The good, the bad, and the ugly

[pongo000]

I sat in on a white paper presentation by Craig Larman, author of Applying UML and Patterns , in which he discussed his experiences with XP while managing a small (8-10 programmer) software project. A summary of his observations:

• XP is most useful for small, "low-ceremony" projects. However, parts of XP can and should be selectively adopted for use in larger projects that might not lend themselves to a total XP approach.
• Some practices (pair programming) apply to all project scales. Others (fast, continual integration, for example) do not scale well in certain parallel development projects.
• Practices to usually adopt: 1. Write unit tests first. 2. Pair programming. 3. On-site customer. 4. Rapid integration. 5. Common project room. 6. 3-4 week dev cycles. 7. Simplest design possible. 8. Collective code ownership. 9. 40-hour week. 10. Shared coding standards. 11. Constant refactoring. 12. Programmer is designer.
• Practices best to avoid: 1. Minimalist formal analysis and design. 2. Avoidance of diagramming. 3. Constant refactoring, especially on short engagements or proof-of-concept apps.
• There is also no empirical data pointing to the success of XP in projects of a large scale.
• The practice of "doing the simplest thing possible" is predicated upon the assumption that late-change is becoming less costly, and the classic exponential cost curve for late change is no longer always true. Of course, there are many counter examples. C++ is more costly to change the Java, which is more costly to change that Smalltalk. New software designs that are coupled with new hardware designs are very costly to change late in the game.

Logic

[mspeedie]

Apply some logic, please:

1) No method is fool proof.
2) Every method has advantages.
3) Every method has disadvantages.
4) Good talent and a reasonable method work.
4) Bad talent or a poor method will not work.

I used some pair programming with some junior programmers to rapidly develop a database interface. We had code reviews and detailed coding standards, including coded examples. All code had to have a testing module that test all aspects of the interface.

It worked well, and the quality of the code was good. We ran a little late, but that was for the programmers to get up to speed with the method. I think the code quality would have been only average if the programmers had been working alone. The bug level using this method quickly dropped to zero before this sub-system was integrated with the front end. I found that refreshing, compared to traditional methods.

I don't think XP will work for prima-donna or insecure people. It is just too exposed for those types. you have to be willing to let other people understand your code and style. You also have to accept they may have some constructive criticism. For example the junior programmers made some darn good suggestion on the example code I had created.

I will continue to dabble in XP as so far it has shown good results.

If it works for you, use it, if not find a method that does work.

Any change will be met with resistance from those who feel threatened by it. If you feel threatened by something try to dig deep and understand it and why you feel threatened. Don't just discount it as a silly sound-bite.