Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×

Extreme Programming Refactored 444

Posted by timothy from the can-you-remind-me-of-my-mantra dept.
fancellu writes "Extreme programming (XP) first hit the mainstream programmer consciousness a few years ago, with the publication of Kent Beck's Extreme Programming Explained. XP was controversial back then (and still is), because it argued in favour of hitting the 'reset' button on accepted software development practices." fancellu reviews below Extreme Programming Refactored: The Case Against XP, and offers this disclaimer: "I should point out that I get a couple of small mentions in this book (the authors quote an email from me), and I also happen to agree with a lot of what the authors say. But I'll try to be as impartial as I can with this review."
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.
This discussion has been archived. No new comments can be posted.

Extreme Programming Refactored More

Extreme Programming Refactored

Comments Filter:

  • Uh-oh (Score:2, Flamebait)

    by jbellis ( 142590 ) *
    That's almost as bad as reviewing a book titled "Linux isn't always the answer."
  • I am delighted to see that XP has now been revisited and is being shown to not be the end-all of development styles. Perhaps with the slightly less "extreme" version, more managers will be willing to accept the changes. I have never had a boss accept XP, simply because they were scared of it (IMHO).

  • Absolutely Hopeless and Clueless (Score:3, Insightful)

    by mihalis ( 28146 ) on Tuesday October 07, 2003 @12:35PM (#7154747) Homepage
    The Previous Extreme is pure fantasy. It has been well known for a long time that big bang or waterfall models don't work well. For example see the Ian Sommerville Software Engineering book - it's mentioned the 'spiral' model (iterating out from the core of a small well understood system) for at least ten years. I couldn't read any more of this "book review" after such a bunch of nonsense.

    • Re:Absolutely Hopeless and Clueless (Score:5, Insightful)

      by AJWM ( 19027 ) on Tuesday October 07, 2003 @01:05PM (#7155027) Homepage
      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.
    • The "waterfall" was great for determining exactly what the user wanted but then ended up delivering it five years later after the requirements had changed.

      "Use-case" analysis was great for determining how the user would interact with the system but tended to automate the existing processes instead of figuring out how automation could make the process unnecessary.

      OO was great for implementing the non-reusable objects determined to be needed by "use-case" analysis (see previous item).

      Too many shops impleme

  • Ask Slashdot: Have you used Extreme programming (Score:3, Interesting)

    by kilroy_hau ( 187226 ) on Tuesday October 07, 2003 @12:37PM (#7154766) Journal
    Well, have you?

    I'm about to start a project using pair programming (not exactly Extreme, but something like that) and I don't like it one bit

    Pair programming is uncomfortable on our reduced space. And it's noisy.

    Are the inconveniences worth it?

    • Re:Ask Slashdot: Have you used Extreme programming (Score:4, Insightful)

      by bokelley ( 563370 ) * on Tuesday October 07, 2003 @12:46PM (#7154844)

      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.

      • I think that is an incredibly simple and extremely powerful idea!! Sometimes when you have been programming for a while you just need the mental rest you get from working on your own. I think that the next time I feel like a break while pair programming, I will try to suggest to my pair-programming partner that we split up and one of us focus on the tests while the other is doing the production code.

        I think it could be especially useful when you are working on a problem that you are not really sure how to

        • 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 docume

          • At my current job, we have three developers. We work on projects as a group, on three seperate machines near each other.
            The steps we follow:
            1. We are all involved in project design.
            2. One of us writes up the requirements.
            3. The others review it.
            4. Two of us write the code while the other designs tests.
            5. The tester tests the system then works with the coders to fix the problems.
            6. Repeat last step until the bugs are gone and the project is ready for beta
            7. Beta testers test.
            8. All three developers work o

      • Re:Ask Slashdot: Have you used Extreme programming (Score:5, Insightful)

        by bunratty ( 545641 ) on Tuesday October 07, 2003 @01:10PM (#7155075)
        The point of pair programming is not to force programmers to communicate with each other. Pair programming is "the knob turned to 10" on code reviews... if code reviews are good, then do them all the time, as a programmer is first writing the code.

        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.

        • That is a good point. I forgot to mention the other important part of this, which is that people switch roles often on the same component. This is my version of turning the dial up to 10. If you think about it, the point of a code review is to make sure that code is clean and legible (and more or less efficient) so that maintenance is easier. What better way to do this than force people to modify each others' code on a regular basis?

        • Pair programming attempts to take two mediocore programmers and create one decent programmer out of them. No senior developer is going to put up with some malodorous jerk sitting on his lap asking questions about every line.
          • Nope, pair programming takes two hackers and attempts to turn them into one disciplined programmer.

            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
      • except if one programmer doesn't like slashdot, it will make the other more productive...

      • I would have to say that pair programming isn't really worth it.

        It's certainly not worth it all the time, but there are times when it can boost productivity. Let me first say I've never worked in a pure XP environment, but on several projects we've cut & pasted from XP and used what works well for us.

        Pair programming can work well when you're still developing the logic that will drive the application. Why? Because at that point, you're not coding for 8 hours straight. You're coding a bit, runnin

    • Yes, its worth it. Take two programmers: one more skilled then the other. Give the less skilled one the keyboard. Force the skilled guy/girl to have to communicate all typing through the less skilled guy/girl. Less skilled guy/girl not only gets a good understanding of what went into the code (they typed it) but also learns new things from the smarty. Eventually you have two smarties. Repeat.

      Who hates the idea of pair programming? Smarties ofcourse. They dont want to lose what they feel makes them
      • How true. Everybody knows the most profitable companies are run by drooling troglodytes. I'm just kidding, I'm sure you mean the prima donnas who nobody can stand...

        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

      • Re:Ask Slashdot: Have you used Extreme programming (Score:5, Insightful)

        by AJWM ( 19027 ) on Tuesday October 07, 2003 @01:18PM (#7155155) Homepage
        Who hates the idea of pair programming? Smarties ofcourse. They dont want to lose what they feel makes them special.

        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 ;-) 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?

        (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 ;-)

    • > Pair programming is uncomfortable on our
      > reduced space.

      Sounds like someone needs to provide your team with pair programming-friendly space. A wide desk is a start.

      > And it's noisy.

      What's noisy? The space you're in? The other people? The person you're pairing with?

      > Are the inconveniences worth it?

      Those inconveniences aren't intrinsic to pair programming. Don't give up yet...

    • Re:Ask Slashdot: Have you used Extreme programming (Score:5, Funny)

      by pmz ( 462998 ) on Tuesday October 07, 2003 @12:52PM (#7154887) Homepage
      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.

    • You said "about to" but then say you don't "like it one bit". Hmmmm, sounds like you made up your mind *before* trying it. Tsk, tsk.

      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:Ask Slashdot: Have you used Extreme programming (Score:4, Insightful)

      by javatips ( 66293 ) on Tuesday October 07, 2003 @01:02PM (#7154999) Homepage
      The concept of pair programming already exist in a good team. No need to force people to work all their time in pair.


      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, ...). In genral, the person will ask one of his fellow team member help to solve the problem. Natural Pair Programming! This is much more effective than having 2 persons work on the same problem (which is trivial 80% of the time).


      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.

    • I've been though a lot of XP. I feel pairing is one of the more crucial aspects of XP. In other words, if you don't pair, you're not doing XP. Make no mistake, pairing is not for everyone. Do you have a cranky,maverick,social misfit who writes brilliant code? Let 'em...don't try to force 'em to pair. Pairing works when a) the people want to pair, b) the people are socially compatible. Pairing forces you to code...no surfing or other dicking around. One coder grabs the keyboard/mouse and does some work, sa
    • I equate Pair programming to brainstorming: necessary but not used during the entire process.

      The web is an entire world filled with programming resources, and is easily accessed to most programmers. With this resource at hand, don't we all already have help when we need it? Are we not already working with one another?

      Perhaps I miss the point.

    • Pair programming worse than halved the productivity of a project I worked on. I suspect it works best in environments with a lot of incompetent people, as long as you pair off the incompetents with the more competent. My environment was full of more competent individuals, so the code-review benefits were not only not positive they were net negative as people were forced to do things by compromise which could better be done by just having one individual do it 'their way'.

      Bottom line: since pair programmin
    • Are the inconveniences worth it?

      Yes, they are.

      We have used it long before XP and in a completely different context - complex mathematical problems as well as data aquisition and process control systems. When the logic and the underlying math are hair-raising having another set of eyes following the development is extremely beneficial. Also, some people have a talent to drive and some people have a talent to navigate. This also means that you are usually either the pilot or navigator and there is no such

  • You put your chocolate in my peanut butter (Score:5, Funny)

    by Anonymous Coward on Tuesday October 07, 2003 @12:37PM (#7154773)
    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.
    • XP and refactoring are buzzwords...

      But if you plan on coding efficiently and making if a dynamic and scaleable system is required, they are both essential.

      After all we dont want any "bad smells" (XP phrase) to occur, this can result in "decaying code" (XP phrase)

      If you dont use XP and refactoring, your code may work, but it will suck. Even if you dont call it that, any good programmer already does 99% of the things in XP and refactoring, it is just an attempt to set good practices for the IT world.

    • This a most telling quote as most developers have never talked to an actual customer in their entire career.

      I agree. Having done freelance work, I've seen plenty of clients that know they most definitely want 'X', but beyond that, they're not sure. Chances are, since they aren't thinking like developers or software architects, they aren't thinking through the ramifications of particular decisions. They could be either overanalyzing a particular use case, or not thinking through it enough. Actually, c

    • "On-Site Customer" (Score:3, Informative)

      by Joseph Vigneau ( 514 )
      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...

      • Re:"On-Site Customer" (Score:3, Informative)

        by kelzer ( 83087 )

        "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...

        Can't remember which XP book it was in but one of them stated that if necessary you can use a proxy for the customer. I think they gave an example of an internal project manager or business analyst. Obviously, the more the proxy knows about the customer's business, the better.

  • Definition of a review (Score:5, Insightful)

    by sphealey ( 2855 ) * on Tuesday October 07, 2003 @12:39PM (#7154786)
    Perhaps I have been reading the New York Review of Books too long, but when I read a "review" I like to see some quotes from the actual book, some arguments for and against, some footnoted references to counter-arguments (it is fine if the reviewer considers the counter-arguments weak, as long as they are noted). In other words, something more than a prose advertisment.

    sPh

  • Factual errors (Score:4, Informative)

    by linuxislandsucks ( 461335 ) on Tuesday October 07, 2003 @12:40PM (#7154793) Homepage Journal
    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...

    • Re:Factual errors (Score:5, Insightful)

      by tcopeland ( 32225 ) * <tom@NoSPaM.thomasleecopeland.com> on Tuesday October 07, 2003 @12:46PM (#7154842) Homepage
      > XP like any software process allows you take
      > 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.
      • "it's hard to pair program"

        Actually, I dont think it's hard to pair program. The difficult part of pair programming is finding the right combination of pairs. Stick the wrong people together and you get a pair that is less efficient combined than either would be on their own. Stick the right pair together and you get more done than both of them working separately.
      • No, if you're rejecting XP because you don't like those things you are EXACTLY RIGHT to reject XP. As you said- those are two core components of XP. If those two components of XP do not work for you, then XP as a whole will not work for you. The fault there is in XP.

        Newsflash: there is no holy grail of software processes. Different processes work better for different team sizes. Different processes work better for different project types. Different processes work better for different teams, due to th
      • XP isn't called 'extreme' because it's risky or adventureous. It's 'extreme' because it takes the best practices of the industry and uses them all.

      • Now where are those mod points, when you need them?

        I quite agree. Actually if you read the first XP book, one of the main point are that if you follow all the ideas, they merge together and support each other.

        There's a nice diagram in the book somewhere that show how the different methods support each other.

        But then again, you don't have to do all of them "extremely". Just doing all of them just a little, bit will be a lot better than big-ball-of-mudd or the usual chaos development method used.

        In most c
    • If memory serves, Beck disagrees.
      Unit testing frameworks can be put in independently of the rest of the XP system. Pair programming maybe. Everything else is only postulated to work on an all or nothing basis.
    • It's such that pair programming is SYNONYMOUS with Extreme Programming.

      Every shop I've talked to, up to this date, about a job that did XP as their development methodology were strongly into the pair-programming along with everything else. I'm not sure WHY they seem to think that pair-programming is an absolute must with XP, but all the shops using it seem to think so.

  • Middle ground? MIDDLE GROUND?!? (Score:5, Funny)

    by burgburgburg ( 574866 ) <splisken06&email,com> on Tuesday October 07, 2003 @12:42PM (#7154806)
    Have you not been paying attention? This is the land of EXTREEEEEMMMMEEEE!!!!.

    Reasonable, well thought out, non-extreme methods mean the terrorists have won. Oh, wait. That's a different article.

    Anyway, how do you scream at the top of your lungs "MIDDLE GROOOOOUUUND"?

    • Anyway, how do you scream at the top of your lungs "MIDDLE GROOOOOUUUND"?

      It's a Zen koan, man...kind of like how you would scream "I am drinking in MODERAAAAATIONNNN!" at a frat party.

      Of course you might just get your ass kicked for that.

  • Balance (Score:3, Interesting)

    by randall_burns ( 108052 ) <randall_burns@@@hotmail...com> on Tuesday October 07, 2003 @12:44PM (#7154824)
    The XP guys _have_ made a mark in the world. Now, how that is going to work out longer term, remains to be seen. XP _is_ influecing stuff like IBM's Rational Unified Process.

    I tend to like XP. I haven't worked in an XP shop, but I have used it in class projects and some project of my own.

    Right now, lots shops have processes that are non-existant or chaotic--that is what XP really needs to be compared against. XP isn't "the emperor" more like an upstart prince edging in on the territory of being eyed(but not governed) by Emperor RUP.

    My gut is that was is motivating books like this:
    is the fact that XP is being adopted in places where stuff like RUP just would never get a toe in the door in its present state.

    The major stages of the opponents of an invention:
    a) it won't work
    b) its evil
    c) its not really new
    d) we invented it

    This stuff strikes me as somewhere between stage a-b.

    • The major stages of the opponents of an invention:
      a) it won't work
      b) its evil
      c) its not really new
      d) we invented it
      Except for some inventions it's:

      a) first they laugh at you
      b) then they forget you

      It's not obvious yet that XP follows your map rather than mine, though a bit of familiarity with the history of sna^w overhyped methodologies might help guide a gambler's bet.

  • XP (Score:2, Funny)

    by CGP314 ( 672613 )
    Sounds just as bad as windows XP

  • Sheesh. (Score:3, Insightful)

    by Earle Martin ( 647758 ) on Tuesday October 07, 2003 @12:46PM (#7154845)
    "I should point out that I get a couple of small mentions in this book (the authors quote an email from me), and I also happen to agree with a lot of what the authors say. But I'll try to be as impartial as I can with this review."

    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)

    by boomgopher ( 627124 ) on Tuesday October 07, 2003 @12:47PM (#7154855) Journal
    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.

    • Having a design (or at least a set of requirements) probably helps too.

      Perhaps you're of the old school and were rolling all the other job titles like analyst, architect, designer, coder and tester into the "programmer" umbrella, but these days that term is mostly synonymous with "coder" with a bit of "designer" thrown in. (Come to think of it, even in the old days "analyst" was separate, and I've had the job title "Programmer-Analyst" -- which is not a psychiatrist for coders ;-)
      • You "design" point is not orthogonal to the items in the list in the post you responded to. So while "a design" is certainly valuable the OP indicated a set of circumstances that in his experience would lead to success. Most likely this succes would incorporate "a design".

    • 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.
      Heh. I thought you were serious until I got to that last one.
    • That's great, until you realize:

      You have no idea how to hire good programmers without getting a bunch of bad ones too.
      You don't have any money to pay programmers until you've already developed something you can sell.
      If you have enough time to do the job right, it's because you don't know what your customers want yet. By the time the job is done right, you'll need more time to make the job right again, because "right" has changed.

      Seriously, the first one is the important one. You can't just get progra

  • Is this a review or a rebuttal? (Score:4, Interesting)

    by Maclir ( 33773 ) on Tuesday October 07, 2003 @12:49PM (#7154870) Journal
    I would have like to have seen less of the pre-emptive rebuttal and more reviews on some of the findings and recommendations.

    Drop the dogma and theology, and give us the hard core, nitty-gritty, down and dirty facts.
    • The hard core, nitty-gritty, down and dirty facts are that the use of XP is four times as slow, irritating as can possibly be, and would not EVER be allowed by the vast majority of seasoned programmers.

      Next time you are programming think of what it would be like to have someone looking over your shoulder arguing about class definitions or variable names. Projects take two programmers twice the time as the better of the two would use to do it alone. The best is when you get stuck halfway through a re-factor

  • Maybe he shouldn't have reviewed it... (Score:3, Insightful)

    by matchlight ( 609707 ) on Tuesday October 07, 2003 @12:50PM (#7154874)
    After reading the disclaimer "I should point out that I get a couple of small mentions in this book (the authors quote an email from me), and I also happen to agree with a lot of what the authors say. But I'll try to be as impartial as I can with this review." I was a little skeptical. It's pretty easy to enjoy a book that uses your ideas for content. I know it's not an entire book written around one e-mail but it's always a nice stroke to the ego to be found printable. That aside I think that although he did point out that the the writer is fair in his addressing the good and bad of XP and that the review is likely close to the truth, I feel as though the reviewer has taken more than great lengths to defend the book against the nay-sayers and "zealots". I'd like another review before running out to pick it up.

  • Bollocks to "software development practices" (Score:3, Informative)

    by Boss, Pointy Haired ( 537010 ) on Tuesday October 07, 2003 @12:51PM (#7154879)
    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 .

  • XP v the Engineer (Score:2, Interesting)

    by MosesJones ( 55544 )

    I'm one of those people who have seen XP tried and failed, and to be honest I never found it a suprise. I was educated to be a software engineer, and that the best way to deliver software effectively is to understand the problem domain. Iterative models like RUP or DSDM are great ways of delivering functionality quickly... XP is not... however there are some ideas in XP that are completely un-original that can work

    1) Pair programming - first seen in the "Surgical Team" idea from the mythical man month

    2)

    • Re:XP v the Engineer (Score:5, Insightful)

      by tcopeland ( 32225 ) * <tom@NoSPaM.thomasleecopeland.com> on Tuesday October 07, 2003 @01:00PM (#7154980) Homepage
      > the best way to deliver software effectively
      > 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.
    • I understand you are not fonding of XP in general

      How do you feel about:

      1) Pair programming

      2) Unit Tests upfront

      3) Iterations

      Do you feel these are good things?

    • You say:

      You don't need requirements before you start coding


      and later...

      Quality doesn't matter


      I say:

      Dude.

      XP is all about requirements and quality. You meet with the customer every day. You have regular meetings to evaluate progress. You write exhaustive unit tests. You perform daily integrations.

      You havn't seen XP fail. What you saw wasn't XP. I don't know what it was.
  • What XP Set out to Fix
    XP set out to fix a lot of things.

    How XP Fixes it
    Unfortunately it fixed few of them.
  • The real answer is somewhere in between XP and formal architecture. You need practical experimentation and you need design together to finish anything. A purely extreme programming environment would go around in circles without heading to a goal. A purely architectural environment would never get a practical solution.

  • My experience (Score:5, Interesting)

    by OYAHHH ( 322809 ) on Tuesday October 07, 2003 @01:06PM (#7155032)
    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...

  • Loverly Staw Man you have there. (Score:4, Insightful)

    by MacGabhain ( 198888 ) on Tuesday October 07, 2003 @01:06PM (#7155035)
    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!

    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).

  • Major problems with this book (Score:5, Informative)

    by HenryFlower ( 27286 ) on Tuesday October 07, 2003 @01:11PM (#7155091)
    The XP advocates are not as far out or as hard line as one would think reading this review, or the book to which it refers (disclaimer: I've not read the book, but have read much of the source text which appeared on the authors web site). There are debates on the extremeprogramming Yahoo group constantly about how far to push emergent design versus design up front (one of the major advocates of XP, Martin Fowler, takes a dissenting view on this matter), about pair programming and how to manage people who don't pair well, etc. There is also a fair bit of self-directed humor by the major advocates for XP. XP needs thoughtful critique, and books (such as Pete McBreen's) that do this are well received.

    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.

  • I think Extreme Programming XP made some significant improvements over Extreme Programming 2002, but it will be better when the .NET framework comes in the box in Extreme Programming 2003
  • Everyone I have come across in person who claimed to have used XP turned out to be someone who didn't have a clue.

    On the other hand I know plenty of people who use what could be termed XP on daily basis, yet I doubt they ever read XP books or even care about it.

    In general XP is a buzzword for the managerial types, the process described therein is pretty much common sense with a bunch of bells and whistles attached.

  • It's just an excuse (Score:2, Interesting)

    by curtlewis ( 662976 )
    Extreme Programming or Rapid Application Development is just an excuse to bypass solid process in order to ship faster. Does it do the job better? No.

    General problems with the approach:

    Design on the fly. You get less features, more hastily implemented. Code is less maintainable.

    Without a plan up front, you have QA scrambling to keep up. Testing is full of gaps in coverage. Product is more buggy as a result.

    The only real benefit is shipping faster. You make everyone work harder and get an inferior

    • Re:It's just an excuse (Score:5, Insightful)

      by chromatic ( 9471 ) on Tuesday October 07, 2003 @01:42PM (#7155386) Homepage
      I'd like to see a lower level of defects maintained and value to customer in stability, reliability and functionality/features increased.

      How would you achieve this? I'd probably do things like:

      • Set coding standards and follow them.
      • Work on a small piece at a time and get it right.
      • Get the customer involved in making sure every piece is right.
      • Deliver working code to the customer every couple of weeks.
      • Have every piece of code reviewed for cleanliness, correctness, and good team style.
      • Have a comprehensive test suite at the programmer level.
      • Develop a comprehensive test plan at the feature level by working with the customer.
      • Revise the design and code as necessary to meet the customer's current needs.
      • Make sure that architects code and coders do architecture have every technical person participate in the whole project, design and coding.

      Of course, by the time you do all that, you've got the heart of XP.

  • anyone who says "don't read this book" (Score:5, Insightful)

    by dbrower ( 114953 ) on Tuesday October 07, 2003 @01:33PM (#7155313) Journal
    has questionable intellectual honesty. One of the best things you can do to validate your belief in something is to occasionally understand the criticism of it by people who really do question it, not the quibbles of fellow believers.

    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

  • Pair programming == punishment (Score:5, Insightful)

    by Ars-Fartsica ( 166957 ) on Tuesday October 07, 2003 @01:46PM (#7155431)
    The bottom line is that no exceptional programmer is ever going to be forced to have someone watching everything he types.

    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:Pair programming == punishment (Score:4, Interesting)

      by Cederic ( 9623 ) on Tuesday October 07, 2003 @03:43PM (#7156606) Journal

      Have you ever actually tried pair programming?

      I'm not an 'exceptional programmer' - I'm just a fucking good one.

      When pair programming, I benefit from the expertise and experience of another developer. I avoid making silly mistakes, because he spots them for me. I don't write as many bugs, because he spots them. I don't dither about variable names, or whether to refactor a method, or which algorithm to use - because I have someone to help me keep focussed, someone that helps me make swift decisions, that keeps me on track and moving forwards.

      Sure, sometimes I want to read a news story on the web. That's why when pair programming we take a break every hour or two. It depends on the progress we're making, how focussed we are, whether we've got the code to compile and pass all its tests.

      Pair programming is not punishment. It's an enlightening experience, a joy to participate in, something I want to do more often.

      Nobody is such an exceptional programmer that they can't learn from someone who still needs to look up the language syntax. Lose your ego, open your mind, and actually try PP.

      ~Cederic

  • No True Scotsman Fallacy (Score:4, Insightful)

    by jjohnson ( 62583 ) on Tuesday October 07, 2003 @02:22PM (#7155749) Homepage
    Every time someone here said "I've seen XP, and it didn't work," the XP defenders say "what you saw wasn't XP".

    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?

  • Why stop at 10? (Score:5, Funny)

    by greenhide ( 597777 ) <jordanslashdotNO@SPAMcvilleweekly.com> on Tuesday October 07, 2003 @03:04PM (#7156180)
    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.

    Nigel: "All the numbers go to 11..."
    Director Marty Dibergi: "I see, and most amps go up to 10. Does that mean it's louder?"
    Nigel: "Well, it's one louder, isn't it? You see, most blokes will be playing at 10...you're on 10 on your guitar. Where can you go from there?...Nowhere, exactly. So when we need that extra push over the cliff, you know what we do?"
    Marty: "Put it to 11."
    Nigel: "Exactly. One louder."
    Marty: "Why don't just make 10 louder and make 10 the top number and make that a little louder?"
    Nigel (chewing gum, pauses while he considers the question, then states confidently): "These go to 11."

  • The Emperor has a relatively decent suit (Score:5, Insightful)

    by Get Behind the Mule ( 61986 ) on Tuesday October 07, 2003 @03:17PM (#7156315)
    Unit testing, especially as a foundation for refactoring; continuous integration, read hourly builds; and the flexibility to revise design decisions when the need becomes obvious -- all of these principles are absolutely indispensible in any modern software project. Failing to do any of these things is an outrageous, inexcusable lapse. But these ideas are better understood and more obvious now than they were before Kent Beck came along with XP.

    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.

  • No free lunch (Score:3, Insightful)

    by YouHaveSnail ( 202852 ) on Tuesday October 07, 2003 @09:13PM (#7159343)
    I don't care if it's structured programming, OOP, Smalltalk, Java, RAD, use-case analysis, XP, or XPR... no language, tool, methodology, or management style can provide a quick fix for the difficult problems of organizing, designing, implementing, and maintaining a significant software project.

    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.

Slashdot Top Deals

Every cloud has a silver lining; you should have sold it, and bought titanium.

Close