Extreme Programming Refactored 444
| Extreme Programming Refactored: The Case Against XP | |
| author | Matt Stephens and Doug Rosenberg |
| pages | 400 |
| publisher | Apress L.P. |
| rating | 9 |
| reviewer | Dino Fancellu |
| ISBN | 1590590961 |
| summary | Bold critique of extreme programming - at last someone is prepared to say "The emperor is buck naked." |
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.
Absolutely Hopeless and Clueless (Score:3, Insightful)
Definition of a review (Score:5, Insightful)
sPh
Re:Factual errors (Score:5, Insightful)
> and use only those features that work with
> your project
Sure, you can do whatever you want. But XP without pair programming isn't XP, it's.... something else. "Pretty Adventuresome Programming", maybe.
Some folks don't like XP because it's hard - it's hard to write unit tests, and it's hard to pair program and share knowledge and so forth. That's fine... but if you're rejecting XP because you don't like doing those things, don't blame XP.
Re:Ask Slashdot: Have you used Extreme programming (Score:4, Insightful)
I would have to say that pair programming isn't really worth it. I personally can't stand the lack of productivity that is inherent to having two programmers sit around and watch each other type.
My version of pair programming is to have one developer write a test harness while the other one develops the actual code to be tested. This forces each of them to communicate with each other, generally via a very informal spec or direct communication with the client.
This ties two people closely together with the immediate need, but it doesn't require complete overlap. I'm not convinced that two brains are better than one - typing is an inherently blocking process, and whiteboarding happens either way.
Anway, what good hacker wants to watch someone else type? Or play a game? Or do anything? Coding isn't a spectator sport.
Sheesh. (Score:3, Insightful)
If there was a book called "Why Linux Sucks", and I contributed to it, and I agreed with it, would that make me a fair reviewer for it? You can find links to some possibly less biased reviews [softwarereality.com] at softwarereality.com. It's also worth reading the comments [softwarereality.com] on the Case Against XP [softwarereality.com] article on the same site, by one of the authors of the book.
Nothing beats... (Score:5, Insightful)
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.
Re:Ask Slashdot: Have you used Extreme programming (Score:3, Insightful)
Who hates the idea of pair programming? Smarties ofcourse. They dont want to lose what they feel makes them special. They are bad for business anyways.
Maybe he shouldn't have reviewed it... (Score:3, Insightful)
Re:Ask Slashdot: Have you used Extreme programming (Score:3, Insightful)
The truth about pair programming is that only the right mix of personalities and skills will work. I've done it with people where it worked great. With others, really badly.
Re:XP v the Engineer (Score:5, Insightful)
> is to understand the problem domain
That's part of the process, yup. And there's a lot of other stuff, too.
> You don't need requirements before you
> start coding
What about the planning game? What about user stories? Read this [xprogramming.com] for better information on XP requirements gathering.
XP has the concept of figuring out what customer want... but XP doesn't demand that you and the customer pretend that every detail of the system is in a bunch of white binders filled with stuff like "the system shall...". Instead, you and the customer work together to develop a system that meets the customer's ever-changing requirements.
> if you aren't you need more process to
> make sure you don't FUBAR things
That's the beauty of XP - it assumes that we aren't geniuses and thus we use unit tests, refactoring, pair programming to keep the code under control.
Re:Ask Slashdot: Have you used Extreme programming (Score:4, Insightful)
When you have a good and balanced team, pair programming will occur naturally. At some point someone is having stuck on some problem (design, bug,
I believe that Natural Pair Programming with mentoring and code review are a lot better than full-time pair programming. This will help junior developer get up to speed more quickly without having to have two brains waisting their time on trivial problems.
I also like the idea of the other poster saying that you can have one developer write the Unit Test while the other write the business code (you should inverse roles often though). This also benefit having two brain work on different thing while maintaining synergy and increasing the odd of catching bugs.
Re:Ask Slashdot: Have you used Extreme programming (Score:3, Insightful)
Anyway, I've found you simply cannot get 2 good coders by shackling one good and one poor coder together. The bad one generally doesn't learn anything and the good one just gets frustrated and angry.
Pair programming might work if the poor coder had a desire to learn, but it's been my experience that this usually isn't true. Learning to be a good coder does not happen by proximity and osmosis.
Re:Absolutely Hopeless and Clueless (Score:5, Insightful)
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.
Re:XP Programming (Score:3, Insightful)
"Real design," as you call it, requires that you keep to yourself, code code code in secret and hope what was defined in the beginning is still what the customer wants.
XP requires everyone to stretch beyond the "standard" development method. But for some reason, developers don't think they need to stretch.
The lack of future planning in XP is not a flaw, it's like that on purpose. I believe that hacking is the best most ideal way to code. XP facilitates hacking on a company wide scale, so even non-developers understand the progress being made.
Loverly Staw Man you have there. (Score:4, Insightful)
XP, like any other process, fits some places and doesn't fit others. While some XP nut-cases may claim otherwise (just like people who market Rational products may claim that RUP should be used for everything), I've never seen the claim made in the pro-XP literature that XP was good for everything.
XP is appropriate for projects where:
Requirements are likely to change or are not well understood.
The customer is readily available
The team is reasonably experienced in the tools being used
etc
Air traffic control and missile guidence, while hopefully satisfying the third item up there, don't satisfy the first two. The customer is generally unavailable (I'm guessing here), and the requirements are understood remarkably well. Further, since these would be critical government projects, you wouldn't even have the choice to use XP. Heavy up front documentation is the only way to go on them.
Perhaps a better statement would be "I'd hate to be around when a major company decides to deploy an accounting system that has been developed with written requirements that aren't in the form I'm used to (user stories) and where the programmers modified the design to suit shifting requirements as they went along." Except, of course, that that is exactly how XP got started and it worked just fine (on a project that had previously been failing).
Pairing works...sometimes (Score:3, Insightful)
Paired Programming (Score:1, Insightful)
> (with two people sitting at one computer). It just
> isn't for everyone.
You know, there are places where pair programming is very helpful. It's part of the job. This whole touchy/feely "it's not for everyone" stuff is BS...it's for people who want others to work around their quirks. We're not freakin' artists, we're software engineers.
Re:Ask Slashdot: Have you used Extreme programming (Score:5, Insightful)
If you don't do pair programming, you need to replace it with a less extreme version of code reviews, such as simply reviewing each patch before it is checked in. The type of pair programming you describe involves no code reviews, and therefore is no substitute for pair programming.
Re:Ask Slashdot: Have you used Extreme programming (Score:3, Insightful)
Right. Also, I forgot to mention how incredibly important it is to switch between being the tester and being the coder. If you don't do this then it's too easy for both parties to be lazy, and there's no way to check or enforce the quality of code.
At my current job, I've actually outsourced the implementation of the tests (because we're a very small shop) but I'm making the product manager the only interface with the test developers. This keeps me honest, and has the "nice" side effect of making me document all of my interfaces and APIs since the other developer isn't even in the office.
One benefit of doing this with two programmers on-staff, as I prefer, is that when somebody leaves a project, there shouldn't be a huge drop in knowledge. I left a project a few months ago that was done this way and the remaining programmer, who was quite junior, was able to keep on going without much trouble since she had been exposed to both the testing and development aspects of the project.
Re:Ask Slashdot: Have you used Extreme programming (Score:5, Insightful)
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
Re:Ask Slashdot: Have you used Extreme programming (Score:2, Insightful)
I'm not sure I follow your reasoning.
How does pair programming hide incompetent programmers? If you're switching pairs often, everyone will have the chance to work with everyone else.
Do you prefer a learning style that requires everyone to make the same mistakes? In my teams, I prefer not to make mistakes at all. In practice, I'll settle for making a mistake once then letting everyone know what it was and how to avoid it. Given experienced programmers, it's pretty handy to start down a path and have your pairing partner say, "Wait... we did something like this before. Here's how we solved it then."
I don't know what you mean by "discourages leaps of faith" at all. That sounds like a positive thing to me. I'd rather go by the empericism of the test suite than mystical intuition that can't be verified. XP's pretty firmly in the realm of "solving the customer's actual problems" than any Kierkegaardian philosophy.
Admittedly, I'm a fan of pair programming. I've used it on a couple of projects and plan to use it on several more in the future.
anyone who says "don't read this book" (Score:5, Insightful)
It's why Liberals need to listen to Rush now and then. It's why neo-cons should read Franken.
So anyone using XP who says "don't read this book" is probably delusioinal in several respects.
As another poster remarked, though, it's a bit annoying to read a review that does not include snips of key points and some analysis. This is endemic in /. reviews. Reviewers, please go look at the form of articles in the Sunday Book Review and follow it!
-dB
Re:It's just an excuse (Score:5, Insightful)
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.
Pair programming == punishment (Score:5, Insightful)
You know, sometimes we just want to pick our noses or read a news story on the web. Pair programming makes this impossible as there is always some idiot practically sitting on your lap. This is why it will always be perceived as punishment.
Re:Bollocks to "software development practices" (Score:3, Insightful)
-Gwala
No True Scotsman Fallacy (Score:4, Insightful)
Does that mean that a necessary requirement for XP to be XP is for it be successful? In other words, the failures disqualify a process from being XP?
Isn't that a rather self-fulfilling condition?
Re:Two idiots don't make a genius (Score:3, Insightful)
Perhaps this way, the code will be commented, have tidy layout, and be readable. Meaningful (to more than one person) variable names might be used. Boundary checking done. Good test cases written, and used. Other programmers may be able to work on this code at a latter date. The code may do what was specified (for this particular task) as the one programmer keeps the other one focussed on the job in hand.
If the developer is *that* senior, he should be capable of explaining what he is doing to the lesser minds in the company. Treat it as a mentor slot. And of course, that's only for 50% - the other half of the time is watching the other guy, advising, perhaps teaching, and guiding.
The question the developer should ask himself, "Is he really a malodorous jerk, or am I so socially inept that I am unable to work with people who may not be as skilled as I am?".
The Emperor has a relatively decent suit (Score:5, Insightful)
I see all the other posts in the thread so far claiming that some or all of these concepts were known earlier, before they were emphasized by XP. But that does not discredit the approach. Frankly, there's rarely anything new under the sun, but sometimes someone has to come up with a kind of philosophy just to help us realize how effective certain ideas can be. I think all programmatic software methodologies are like this -- they try to emphasize methods that are known to have worked well in the past, and try to draw useful generalizations about them.
Nowadays, most of the UP people are adopting many ideas emphasized by XP -- I attended a tutorial by Craig Larman [craiglarman.com] last year in which he argued that no conflict between the UP and XP exists at all. But no one was saying these things before XP was articulated.
Incidentally, I think it's clear that the waterfall is an unmitigated disaster. I was once in a project that was managed that way, a big fat loser of millions, the worst nightmare of my career, took down a whole dot-com agency. Those were the days.
I don't agree with all of XP -- a complex system has to start with a fairly sophisticated analysis and design (but it better be designed flexibly enough to change over time if necessary). And I can't imagine pair programming, never tried it and don't want to. But even if the Emperor is not wearing purple and crimson ermine minks with linings of silver and gold, he's not naked either. On the contrary, his suit is fairly presentable.
Re:Ask Slashdot: Have you used Extreme programming (Score:3, Insightful)
>> it hides incompetent programmers
Actually, it exposes them quicker, as their incompetence becomes immediately apparent to their partner.
Further, it gives the partner an opportunity to improve them and reduce their incompetence.
If that doesn't work, then they're hopelessly incompetent, and you're no worse off than had you not programmed (and indeed, much better than if you'd found out 8 months into development when you did your first code review)
>> reduces the learning that comes from failing at a certain approach
Actually, it increases the learning - that learning is spread around the whole team in short order. The team learn collectively from their failures, instead of each individual having to make them all in turn.
>> and discourages leaps of faith.
I'm not sure what you're getting at here. I have been sat with a partner while he's said "go with me on this one for ten minutes, I want to try something". I shut up, I watch, I learn, I see how he's intuitively solved a problem or implemented a mechanism and saved a ton of work.
Or I've been driving, and I've asked my partner, "I know we should methodically trace through this bug, but I reckon I can find it by guesswork - gimme a couple of minutes to have a go". Two minutes later, bug fixed, several hours of painful tracing averted.
It's about building good communication within the pair, in having faith in each others abilities. What you've been describing is not pair programming.
~Cederic
Re:XP Programming (Score:4, Insightful)
However, there's a lot more to XP, and there are some definite weaknesses in it...I say this as an XP supporter. I'm also going to make the same argument I've made in most of the previous XP articles on here; XP is absolutely great
I was part of an Extreme Programming team that saw both ends of the spectrum. We had internal support, we met with our customer every two weeks and had an iteration planning meeting, and we were productive beyond all reason. When the requirements for part of the project changed, we were able to adapt quickly; our code was small, reusable and modular, so we were able to quickly make adaptations when the end-goal target changed. The code was largely bug-free because of pair programming, where one would work on design while the other coded, and we caught errors much more easily. Meetings were held standing up so that no one wanted them to go on for too long, and it kept them short. Our team was responsible for our own hires, which meant we picked folks who could fit into the pair-programming model well. We took a break every two hours to keep from burning out, we had separate 'personal' spaces as opposed to the pair programming computers...
It was one of the most rewarding development experiences I have ever been part of. Every bit of glowing, golden praise I had heard about XP working well seemed to be true.
But things changed inside the company when management changed hands. We lost the support for two-week iteration planning meetings, and had to work in six-month intervals. We lost the ability to hold stand-up meetings and were stuck in long conference calls. Our team got too large and fragmented into smaller bits, and the pair programming model broke down. Trying to stick to XP became an exercise in frustration and warfare with management. And as we let go of bits and pieces of XP, under pressure, the remaining pieces were weakened. Iteration planning only works if you can actually interact with the customer at an iteration-level, for instance... and so our targets became less easily defined since they were set out months in advance. Made it easier and easier for specific people to concentrate on tasks than having to swap around per-session... which ended up meaning instead of knowing all the code as we had before, anyone able to take over any area, we became specialized in specific areas of the project. And so on...watching XP collapse around us. And it was depressing, really, to see what had been a productive, active environment be stifled.
So that's my first-hand experience. When XP works...it
And more and more, it's harder to find the support for the XP procedures in a corporate environment. Bits and pieces that are in XP -- such as making modifications as they're needed rather than trying to plan overly far ahead for goals that might change, or writing test-suites for your code, and making clearly-understood code -- are of course sensible procedures. But the overall conglomerate only works if you have certain things...support within the
Re:Ask Slashdot: Have you used Extreme programming (Score:2, Insightful)
I've done some pair programming, and I have to disagree here. It's true that the "passenger" will interupt the "driver", but it will not necessarily interrupt the train of thought. Indeed, frequently comments will be along the lines of "why not just do instead?". Moreover, the "passenger" can often help keep track of the big picture, allowing the "driver" to focus on details without getting lost.
This is not to say that pair programming is perfect. For certain drudge work, it's definitely not efficient. Even with two coders who respect each other and get along well, it can be very emotionally draining. But I've almost never felt that my pairing partner and I could have developed *and debugged* code more efficiently by working separately. Indeed, we tended to write remarkably bug-free code when we had a "second pair of eyes".
One thing that I think is necessary for pair programming to work well - both developers need to be as "egoless" as possible. Only when each person can truly listen to and fairly evaluate the others comments while in "the heat of battle" will pair programming work well.
Another Fad... (Score:2, Insightful)
I've seen SO many of these come and go. You can never question them while they're in the ascendancy.
Stage 1 consists of proof by repeated assertion, and "case studies" that actually describe only how projects using the Methodology were _started_. Lots of detail on how managers and workers were organized and brought on board, etc. Anecdotal success stories where you cannot tell whether the success actually had anything to do with the use of the Methodology or whether they just had a good team that would have succeeded anyway, or whether it was just Hawthorne Effect. No clear evidence that _other things being equal_ using the Methodology instead of some other process actually has a beneficial effect.
Stage 2 occurs when a Methodology has been used in enough real projects by a real-world variety of programmers, then you start to see the articles that say "in order for it to work, you MUST have conditions a, b, c, d, and e." One of the conditions is usually the enthusiastic involvement of upper management. But, hey, if you have the enthusiastic involvement of upper management you can probably get ANY project to succeed. Another is usually the adoption of the entire methodology, no "piecemeal" approaches. Another is usually the provision of adequate training. No real-world project ever meets all these conditions, therefore no failed project using the Methodology is deemed to disprove its efficacy.
Stage 3 occurs when people start to notice that the Methodology doesn't particularly work. Well, actually, it's never phrased that way. Nobody ever _admits_ that the Methodology was a fad which has now been abandoned. Instead, they simply say they are adopting the _new_ Methodology, which it is said, DOES work. Or at any rate WILL work. Provided, of course, that you adopt all of it, have the enthusiastic backing of upper management, and adequate training.
No free lunch (Score:3, Insightful)
By all means, read this book (or any other) if you feel it might bring something positive to your development process, and adapt what you can to your own project. Just don't fall into the trap of thinking that XPR (or anything else) will solve all your problems, and if it doesn't that you must not have done it right.