Slashdot Mirror
Extreme Programming Refactored
The Previous Extreme - What XP Set out to Fix It had previously been accepted practice to spend months (years, even, on large-scale projects) gathering requirements, then another year or two on design, before a single line of production code had been written. The infamous "big bang delivery" occurred when this gigantic monolith of a software system was finally delivered to the customer, only for the customer to retort that this was nothing like what he wanted.
It was also accepted practice to divide the system into separate subsystems, and attempt to integrate them after several months. By this time, each subsystem would have taken on a life of its own, and integrating these disparate monoliths together gave a whole new meaning to "plug and pray."
How XP "Fixes" It XP takes the development process to the other extreme, by shortening the "waterfall" lifecycle to weeks, days, even minutes. In fact, Kent Beck describes XP as a "waterfall run through a blender." Iterations typically last for a week or two; there is a high emphasis on code quality via unit testing; and code is integrated "constantly" so that it never becomes out of synch with the rest of the project. Beck is often quoted for saying that the XP practices "turn the dial all the way up to 10" -- that is, if something is good (testing, integrating, pair programming etc), well then, let's do it all the time.
There's a lot to be gained from learning about XP, and agile practices in general. However, many feel that XP has taken things too far. By taking things to the opposite extreme, we're just introducing a fresh set of problems. The optimum solution, then, must lie somewhere between these two extremes. That is fundamentally what Extreme Programming Refactored (XPR) is about.
Optimizing the Process There's been a lot of controversy surrounding this book. It grew out of an equally controversial article that appeared on the author's website. XP advocates were arguing on Yahoo! Groups over XPR's good and bad points, miraculously, months before the book was even available. XP zealots were even posting messages telling others not to buy the book, before they'd even had a chance to read it for themselves and find out what it's all about.It's important to note that XPR isn't the anti-XP slam piece that some people had been expecting. It does rip into the XP practices in plenty of detail, but importantly it also describes alternatives, and talks about the good aspects of XP.
The authors make the argument that "turning the dial up to 10" mostly isn't such a good thing, and that to achieve our "holy grail" development process, we just need to turn the dial down a little bit -- let the milk simmer rather than boil over. We can do this by adding in some additional practices that take the burden off the overloaded, heavily interdependent XP practices.
For example, not everyone likes to pair program (with two people sitting at one computer). It just isn't for everyone. However, XP relies on everybody in the team pairing all the time. So if you don't like to "pair up," what choice do you have but to leave the project? XPR adjusts the other practices, placing a bigger emphasis on up-front design and documentation, so that pairing up doesn't have to be mandatory.
XPR also argues that it is possible to achieve a decent design before writing the code. The authors don't want a return to "BDUF" (Big Design Up Front), but instead to achieve an ideal middle-ground. The result is more akin to the monthly Sprints found in Scrum (www.controlchaos.com).
Similarly, XPR argues that the customer (and users) usually do have a pretty good idea what they want from a new system, and that they don't have to see a live system first before realizing that they wanted something entirely different. The authors argue in favour of interaction design as a way of achieving this goal.
XPR achieves all of this with more than a mild dose of satire. It's important to realize this -- the book is essentially "taking the piss" out of the more extreme XP practices, and the quasi-religious Extremo culture that has quickly grown up around XP. It has lots of serious things to say, but has a slight danger of that being lost "in the chuckles." There again, the danger is less to do with the book, and more to do with the reader.
XP sealots will never be swayed by such a book, naturally, but they are not the audience. It is for those undecided, or the cowed XP skeptics who know something is very wrong at the heart of the beast, but haven't have the words to say it. Even for zealots, I'd hope they'd put the hatred for long enough to at least temper their XP actions, to turn the dial down a little, to read the contents with the possibility in their minds that XP isn't the final perfect expression of all programming methodologies. Just for a while...
If you are scared of the contents, a favorite XP accusation, then of course you'll point out the 'needless humour,' blah blah, anything rther than address what the book says. Form will be far more addressable than content. It's the old "ignore this man, he wears a colourful tie" excuse, pick on some small detail that you feel is a weakness and totally ignore all the embarrassing questions you'd rather not address. If you like the contents, then the humour will be seen as a playful, court-jester like addition to what is a seriously analytical book
In conclusion, this book is well written, thought provoking, and above all entertaining (an aspect which seems to be proving almost heretical among some XP advocates). I found this to be a fun read, unlike some books, it was never a chore. It's extremely conversational, like having a cynical, wise-cracking guide. It's a pity more computer books aren't this fun. A spoonful of sugar and all that...
In fact this book is pretty damn wonderful. I know, it may sound a bit gushing, but before you review my review, give the book a read yourself. It's a thing of beauty, a rare mix of positive and negative, sweet and sour, opinion, and XP's favorite emotion, courage, courage enough to say "the emperor has no clothes." I can't see how you could read this book from beginning to end and not see XP in a different light.
In fact, XP programmers would do well to read this book, as it presents the negative path, something other than sunny-day scenarios. Using these warnings and guidelines, they'd have much more successful projects, as this book points out the dangers of lack of XP discipline, fragility and so on.
The truth is that I couldn't do justice to this book in such a short review. There is just so much evidence, so many contradictions pointed out, endless damning words from XPer's own mouths. It was supposed to be a small book to start of with, 150 pages or so, but due to the sheer body of evidence and submitted real life stories from those in the trenches, it bloomed to 400+ pages.
As Doug Rosenberg says "I don't want to be nearby when somebody decides to deploy an air traffic control system or some missile-targeting software that has been developed with no written requirements, and where the programmers made the design up as they went along." At least don't say you weren't warned!
You can purchase Extreme Programming Refactored: The Case Against XP from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
there are numerous factual erros on what xp is in this book..
One example..if using xp must pari program..
wrong! XP like any software process allows you take and use only those features that work with your project something this book author forgets to point out...
Don't Tread on OpenSource
I have been using XP where I work for over a year now and I must say it is the worst enviroment I have ever worked in. It seems XP is for people who just want to write code and not think about serious design issues or future planning. In the future when looking for a job I will make sure that they DONT use XP. More and more it appears to me that XP is for the hacks out there that never bothered to learn how to do real design work.
Look,
.
Nobody should shun any alternative aproach to software development in favor of established "software development practices" when a huge percentage of projects, very very close to 100%, come in late and massively over budget
The web-posted material on which this book is based is not a thoughful critique. It is parody, yes, but not a critique. One of the central points made is that XP requires, e.g., strong unit testing and refactoring to work. Yep. If you don't do that, XP doesn't work well. Yep. These are points no XP advocate denys. The material ends up making the claim that if you don't do XP you can't do XP. This is quasi-interesting, if utterly obvious, but not the basis for a book-length attack on XP.
Skip this book and buy McBreen's if you want to read a critique. Join the Yahoo group and state your critique thoughfully, and read how some of the major thinkers in XP respond. Then make up your mind.
This a most telling quote as most developers have never talked to an actual customer in their entire career.
"On-Site Customer" is one of the tenets of XP.. Of course, this isn't always practical, but having instant access to the customer is one of the things that makes XP work...
That's a good question.
XP requires quite a bit of discipline, just like any good process does. The real power, I believe, comes from the interaction of the processes. For example, tt'd be crazy to refactor all of the time, unless you had a comprehensive test suite. It'd be crazy not to design ahead for features you will need in the future, unless you let the customer choose which features to add and when and if you can keep the cost of changing the code low.
A lot of projects adopt a couple of the easier practices without really understanding why they're important and how they fit into XP as a whole. (Extreme Programming Pocket Guide spends most of its time talking about these interactions.) Without either tremendous skill and discipline or other supporting practices that provide what the unpracticed XP practices do, you're bound to crash and burn eventually.
It's okay to pick and choose from the XP practices that your team needs most, but you have to understand what they can and cannot provide.
I think what you're seeing is a lot of teams who like the idea of not doing a lot of up front design and getting rid of a lot of process but who aren't replacing that with the appropriate XP practices or equivalents.
That's why when someone says "We tried XP, but our code turned into a big ball of mud", people who've used XP successfully will ask "How well were you testing?" and "Were you refactoring?" It's not that XP is always appropriate for every situation and every team. It's that if you just copy a few practices without thinking about why they're important, you can get in a lot of trouble.
how to invest, a novice's guide
XP is sort of like this (according to my com sci proff)
XP is a response to the engineering of code (which has some problems)
It addresses the fact that the biggest problem in software development is requirements change. Intead of trying to avoid change (traditional engineering does this) XP deals with it by always having access to a customer, having short release cycles, and determining priorities for each release.
XP grows a product, over time a framework will also grow. The key is simplicity, only building what is required at this time, not going overboard and building a big framework. (not sure I agree with all of this)
XP is supported by pair programming - two people code togeather, one codes, other looks to see if any improvements can be made.
and No code ownership - anyone can change anything.. this means no waiting for someone to fix problem code. (other methodologies such as feature driven development which are similar to XP, stress this is not always a good thing)
Also, XP states that with each feature the product must be integrated and tested. This is supported through test driven development.
test driven development means that automated test code is developed before the feature is implemented. Only after the code passes the test will the feature be complete. This gives greater feedback to the programmers.
XP does have design documents. It has a coding standards document, a metaphor (what the product is liken to), customer "stories" that describe each feature and CRC (class responsibilities and collaborations)
XP also suggests the use of state diagrams and using a white board to plan out features that are complex. It recommends capturing the diagram before erasing (maybe a digital camera)
So, XP does not throw out planning. XP is not coding by the seat of your pants, and it is sort of like you described, only there is method behind what is precieved as madness. You do follow described features, and the Test Driven Development keeps the program on track.
Having been through the waterfall'esk process several times, I cant say I disagree with what XP is trying to do. Some of it sounds flaky to me, but makes a lot of sense. The key to it is communication, you communicate more with programmers (pair programming), customers (on site customer) and get more feed back (automated testing).