Please create an account to participate in the Slashdot moderation system


Forgot your password?
Programming Books Media Book Reviews IT Technology

Questioning Extreme Programming 492

David Kennedy writes with the following review of Pete McBreen's new Addison-Wesley title, Questioning Extreme Programming. It's one of the few books which casts a questioning look at the buzzwords and concepts of Extreme Programming; read on to see how well XP fares under McBreen's examination.
Questioning Extreme Programming
author Pete McBreen
pages 186
publisher Addison-Wesley
rating 9
reviewer David Kennedy
ISBN 0201844575
summary A critical but fair re-examination of all of XP.

In short:

This is bound to a controversial and widely read title -- it is a critical but fair re-examination of all of XP's assumptions and core practices. It provides a much needed comparison of XP with other, less popular, methodologies. Overall, XP emerges favourably, with one serious caveat -- the author concludes that XP is only suitable for a very narrow range of projects, and those that can fulfill all requirements probably stand a significant chance of succeeding using any of the similar methodologies. As with programming languages, there is no silver bullet -- put XP in your methodology toolbox, know when it is appropriate and only use it then.

A couple of interesting specifics:

  • The author specifically argues, and I agree, that what the XP literature badly needs is a DSDM 'suitability filter' to advise project leaders as to whether XP is for them.
  • In the preface, Kent Beck describes the On-Site Customer role as a team, and not an individual role.
Overall, this is an intriguing and well-argued book. It's based on solid, reasoned arguments, with conservative conclusions drawn based on the evidence. It's a must-read for those interested in XP and other Agile methodologies.

The Extreme Programming Series

