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.
XP and refactoring. Two over-blown buzzwords that go great together.
the customer (and users) usually do have a pretty good idea what they want from a new system
This a most telling quote as most developers have never talked to an actual customer in their entire career.
I think the next programming movement should be called XTTFC for Extreme Talking To a Fucking Customer.
having a team of programmers who:
Like to program,
are properly trained and schooled,
who are paid enough,
and are given enough time to do the job right.
Everything else is fluff or a fad.
Your hybrid is not saving the environment. Its purpose is to make you feel good about buying something.
Pair programming is uncomfortable on our reduced space. And it's noisy.
Are the inconveniences worth it?
If your partner is really hot, then yes.
Healthcare article at Kuro5hin
Q: What do you get when you combine the waterfall model with the spiral approach?
A: The flush model.
On a more serious note, the waterfall model does work for certain problem domains, notably those where the requirements are well understood in advance and unlikely to change significantly over the course of development, and where reliability of the final product is critical. This assumes you have the resources (time and people) to do it properly -- and this is why the waterfall method has gotten a bad reputation -- it's been applied where there is insufficient time/resources or the requirements aren't well understood.
Most business applications, for example. The waterfull method is wonderfully suited to something like spacecraft control software, where the spiral approach (we called it "stepwise refinement" twenty-five years ago when I was in college -- there's nothing new) just wouldn't work. But businesses are both constantly changing and adaptable -- a business app that only implements half the requested features is probably still more useful than not, where as software to control complex hardware that's only half done is nearly useless (except that some testing can be done, perhaps).
As always, it's a matter of picking the right tool for the job, rather than picking up your hammer and treating everything as a nail.
-- Alastair
I cannot attest to actually having been involved in any project which used XP as defined but I can say the following about what I consider similar:
I used to work at a company that strangely enough fostered both getting things done quickly for some projects while fostering a long drawn out method for other projects.
The company was a consulting firm which always needed an answer yesterday for this or that problem.
They also wrote fairly large simulation packages for the FAA. Some of these projects would go up to three years. Lots of planning etc. was usually done.
Regardless of which type project I worked on I always tended to be the type who would get something working quick and then iterate over it several times if necessary.
Others tended to be going at what I considered to be a snails pace mode. They would plan for days, weeks, months on something that I never considered worth that much planning.
I could usually have a pretty good prototype working with a couple of major revisions made before the "planning types" could even get out a initial prototype.
But, over the years I noticed that I (and those like me) tended to get "officially finished" in about the same amount of time that the annoying guys who planned everything out to the Nth degree got finished.
Was my product any better than their's? No not really.
Which methodology was better? It's hard to say, I know I certainly always liked to utilize new methodologies that worked well while they liked to stick with the tried and true.
About the only thing that I can say is that my internal company clients usually appreciated that they had something to work with earlier rather than later.
They knew it was a rough version, but hey, if you need it now, you need it now. And two years from now may not pay the bills.
So, lots of times I came out looking like a hero.
But, looking back on it now I'd have to say that my own personal version of XP wasn't any better than my counterpart's long drawn out process, at least in terms of a final product.
My $0.02 worth.
Sorry if I was too far off-topic...
Caution: Contents under pressure
Who hates the idea of pair programming? Smarties ofcourse. They dont want to lose what they feel makes them special.
;-)
;-) but do you just want a stable of predictable but average programmers, or do you want to hold on to those "smarties" who, in a pinch, can deliver good code faster than any eight other programmers put together?
;-)
More likely they're just driven insane by having to wait on the other person. Depends on how bad an impedence mismatch you have. Programmer productivity can vary by an order of magnitude or more between individuals (so called "superprogrammers", although the term is silly). If you have one of the latter, no amount of "skill transference" is going to bring the former up to the same speed, any more than teaming someone with an IQ of 150 with someone with an IQ of 110 is going to raise the latter's IQ to 130. (It might, through frustration, lower the former's though
On the other hand, if you're just talking about a couple of average programmers, one of whom has a couple of years more experience, then yeah, it makes sense.
They are bad for business anyways.
Depends. Nobody needs prima donnas, of course (well, except ballet companies, I suppose
(Of course, you may not have the choice. Superprogrammers aren't nearly as prevalent as the number of average programmers who think they're "super" would indicate
-- Alastair
How would you achieve this? I'd probably do things like:
Of course, by the time you do all that, you've got the heart of XP.
how to invest, a novice's guide