Slashdot Mirror
Extreme Programming Installed
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- Extreme Programming
- The Circle of Life
- On-Site Customer
- User Stories
- Acceptance Tests
- Story Estimation
- Small Releases
- Customer Defines Release
- Iteration Planning
- Quick Design Session
- Programming
- Pair Programming
- Unit Tests
- Test First, by Intention
- Releasing Changes
- Do or Do Not
- Experience Improves Estimates
- Resources, Scope, Quality, Time
- Steering
- Steering the Iteration
- Steering the Release
- Handling Defects
- Conclusion
- We'll Try
- How to Estimate Anything
- Infrastructure
- It's Chet's Fault
- Balancing Hopes and Fears
- Testing Improves Code
- XPer Tries Java
- A Java Perspective
- A True Story
- Estimates and Promises
- Everything That Could Possibly Break
You can Purchase this book at ThinkGeek.
It's so convenient to paint things in black and white. Either management are incurably ignorant, hence nothing will save them, or they are devine oracles, and they already know everything. The ignorant are too stupid to learn, the wise already know everything, therefore learning new things is pointless.
There's nothing in your reasoning that precludes it from generalising to all fields, and allowing us to reach the absurd conclusion that noone needs to read.
I can understand the folly of touting a book or methodology as an instant cure-all, but in the high tech industry, dismissing new ideas because you think that you already "know it all" is hardly a recipe for success.
The first big unique thing about XP is its rejection of the "exponential cost curve" taught in most software engineering classes. Instead of trying to anticipate future requirements and design accordingly, XP advocates keeping the code simple, flexible, and solidly regression-testable, so that the cost of changing code is always cheap. In my experience, this has proven a really good idea.
The other unique thing about XP is that it gives structural support to the so-called "good habits" of software engineering, rather than relying on exceptional programmers to (hopefully) implement them. Over-the-shoulder coding is a wonderful technique that I at least hadn't tried before (your coding buddy doesn't even have to be a particularly strong coder, and it still works very well). The continuous test cycles and writing tests before code are not new, but the discipline of implementing them is most welcome. Short iterations with a focus on business value is practically unheard of -- instead, the focus is usually on getting a complete spec before moving to a rigid (and thus usually brittle) implementation, etc.
Of course XP isn't unique in one sense: some of the best programmers I've known already use these techniques in their own work. But, much as How to Win Friends and Influence People doesn't tell you anything you didn't already know, it's useful to have it all in one place.
Take a closer look at XP if you haven't; what your post points out to me is that, like other fad processes, people will probably rush to implement XP, miss the point, and denounce it as a fad instead of looking for the core contributions to the art.
Clearly, you didn't read the book.
Beck makes pretty clear that the XP model is not for everybody. He even has a chapter titled When You Shouldn't Try XP.
He also makes many of the same points you make; especially that understanding customer needs is crucial. He goes further to say that the only will way to understand customer needs is to involve them (or, as you say, their representatives) closely in the development process, so that you have lots of feedback.
Because XP has a lot in common with the Evolutionary Delivery lifecycle, it also substantally reduces budget-related risk. Since you are regularly producing high-quality working versions that have successively more features, you always have something to deliver.
So I agree that 'silver bullet' solutions are bad but I disagree that XP is such a solution. It's just a collection of development techniques that are, for the most part, entirely uncontroversial. The only new thing is the emphasis on combining them in a way that they reinforce one another.
I agree that if you have an evil (or willfully clueless) manager, no book will help. But there are a lot of people who manage software projects (or who manage people who manage projects) that are ignorant but willing to learn, especially if it means the difference between success and failure. And for those people, sticking a few books under their noses will help a great deal. For these managers, I give away copies of Rapid Development or The Software Project Survival Guide depending on how technical they are. And if your project is suited to an XP approach, then a book explaining the business case for using XP will help them understand why they should back you, rather then meddling with things they don't get.
XP is about attitude. Just as there is a vast difference between agressive and passive error checking/handling, the entire XP philosophy is centered around agressive programming.
You don't code until you need to code it. (No that doesn't mean you don't do a proper design) You refactor code and design as soon as you run into delays or problems. This way you avoid cruft that builds up. You are under constant code review (when programming in partners). You get exposed to the whole system and not just one small section. Interestingly many of the XP practices go against what traditional SE teaches.
http://www.xprogramming.com/ - has a good overview of the processes and atmosphere that XP creates. Check out the XP Practices in particular.
I've tried implementing some of these practices myself in personal programming. I can tell you it takes more engery but so far I like what I'm seeing from my progress. I'd like to see how effective pair programming can be as well. I've done a bit of this at work but only at weekly code reviews.
Now I don't think it's the silver bullet or holy grail but I'll try anything to hasten the development process whie lowering defect count. I don't try to do everything that XP advocates.
Anyways, if there's one thing you should probably get from XP it's an agressive mentality when programming.
Fsck cluebie moderators. I'll say what I want, offtopic or not. And fsck having to qualify every bloody statement just
Maybe there is just too much consultant mumbo-jumbo in the XP publications, but the technique sounds old. Develop incrementally, have a small group of smart people working together, test and release frequently, etc., ... those things have been used as the guidelines for projects for at least 20 years, if not longer. I think one might argue that GNU Emacs and other GNU software was developed that way. I don't see anything "extreme" about it, and in fact tools support for this kind of programming used to be much better. However, it doesn't always work: you really do need people on the project that are really smart, love what they are doing, and can work together. Self-selected groups in open source development fit that profile much better than a bunch of people thrown together into a project in a company, under stress from release dates and career paths.
The conclusion: If you work for clueless managers, sticking books (like the one reviewed here) under their noses is not going to fix the problem. If you managers have any understanding of the software development process, they will probably already have a development model in place that is appropriate for your project(s), customer(s), organization, and budget.
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).
Slashdot - News for Herds. Stuff that Splatters.
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.