This is the 8th title in The Extreme Programming (XP) Series from Addison-Wesley, surely the most widely read series on a software methodology ever! (If that isn't achievement enough, XP also made testing sexy again. I hear that accountancy firms are looking for Kent Beck to do Public Relations work ...) For those of you who have been living under a rock for the past couple of years the previous titles are:

  • Extreme Programming Explained (Beck)
  • Planning Extreme Programming (Beck & Fowler)
  • Extreme Programming Installed (Jeffries et al)
  • Extreme Programming Examined (Succi & Marchesi)
  • Extreme Programming in Practice (Newkirk & Martin)
  • Extreme Programming Explored (Wake)
  • Extreme Programming Applied (Auer & Miller)

This new addition to the XP library feature a foreword by Kent Beck. This is important as many of the reactionary XP fan-club will not like this book -- it challenges XP, and I am delighted to see this title as part of the series. Beck admits he doesn't agree with McBreen's conclusions, but asks you to read the book and decide for yourself, conceding that the arguments are fair and reasoned. I come from a scientific background and distrust anything except wide open debate, a position many who welcome XP will surely agree with. A book challenging XP can only help persuade people to give it a go, by addressing their fears and explaining how to manage any real risk.

Check your sources

Pete McBreen is the author of the excellent Software Craftmanship: The new imperative, a 2002 title from Addison-Wesley. In it he outlines an alternative to the software factory model behind much of traditional software engineering thinking. He proposes a collaborative model with small teams, where the software coder is seen as a craftsman in constant dialogue with the customer. Sound familiar? It should, this is a cross between a methodology and book of advice for career programmers, and fits squarely within the values proposed by the Agile Alliance, and arguably popularised most by XP.

I highly recommend Software Craftmanship, and can think of few authors who are as well positioned to give an analysis of XP as it currently stands.

What is the book about?

Questioning Extreme Programming does just that -- it's the first title in the series to take a skeptical look at the rise of this popular methodology and question some of the key assumptions. Arguably there was material like this buried in Extreme Programming Examined, but it suffered from a fragmented, detailed view, due to it being a bound set of conference papers.

The author tackles XP in a fair way -- he's extremely excited by the methodology, and it's clearly in accord with his own preferred approach. What he does is tackle each of the XP tenets in turn, questioning their validity, and then moves on the compare XP to other Agile methodologies and asks how XP stacks up against the competition. He also has a look at the common mis-conceptions (from both sides) about XP, and tackles the key arguments against its adoption in the same way.

Let's have a look at the contents to give you an idea of the structure:

  • Introduction.
    XP: Hype or HyperProductive?
  • What is a methodology?
    • What do methodologies optimise?
    • What are XP projects scared of?
    • What do other methodologies consider important?
    • What is important for your projects?
  • Questioning the Core XP Practices
    • Planning incremental development
    • Truly incremental development
    • Are we done yet?
    • Working at this intensity is hard
    • Is that all there is to XP?
  • Questioning XP concepts
    • The source code is the design
    • Test first development
    • Large-scale XP
    • Is the cost of change really low?
    • Setting the dials on ten
    • Requirements: Documentation or a conversation?
    • Is oral documentation enough?
    • Playing to win?
  • Understanding the XP community
    • ReallyStrangeSayings
    • Feel the hostility; experience the joy
    • Transitioning away from XP
  • Your choice
    • Is XP for you?
    • Do you have a suitable first project?

What's good?

The whole thing. Let's start with the basics, the high standards of the XP series are maintained, with flawless editing and layout. Moving on, the author's position is admirably neutral -- he is knowledgeable about the field, and although he wants to be converted, he argues only from first principles, and only from the evidence. Similarly, at no point did I think he set up a straw man, or tackled the opposing issues in a different manner. I particularly admired the way he avoided polarising issues -- "All models are lies." -- dismissing them as unhelpful in his current investigation. (He points out that much of the fire in the XP debate has resulted from the use of deliberately polarised opinions as a unambiguous goad to further debate within the XP community. Fine within the gang, inflammatory outside.)

The structuring of the book is of particular interest -- the argument could easily sprawl, but is restrained into very short sub-sections, with each section sporting a clear list of summary bullets. As much as is practical, each challenge to a tenet or practice of XP is discussed independently. (This comes across as simple and straight-forward and you may wonder why I even mention it, but I think it's a fine piece of editing and worthy of praise.)

The sections of the book that I enjoyed most were those dealing with the SmallTalk culture that XP grew out of -- he presents an interesting analysis of why XP works within that environment but discusses how that environment is NOT typical of most development. I have some bias here due to my own experience, see below, but had to agree strongly with his contention that XP is weakest when it comes to team resourcing, and the on-site customer. In particular, he argues that while XP restores dignity and human rights to the programming team, it does so at the expense of the poor frazzled customer. Similarly, he argues that the pre-conditions for XP, in terms of the programming staff, are so high that almost any methodology could be made to succeed with that team.

Don't get the impression that this is a negative work -- it's not. Most of XP emerges intact, and I felt that the author genuinely wanted only to restrain people from adopting XP in inappropriate situations -- not to persuade people to avoid XP. In doing so, he actually protects XP from bad press due to teams failing when trying to adopt XP, them blaming XP itself, rather than their own inappropriate circumstances.

What's bad?

Er, not much. He sort of pulls in some material re Open Source early on, but fails to particularly build on that comparison, moving instead to a comparison of Agile methods in closed source circumstances. This is a feeble objection -- but really, it's all I've got this time!

Anything to declare?

I should probably give a quick sketch of my background before I finish as I am slightly biased -- most of my work has been in the telecommunications sector, where I either worked with a large code-base (legacy) or a large, distributed team (new development). In no way was I working in the XP style, although I became test-infected easily I found it difficult to even imagine how to apply some of the XP practices to my workplace.

XP changed the way I code and work, for the better, but in a large environment, with no contracting customer, and few experts on a complex domain involving simultaneous hardware development I couldn't see any way to do XP. I'm not saying what we did was good, I'll be the first to admit it was broken (hmm, and I'm unemployed now, time to go and think about cause and effect!). The key assumptions of pure XP just didn't fit the industry I've seen most of. (To be fair, McBreen would have called these projects "systems engineering" and placed them outside of the discussion.) Now that I'm seeking employment again, I'm a lot more aware of methodologies and am much keener to work within an Agile framework, as I believe that all of the methodologies, XP included, offer a much better way of developing software. However, the key point remains -- XP cannot be applied everywhere.

Lastly, I should make it clear that I received a review copy of this title from the publisher and did not pay for it. I paid for my own copy of Software Craftsmanship.

You can purchase Questioning Extreme Programming from 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.

Questioning Extreme Programming

Comments Filter:
  • by Anonymous Coward on Wednesday November 13, 2002 @12:34PM (#4660244)
    OK, I'll take the fall here: am I the only one out there who's never heard of eXtreme Programming? Judging from the name, it sounds like hacking code on a laptop, nude in the snow. WTF?
    • by El Pollo Loco ( 562236 ) on Wednesday November 13, 2002 @12:38PM (#4660288)
      man, you are not leet! My clan programs naked, in the snow, while snowboarding down the mountain with explosions going off behind us Triple X style! This we do on a daily basis. And the worst part? To get our pants back, we have to lick a metal pole! But we roXor all!
    • XP explained (Score:3, Informative)

      by Anonymous Coward
      It is a management tool made to look like a geek toy.

      The name attracts geeks: they like 'extreme', they like programming, so XP must be great, right?


      In XP, the idea is that two programmers are constantly working together. One of the two types code, the other watches his every move. "Don't forget that semicolon!" "No, don't do it like that!" "You don't need to do that right now!".

      Having a slavedriver who puts the whip on you whenever you stare out the window (or browse /.) may sound nice to management, but it doesn't make for a nice working environment - in fact I'd say it drives people very quickly to being burned out.

      Another mantra of XP is "never write anything you do not need right now". As with top-down or bottom-up programming, this tries to force the way a programmer thinks into a narrow pattern.

      Personally I've found that I'm at my most productive when I have a good flow going. That may mean writing some support classes first (and completely) and then building something on top, or it may mean going chaotically all over the place adding bits, but it never means doing things precisely in one order.

      I've also noticed that it is not possible for two people to sync their 'flows' when they're coding. Yeah, bring forth the lame jokes...

    • Re:sacrificial lamb (Score:5, Informative)

      by almeida ( 98786 ) on Wednesday November 13, 2002 @02:21PM (#4661409)
      I've never heard of it either. Google found this [] for me. You might be interested in going straight to the What is Extreme Programming [] page. Based on my quick look through their pages, it seems like just another buzz word for something that isn't really exciting (ooooh, listening to customers and testing throughout the development cycle!? How revolutionary!)
      • Re:sacrificial lamb (Score:3, Informative)

        by customiser ( 150740 )
        You might find Pair Programming [], 40-hour week [] and continuous integration [] a little more exciting. I'm not saying that it works or even that you should have heard of it, but a "quick look" is definitely not a good reason for rejecting it.

        Personally I find that some of its suggested methods are right on the spot while others a bit on the idealistic side. Still, I would like to try it and see first-hand how it works in a proper business environment.
      • This [] is an actual explanation of the rules and practices of XP, not just a page full of buzzwords. It seems to center around extensive testing and customer feedback.

        --grendel drago
    • by BitGeek ( 19506 )

      Don't feel bad. You're not the only one-- probably less than %1 of the slashdot crowd has heard of extreme programming. After all, perl hackers and other non-programmers have no need for it.

      Slashdot is not a technology or programming site-- it is a linux fan site. Unfortunately, a surprisingly small number of linux fans are programmers.

      If you do decide to start programming (And that kid who's in his 5th year of CS had better get up to speed!) then XP is something very much worth learning, even if you put none of it into practice.

  • Just like Clinton.

    I personally prefer to be on my own. I could see how managers prefer it because it forces more work to be done and yeah, it prevents a lot of errors, from my experience.
    But I hate it - I hate working right with someone else.
    I personally would rather to just be near someone and ask them questions about code if need be, but I hate the XP experience personally.
  • between extremes (Score:4, Insightful)

    by Anonymous Coward on Wednesday November 13, 2002 @12:41PM (#4660320)
    . Overall, XP emerges favourably, with one serious caveat -- the author concludes that XP is only suitable for a very narrow range of projects, and those that can fulfill all requirements probably stand a significant chance of succeeding using any of the similar methodologies.

    Strange definition of 'favourable', that. Not an attempt at a troll, but the rest of the review didn't tell me how XP emerged favourably either.
  • To each his own (Score:3, Insightful)

    by slantyyz ( 196624 ) on Wednesday November 13, 2002 @12:43PM (#4660347)
    As all slashdotters know, computer geeks can be atheists and religious zealots at the same time.

    Xtreme Programming is one of the hot buttons (as is Unix, Java, Linux, OSX, etc. - the only common religion here seems to be the hatred for MicroSatan).

    Xtreme Programming has a lot of interesting elements (the only one I'm not keen on is the Pair Programming). But, as with anything, if it doesn't work for you, there's probably something similar else you can try - SCRUM, et al.

    The title is provocative enough (at least it isn't inflammatory) that XP fanatics will probably find ways to evangelize their methodology and sell it to anybody who will listen. The book does sound like a good read, because everyone needs a strong dose of perspective now and then.
  • by sam_handelman ( 519767 ) <> on Wednesday November 13, 2002 @12:43PM (#4660348) Homepage Journal
    I do bioinformatics programming. The people I work with are biologists (so am I, actually, but I also have a degree in CS.) They don't have CS degrees, but are pretty computer savvy.

    However, when I say, "we should apply the extreme programming methodolgies,"

    they say,
    "coding to the max!" or
    "what does this have to do with snowboarding?" or
    "the mountain dew commercial was not funny."

    and so forth. They think I'm joking and it is impossible to convince them that Extreme Programming is not either a) a joke or b) marketspeak gibberish crap.

    Now, b) may be true. However, as long as the method is called "programming.... to the extreme!" it becomes difficult to convince people on the intellectually snobbish periphery of CS that it has even potential merit.
    • Couldn't agree more. This method has a serious PR problem; when you try to convince people to use it they usually are scared off right away by the name.

      There is a bit of a catch-22 in introducing new methods: in order to draw people you have to make noise, and that usually scares people to use the method because they think the claims are inflated.

    • Call it Agile Programming. This is what all the "cool" people are calling it now anyway. ;-)
  • by truth_revealed ( 593493 ) on Wednesday November 13, 2002 @12:43PM (#4660355)
    Nothing beats a well orchestrated and well executed plan - i.e., a written and documented plan. If software specifications are not worth formalizing on paper - it isn't worth creating. You can keep your extreme voodoo. It just formalizes the lazy practices of programmers. 50% to 90% of software projects fail because of embracing fly-by-night "technologies" like this. I thought Extreme Programming was buried for good with the dot bomb implosion.
    • Planning (Score:5, Interesting)

      by Lumpish Scholar ( 17107 ) on Wednesday November 13, 2002 @01:07PM (#4660630) Homepage Journal
      Nothing beats a well orchestrated and well executed plan - i.e., a written and documented plan. If software specifications are not worth formalizing on paper - it isn't worth creating.
      XP proponents agree with you.

      They'd point towards "the planning game," the XP deliverable for project management. (See Planning Extreme Programming [] for details.)

      They'd point towards "user stories" (very similar to use cases), one XP deliverable for requirements gathering.

      They'd also point to projects where the requirements weren't well defined up front and changed very quickly, and the cost of maintaining detailed requirements deliverables would have slowed the project down enormously.

      And what project doesn't fall in that category? It's a fantasy to think, ala classic "waterfall" development, that the requirements can be set in stone before any of the design, coding, and testing is done. Requirements grow and change as the project progresses, in ways peculiar to the "softness" of software development. (No one would start a project to build a footbridge over a creek, then halfway through want a rail bridge over the Mississippi River.)

      XP may not be the best way to address this, but it's one way; and even as McBreen concludes, it's a good way for some projects. For all projects? No one's saying it is.
    • And can I live there too?!?!

      If software specifications are not worth formalizing on paper - it isn't worth creating. You can keep your extreme voodoo. It just formalizes the lazy practices of programmers

      I'm guessing that you must be self employed or in academia, as it is the domain of management to demand complex solutions to improperly spec'd problems and, oh yeah, we wanted it yesterday. I see this happen all the time where they want a rundown of what are the risks of re-baselining the hardware of our legacy system, and can we get that by Close Of Business today? Oh yeah, and these are the same people who say "BTW, try to follow our Business Practice Process if you can, never mind that we completely violated it already"
      Oh yeah, we are a fortune 100 company.

      And guess what? I don't gamble. I don't drive too fast, nor sky dive. I don't need drugs to get high. I get my kicks by trying to meet unrealistic deadlines. I love death marches... its the only way to know I'm alive ;)

      P.S. XProgramming fits right into this real world model.
    • by X ( 1235 ) <> on Wednesday November 13, 2002 @01:11PM (#4660669) Homepage Journal
      The common pratices before XP became popular were to do exactly as you described. The problems with this are many fold, not the least of which it makes your development process extremely inflexible and unable to adapt to change, the tendancy to get locked into analysis paralysis, and the simple inability to define a plan when tackling a problem or technology that nobody has familiarity with.

      FYI, XP isn't a "technology", and it isn't fly by night. It's based on successful practices that have existed in one form or another for decades. I have no idea what practices you think are in XP that in any way reinforce laziness. XP actually fights a number of lazy behaviours that programmers have. All it does is bring together a number of successful practices and espouse doing them "to the extreme" in order to combat the naturally lazy approaches of programmers.
    • From this I take it that you are a fan of the 'Waterfall' model of software development?

      Jack William Bell
    • In XP, the test scripts should be written first (test-first programming) before the code features they test. These are (sort of) requirements specs, because 'if it's not in the tests, it shouldn't be in the code'.

      Of course, a requirements spec is not the same as a set of test scripts, but then XP also has user stories for a more user-comprehensible outline of what's being delivered.

      • by Dom2 ( 838 ) on Wednesday November 13, 2002 @02:06PM (#4661255) Homepage
        Test First is a godsend!

        I've started doing test first for all my programming now and I've found that it helps in several areas:

        * Forces you to think upfront about what you're doing and helps catch stupid errors right there.

        * Tends you towards a better, more separated design. This is a natural consequence of testing.

    • 50% to 90% of software projects fail because of embracing fly-by-night "technologies" like this.

      No. 50% to 90% of software projects fail because the requirements, problem domain, and customer expectations change at least 5 times during the course of a one year project. I've been on two failed projects in the last 3 years, both of which failed because the customers continually went back on their own decisions for which we had based our "written and documented plan", long after we had been heavily involved in the code. By the time the "final" decision was made, there was no time to actually implement it.

      I'm not saying XP would have saved them (it likely wouldn't), but assuming that a well-documented design and plan will save a project from the curse of changes in requirements and expectations is self-defeating.

    • Embrace Change (Score:3, Informative)

      That is something that should be read by all "Waterfall []" developers like you. It is very useful, even if you don't change your opinion.

      Damn. IHBT. :)
  • But wait! (Score:2, Funny)

    by Black Parrot ( 19622 )

    Surely you're not suggesting that something with an 'X' in it's acronym isn't way cool.

  • by HYauSB ( 622065 ) on Wednesday November 13, 2002 @12:44PM (#4660363)
    I read the whole article trying to figure out what he was on about. eXtreme Programming? Can anyone give a definition of it? What exactly is it that XP is, and why does this book challenge it? How did XP change the way he codes and works? What is this "popular methodology?" Because that's what I'm most interested in. The author of the above book review assumes everyone has read the book, or knows all about XP.
    • Check this [] out.
    • heh, XP is sorta like a formulated Build and Fix model...The REALLY basic description is below

      1. Divide your project into a bunch of moduals
      2. Make teams of 2 programmers and assign each modual. Program it without worrying too much about how things fit together. Both members work on the same code(2 people to 1 computer)
      3. Fit the moduals together

      Step 3 is the limiting facter, Large projects suffer from too many hacks, and well defined projects suffer because of unneeded hacks...

      It works very well for small projects(under a year), where the requirements change a lot.

      • XP is sorta like a formulated Build and Fix model

        No, it's not. It's really very structured. The simple definition given above is one of the main reason XP-projects fail.
        Basically XP is a bunch (11 or 12?) of well known best practises taken all the way out (if code review is good, then more code review is better, so let's code review all the time).
        It's heavilly based on communication, so it will break down with large teams. It's also missing an architecture step, so large projects tends to fail, if you don't "cheat". And it's missing testing. But if the product is rather small, the people on the team communicate well, and your QA-team gets a go at the app occasionally, you'll be doing great.
        Probably the best thing about XP is that it brings back the fun in programming. Writing out-of-date documents isn't any fun.


    • by angel'o'sphere ( 80593 ) on Wednesday November 13, 2002 @02:18PM (#4661378) Journal
      Someone with three questions like this:
      I read the whole article trying to figure out what he was on about. eXtreme Programming? Can anyone give a definition of it? What exactly is it that XP is, and why does this book challenge it? How did XP change the way he codes and works? What is this "popular methodology?" Because that's what I'm most interested in. The author of the above book review assumes everyone has read the book, or knows all about XP.
      gets modded as Insightfull?

      He is not "cluefull" enough to make a google search?

      Anyway: XP is set of about 12 "best habits" you should follow in programming.

      Whereas other software developmnet processes focus on a lot of work wich is not programming, XP focuses on doing a lot of programming and incorporate the other work: analizis, design, as good as possible into the programming "phase/workflow".

      The most known "buzz words" are programming in pairs and unit tests.

      But: there are 12 :-)

      -- Have your programming team at the customer side, or the customer in your house.

      -- refactor, if you see a strange couple of lines of code, refactor it

      -- only program what you imediatly need, Saying: "You ain't wanna use it". So don't program overabstraced "framework like" code as it likely will get refactored away or won't be needed anyway

      -- use storry boards, similar to use cases, well in fact similar to Scenarios, but a lot of literatue mixes up the difference between Use Case and Scenario

      -- imediat feed back: make a story board with the customer, see above, prepare a unit test for it, see above, code it, refactor every existing code in your way to support your new story, run the unit tests of teh old story boards to be sure nothing broke during refactoring, run your new unit test to your new story board, show the result to the customer, adjust storyboard and repeat if needed

      -- plan the architecture, "play your way through it", buzz word: "planning game", e.g. use CRC cards

      -- short releases, plan a day per "story board" or major feature

      -- collective ownership, all code belomngs to the team, ther eis nothing like YOUR file/class or code

      -- have a system metaphor, thats an architecture pattern, basicly have an other system you can compare your current work with

      -- learn and communicate

      Well, read a book, get a consultant and DO it.

      You won't be able determine if it WORKS or not by trying it half hearted for 3 weeks.

  • by Anonymous Coward on Wednesday November 13, 2002 @12:46PM (#4660391)
    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.

    By the way, what SEI CMM level _is_ Microsoft at?
    • by j3110 ( 193209 ) <> on Wednesday November 13, 2002 @01:43PM (#4661037) Homepage
      You seem to define fad in an odd way. You suggest that anything that comes then goes is a fad. To the average person, I would asume that fad meant that it came and went without any effect. You are assuming that in Stage 3 that the original item didn't effect the building of the next best thing. Object-Oriented programming is based on procedural programming. Eventually, it could become that procedural programming is abandoned, but will not have been a fad because it's "replacement" is a derivative of the original.

      I think XP is great because it was the first system designed to teach how to program responsibly. I'm sure it will be replaced by something better, because AFAIK, no one has pioneered perfection in a new field in their first shot. You can bet the farm that the next "fad" will be based on XP. I think you are afraid to change the programming methodologies you already have; therefore, from your point of view, no programming methodology will be more than a fad, because it's not yours and you will never adopt it.

      BTW, I've never heard of anyone saying that peicemeal approaches to XP won't work. I've heard the exact oposite. Some people implemnt pair programming, some have great programmers they can depend on (the reasons for pair programming are so that one can catch the others errors, one may leave and someone will need to take over for him). A lot of people implement the test units because no coder is perfect and the synergy of a large system of object (be they libraries or classes) can cause one small change to break a lot of the system. In a large system, you can't remember every little thing you should test and it would be very time consuming to test them by hand.

      All things die to give way for the next generation. That doesn't make yesterday's champions fads, but rather old heros.
    • if you have the enthusiastic involvement of upper management you can probably get ANY project to succeed.

      You seriously believe that?
      The enthusiastic involvement of upper management can help, but it's by no means a sufficient condition.

      I've seen lots of anthusiastic managers who don't notice when their teams is saying

      • The requirements don't make sense
      • We don't have time
      • You need to invest in more testing
      • This project is doomed

      It's not about enthusiasm, it's about management being supportive of the development team, and the development team being right.
      If you don't have both of those, then you will have problems.

      In my experience management can kill a project, and they can help a project avoid death, but they can't make a project actually work.

  • Summary (Score:5, Insightful)

    by freuddot ( 162409 ) on Wednesday November 13, 2002 @12:49PM (#4660424)
    I'll summarize the book ( without reading it ) :

    For extreme programming to work out, you and your team need to have outstanding ability.

    XP(extreme programming) is great, but add into it a shaky designer, a loner in the team, or a delusionned (sp?) manager, and the whole thing will crash down in flames. In traditionnal methodology, the problem would rather settle with a non-optimal development process. With XP, you either fly high or crash badly.

    The fact that it is a great development model and the fact that it will not work in most places are not incompatible.

    But that's just my experience. Take it with a few tons of NaCl.

    • Re:Summary (Score:3, Insightful)

      by tpv ( 155309 )
      XP is great, but add into it a shaky designer, a loner in the team, or a delusionned manager, and the whole thing will crash down in flames.

      I'm not sure it's that black and white.
      I would suggest that in XP (and most other agile methodologies) you need the following three roles to be well filled:

      • Architect
      • Project Manager
      • Lead Developer
      Depending on your project/team size, one person may fill more than 1 role, (or you may need 2 people for a given role).

      I don't think the developers need to be that great. It obviously helps - better people produce better results - but it's not required.
      I guess if they're hopeless developers then they won't cope, but I think that's true in all methodologies.

      Other methodologies will possibly cope without those roles, but they will still (ultimately) be failures (assuming the project has sufficient complexity).

      We took an existing development team that was decent, but not brilliant, an enthusiastic project manager and added a couple of experienced people (an architect and a developer), and the project is working very well. Much better than any previous methodologies we used.
      Part of that is due to the people we brought in, but they're really only there because we needed some architectural guidance for this project (we were using some technology that was new to our existing architects) and we wanted a mentor (both for XP and for the technology).

      Once we get enough people with experience, we won't need them anymore, and I think we will still be successful - but you don't need people to fill those roles.

  • Test First Coding (Score:4, Informative)

    by osullish ( 586626 ) <`osullish' `at' `'> on Wednesday November 13, 2002 @12:52PM (#4660459)
    Where I work we've recently adopted Test First Design, Initially we all hated it as the learning curve is steep, and it doesn't really make sense the first few times round.

    Initially we took an old project and applied Unit testing to it, which really turned us off the concept. But once we started a new project, and wrote the test cases before our code it suddenly made sense!

    Now its instinctive for us to write the test cases first, It also allows cuts down on refactoring later as all our code is at its simplest level always. If our code is changed in the future, any problems will be identified straight away.

    I'm sure in the future we'll attempt the other concepts behind XP

    • by blirp ( 147278 )
      Where I work we've recently adopted Test First Design

      Just remember that TFD is a Design method, and really has nothing to do with testing as in testing the requirements. So it will check that you coded what you designed. Whether that has anything to do with what the customer wanted is another matter.
      Which should be checked by the functional testing, but that's written by the customer. And most customers don't know what they want...


  • by selkirk ( 175431 ) on Wednesday November 13, 2002 @12:52PM (#4660461) Homepage

    XP has an active and interesting mailing list [].

    More information about XP can be found here [] or here [].

  • testing ideas (Score:3, Interesting)

    by Tablizer ( 95088 ) on Wednesday November 13, 2002 @12:58PM (#4660523) Journal
    It is a good idea (for somebody) to experiment with software engineering ideas. I have no problem with that. However, these conditions should be met:

    1. Test it on willing and knowing *volunteers* only.

    2. Don't claim it is "better" until it has been road-tested for a while. At least 3 years and preferrably 15.

    3. Identify where it works and where it does not, or at least be clear about the domains and situations and scope about where it does work so far.

    There are too many credit-cravers and talking heads out there pushing buzzwords into the mainstream before they are tested properly. They should take some clues from the medicine industry. Sloppy pushing may not (directly) kill people, but it can certainly kill the economy and IT credibility, as we have already seen.
  • If that isn't achievement enough, XP also made testing sexy again.

    Erhm, no, it didn't. Nothing's sexy about XP. IMHO, XP took much of the fun out of programming. The chaos that is open source development brought it back.

    People seem to think that pretending programming is always as complicated as particle physics is going to somehow produce better code on time. I don't. Sometimes coding 9-5 in pairs and creating ten AbstractFactoryContainerXYZYourMom objects each time there's a need for a one line getter method just isn't the way to do it. It might be necessary when working on safety critical systems, but I doubt even that, as formal methods is probably what will dominate in those cases anyway, and for your average off the mill app there's just no need. But, as I've already said, what's worse is that it's no fun.

    And don't give me that "statistics has proven XP is not only more reliable, but also much faster"-bullshit. I've seen it in action. It just ain't true.
  • by matticus ( 93537 ) on Wednesday November 13, 2002 @01:07PM (#4660627) Homepage
    I worked as an intern this summer at a small company in Grand Rapids, MI. We were complete XP to the core. I was very nervous coming in because I have heard about how difficult XP is to do right. However, with our company, everything worked. Here are what I think a company needs for XP:
    • FOOD in the programming area. So what if it'll mess the keyboards up. A hungry programmer is a bad programmer. Always have snacks. If your coders are getting fat, give them something healthy. Always have food.
    • People who get along and have similar levels of experience. Pairing with a person who knows much more or less than you do is counterproductive. However, pairing with someone who knows their stuff like you to is great.
    • Smart boss/project manager. This person won't do much of the coding, except pair when needed, but the team really needs someone who knows their stuff to be the leader.
    • Clients who understand what XP is. If they do, they will be incredibly happy with your work. If they don't, they will be very confused.

    We used these four concepts and since the code we put out was so much better than anything our clients had ever paid for, we had more work than we knew what to do with. It was incredible.

    Oh-and Boss, take the guys out for a beer at lunchtime every once in a while, and encourage a 5 minute break every hour or so. A happy coder is a good coder.
  • XP advantage (Score:5, Insightful)

    by DrinkDr.Pepper ( 620053 ) on Wednesday November 13, 2002 @01:12PM (#4660679)
    The main advantage to productivity is that it is unlikely both programmers will share the same opinion about how to waste one's time. Both will feel guilty about wasting the other's time so neither will screw around as much. Slashdot's effect will wane.
  • Horrible (Score:4, Insightful)

    by Anonymous Coward on Wednesday November 13, 2002 @01:15PM (#4660714)
    Extreme Programming seems to be another step in the disturbing trend of turning coders or engineers into robot-computers. Under XP, if you have to fire one of your robots, there'll be more people who can understand what Fired Robot X did, because he never coded anything alone. It also tends to suck the "guru" right out of coding. Consider if you had a pack of middle-of-the-road coders, and one guru. Under extreme programming, the guru becomes a loner, and a drag to the team (note how there aren't actually any individuals, just people to "make code"). Since a pair of fools are better than one guru under extreme programming, you can fire the guru.

    The bottom line is not to mistake a business model for a work model, and to avoid anything that mixes business with design.
    • Re:Horrible (Score:3, Insightful)

      by greenhide ( 597777 )
      Sorry, coding isn't saddlery. Or glass-blowing. Or painting. Heck, it isn't even woodworking.

      People like to talk about coding as a "craft", and in a sense, it can be. And sometimes, really gorgeous code (either because it's really well written, or beautifully obfuscated and compressed) can be treated like a work of art.

      However, the greatest use of coding isn't for creating masterpieces to hang on the walls of the Met. Instead, it is for businesses so, yes, business has to be mixed in with design.

      Starving artists are artists who, because they refuse to commercialize their art in any way, shape or form, are unable to sell it (until they're dead, at which point it sells like hotcakes). Ever heard of the phrase, "starving programmer"? You probably haven't. And there's a reason for that. While not all programmers are poor, those who do it for a profession generally try to make their code into a commercial product, or are paid by a business to create it in the first place.

      In my own experience, whenever there is a sense of "ownership" over a project or code within that project, the project suffers. It no longer becomes about the code, it becomes about the personality of the programmer.

      I think that valuing individuals is a function of company politics, not development practices. Never underestimate the downside of being "irreplaceable." Right now I work in a firm where I'm the only one who is working on a specific project. I"m desperately trying to get others at my job understand it. Why? So I can go on vacation without feeling guilty or anxious about things going wrong, or about the client needing new features. So I can eventually leave the company and go on to other places, without leaving the company in a lurch.

      Programmers aren't becoming robots; they still far exceed computers in being able to translate real-world needs into working code.

      I am leery of anyone who feels that they are a guru. If you see Buddha coding on your computer, kill him. But eliminate the "guru" label: Since a pair of fools are better than one [more experienced programmer] under extreme programming, you can fire the guru. Wrong. The more experienced programmer can help manage the project, or can serve as one of the paired programmers. A pair of fools are not better. A pair of good programmers are. If the "guru" is truly wise, he will be glad to work within the team. If he choose to be a loner, he probably has some personal issues to work through, and work is not the place to do it.
  • by Dr Thrustgood ( 625498 ) <> on Wednesday November 13, 2002 @01:17PM (#4660749)
    Not so!

    The only acceptable sport / hobby / whatever for which such a prefix can be done justice: Extreme Ironing [].

  • by 5n3ak3rp1mp ( 305814 ) on Wednesday November 13, 2002 @01:19PM (#4660770) Homepage
    We had a relatively complex data integration job that was failing under certain circumstances, but the author couldn't figure it out. Since it was a very important job (affected revenue tracking, among other things), the larger IS team decided to toss out the whole thing and start fresh using XP... with not just 2 but 3 engineers looking at the code (while only the programmer "on deck" actually entered code). I was one of those engineers.

    (FYI- This was a large T-SQL job on SQL Server.)

    We'd add a feature, then add the test of that feature to the unit test, then run the test and fix bugs. Worked great!

    We didn't adopt EVERY aspect of XP... but I have never seen such clean code and neat ideas emerge out of one project. We all agreed that the end result was better than any one (or two) of us could have done individually, and the 9 man-hours spent (it all took just 3 coding days) were WELL worth it, in the boss' opinion...

    That said, we planned on adopting XP in some larger projects, but it kind of fell by the wayside...
  • by Lumpish Scholar ( 17107 ) on Wednesday November 13, 2002 @01:21PM (#4660789) Homepage Journal
    Extreme Programming was in part a reaction to "heavyweight" methodologies, such as the Rational Unified Process [] (RUP).

    XP was first out of the gate with a lot of publicity. There are other ideas, though, about how to do effective, lightweight, "agile" software development.

    See the "Agile Alliance" website [] (Google cache []), or either of the books titled Agile Software Development, one by Robert Martin [], one by Alistair Cockburn [] (both intellectual heavyweights in the software development field).

    There's a lot of good stuff out there, not all of it being done under the XP banner.
  • by cjustus ( 601772 ) on Wednesday November 13, 2002 @01:34PM (#4660952) Homepage
    I think that there are some benefits to XP:

    Designing for the next iteration -- not the entire system... In some cases for designs to be useful, the developer must code a portion of it as a prototype to demonstrate that their idea will work and is effecient... If someone says that they can forsee all implementation issues at design time, they are either lying or spending too much time designing :)
    Regular communication with the end user / customer ... This just can't be done enough... I think that any methodology that calls this to the attention of the development team / project managers is a "good thing".

    On the other hand, some things are not so good/realistic... The biggest thing being pairs programming ... I'm not aware of any organization that is actually doing this... Forget about working from home, putting in long hours, etc if you start using this technique... I'd be curious to hear about organizations doing this, with success...

    Finally, I agree that change in requirements is inevitable, but I think that it has to be properly managed... You can't keep getting new and potentially radically different requirements from the client every two weeks, without seriously burning out the development team... and you can't tell me that requirement changes don't affect costs... Like everything in a project, changes must be managed and negotiated... The development team can work hard to implement software, but can't bend time and space to do so...

    My 2 cents... And yes, I definitely practice what I preach :)


  • by CresentCityRon ( 2570 ) on Wednesday November 13, 2002 @01:44PM (#4661046)
    Everyone is posting about XP but I would like to address the review.

    It was rather thin. I didn't see much insight into the book's ideas or even the writing style. I didn't come away with any sort of idea if I should buy this book or if it would be of use to me.

    I like book reviews. I think this was more like a very short book description and summary of the table of contents. Reviews talk about a view and not just a summary.
  • by SunPin ( 596554 ) <slashspam&cyberista,com> on Wednesday November 13, 2002 @01:46PM (#4661064) Homepage
    The reason that professional programmers and uninitiated observers can agree that Extreme Programming is a joke is because it *is* a joke.

    The only people that write about ideal methodologies and their theoretical applications are academics. I am reluctant to use the term "scholar" on these people.

    The key to a successful project is design. Even OSS projects have a design. Anybody can attempt to write for the project but if it doesn't fit with the design or is too far off base to incorporate into the design, that code doesn't get into the next release.

    Extreme programming is a ridiculous term. Perhaps a better description is "ad hoc" programming.

    Think about evolution itself and you'll see how much damage ad hoc programming can cause. :)

    • The key to a successful project is design. Even OSS projects have a design. Anybody can attempt to write for the project but if it doesn't fit with the design or is too far off base to incorporate into the design, that code doesn't get into the next release.
      I think the problem with your perspective, and with waterfall-type methodologies, is that they distinguish "design" from "implementation". This isn't engineering, and programmers aren't construction workers building to the blueprint.

      A program is a design. It is the formal specification of what the computer (the real construction worker) is supposed to do. Every piece of code written should be a plan and a design.

      Of course, that is not always true -- there's a lot of boilerplate and code that requires no thoughtfulness. But it is up to good programmers to eliminate this as much as possible -- to abstract away the parts that require no thoughtfulness, to eliminate portions that are redundant, and to build ourselves tools that will concentrate our effort.

      • It seems to me, that saying "code is design" is a lot like saying "the code is the documentation." Yeah, in a sense it's true, but code by itself is crappy documentation. The same for design. Code to display a JPEG is not a JPEG specfication. You may be able to figure out a partial JPEG spec from code to display them, but that doesn't make it a specfication. You need a design before you start writing code. That way you know if your code does what it's supposed to.
        If you plan to do a good job on a complex project, coding is engineering. You don't just sit down and start coding a database/compiler/opeating system you think about it first. You consider things like: "This operation is O(n^2) can it be made O(NlogN) and if so what is the tradeoff?" "How fast does this program have to run? Is that feasible?" "Are these data structures efficient?"
        People actually go to engineering schools to get degrees in Computer Science for a reason. Knowing how to write good code, is not the same thing as knowing how to write in some particular language. It requires an understanding of what goes on inside a computer. You need to understand things. A good programmer knows that a floating point division by 2 is much slower that a shift right by two and will use that knowledge. Computer Science is a type of engineering.
    • Extreme programming is a ridiculous term. Perhaps a better description is "ad hoc" programming.

      Think about evolution itself and you'll see how much damage ad hoc programming can cause. :)

      Evolution? You mean, how it went and produced humans? Undoubtedly, an embarrassment.
  • by cartman ( 18204 ) on Wednesday November 13, 2002 @01:51PM (#4661113)
    XP entirely consists of about 20 helpful programming tips:

    "write unit tests first."
    "leave optimization 'till last."
    "develop iteratively."

    ...and so on. These helpful pointers are treated as if they were the ripest wisdom, but actually they're just common sense. They're obvious to anyone who isn't retarded. The few things in XP that are controversial (like pair programming) don't work.

    The importance of XP is exaggerated to an incredible extent. I've heard more than one person compare XP to OO! Consider the vast amount of thinking of research that went into the development of OO. XP is comparable in importance to a "Frequently Asked Questions" file for beginning programmers.
    • by starling ( 26204 ) <> on Wednesday November 13, 2002 @02:57PM (#4661781)
      These helpful pointers are treated as if they were the ripest wisdom, but actually they're just common sense

      The thing about common sense is that it isn't very common. If those tips need to be dressed up in some shiny! new acronym to make people follow them then I'm all for it. Just don't expect XP to magically make all projects turn out perfect.

      The importance of XP is exaggerated to an incredible extent. I've heard more than one person compare XP to OO!

      Oh, I don't think XP's been quite as badly over-hyped as OO.
  • please move along (Score:5, Insightful)

    by KyleCordes ( 10679 ) on Wednesday November 13, 2002 @01:53PM (#4661140) Homepage
    I've had very good results with XP-ish techniques. On some projects I use just a handful of the XP practices; on others, nearly 100% of them. I've used all of the practices enough to understand them, and have found that the XP community has an unusual concentration of effective, smart people.

    Yet I have little interest in XP-sucks-XP-rocks flamewars. In fact, because of the good results I've had, I'd really much prefer if my competitors decide that XP is a terrible idea, pair programming is insane, writing tests first is totally backwards, integrating every few weeks is plenty often, and changing requirements are a nightmare. It would suit me just fine if my competitors reject XP completely.

    So please, if you're curious about XP, forget about it. There's nothing to see here, please move along.
  • My eXperience (Score:5, Insightful)

    by Lordrashmi ( 167121 ) on Wednesday November 13, 2002 @01:57PM (#4661173)
    My team tried out Extreme Programming/Pair Programming (yes, I know there is a different and I guess ours was more Pair then Extreme but anyways) and we had mixed results.
    The best team was when one of the programmers was very good at design, documentation and managing how the pieces fit together while the other programmer was good at the 'bits'. Coding an individual section based on what the first programmer told him. That team worked wonderful and churned out alot of work because thier strengths were complimentary.

    However, another team just had to programmers who sucked at managing the process, design and documentation and both just tended to write out code. This led to conflict both in how the code worked (each coded a section without thinking how it would work with the other section) and between the two programmers.

    We are back to individual programming now, just with freqent code reviews. Also we love to go through CVS checking for bad habits and bash whoever did it (Sucks when you point out a issue and then realize you are responsible for it though).

    Summary: I think it all depends on the type of programmers and what they are good at on if any methodology works.
  • by Aron S-T ( 3012 ) on Wednesday November 13, 2002 @02:23PM (#4661436) Homepage
    The problem with all software methodologies is that they are usually associated with some software guru who is trying to make big bucks as a consultant selling his brand. Also methodologies very often become religions, with the head guru being the leader of the cult. This is understandeable since most software developers depend on a song and a prayer to get their code to work. XP is a good example of both trends.

    I wrote a white paper on software methodology which you can download here []. I am an agnostic when it comes to methodologies, but there is alot you can learn from what's out there.
  • by Sparks23 ( 412116 ) on Wednesday November 13, 2002 @04:30PM (#4662765)
    I joined a company a year and a half ago, becoming part of an Extreme Programming development team. And I was pretty skeptical at first.

    I mean, here I am, coming into a compiler-and-assembler design team and I'm being told that we have to /share/ computers? That we have /weekly/ design meetings? And all sorts of other strange and unfamiliar things.

    But to my surprise, it worked. We each had our own 'personal space' computer for e-mail and everything else, and when we were working we went into our lab as a group. We'd look at the board of current 'stories' (overall larger tasks) and pick a 'task card' from the story. (Literally, taking an index card off the corkboard and clipping it into a little holder by our computer.) And then you sat down at a computer with two monitors, two keyboards and two mice and you pair programmed. If there were an odd number of people, you had to have someone else go over your code with you before you checked it in. All code had to have tests written for it /before/ the code was written, and the code couldn't be checked in until the tests -- and all existing tests -- passed.

    And to my surprise, it worked. With two people looking at code, the little mistakes were harder to make. Design problems were more easily tackled. Because we all shifted around and changed partners a lot, we all learned all the areas of the code and had a better understanding of the system as a whole. The way tasks and suchnot were partitioned out worked very well. Meetings didn't interrupt the flow of things, because almost all meetings /had/ to be held standing up. (I.e., everyone starts to get tired, and when people start sitting down a meeting had to end.) We took a fifteen minute break every two hours to keep from getting into fugue states, and because of that productivity we were never working overtime (thus keeping us from burning out). It was one of the most rewarding development experiences I've ever had.

    BUT...this also became a story in how Extreme Programming can /fail/. We lost support within the rest of the company for the XP process, and that hurt a lot; XP relies on getting weekly or bi-weekly feedback from your 'customers' (i.e. the target for your project), as well as having them set what the more important tasks for the next two weeks were. Suddenly, we were having to plan out things six months in advance and operate in a vaccuum, which really hampered the Extreme Programming method. In addition, our team was expanded...and we learned the difficult way that while XP works really well for an 8-person team or so, it does /not/ mesh well with larger teams.

    So, I actually would probably agree with the book's assessment; XP is well-suited for certain situations (small team, active customer feedback and support, quick dev cycles), but will fail miserably (and I do mean miserably, as in ruining the morale of the team) if you do not have the full support infrastructure.

    Admittedly, some of XP's practices -- tests written before code, meetings held standing up to keep them from dragging on indefinitely -- work pretty well even outside XP. But the system as a whole works well only within a specific target range.
  • by BitwizeGHC ( 145393 ) on Wednesday November 13, 2002 @04:59PM (#4663063) Homepage
    ... is that it is tied to Smalltalk, and hence to object-oriented methodology.

    OO isn't the only way to program. It isn't even the best way to program, in certain situations.

    XP, Design Patterns, and fads like these are all nice in that they reflect certain practices which make for good software. But they are the CS equivalent of "How to Draw Comics the Marvel Way": great at what they do, good at expressing the concepts behind a particular style/method, not very useful when you want to cross over into other styles/methods.
  • by istartedi ( 132515 ) on Thursday November 14, 2002 @12:43AM (#4666075) Journal

    Extreme Programming Explained (Beck)
    Planning Extreme Programming (Beck & Fowler)
    Extreme Programming Installed (Jeffries et al)
    Extreme Programming Examined (Succi & Marchesi)
    Extreme Programming in Practice (Newkirk & Martin)
    Extreme Programming Explored (Wake)
    Extreme Programming Applied (Auer & Miller)
    Extreme Programming Debunked (Archie D. Bunker)
    Extreme Programming Filters Into Academia (Fileas Snodgras, PhD)
    Learn Extreme Programming in 21 minutes (QUE Books)
    Extreme Programming Departs And Thanks You For All The Fish (Sqeeeeeek sqk sqk sqk)
    Designing, Touting And Debunking Methodologies For Fun And Profit (Popular Science Press)
    Extreme No Money Down Real Estate (Carlton Sheets)

MESSAGE ACKNOWLEDGED -- The Pershing II missiles have been launched.