03/09/2009 04:09:00 PM EST

Perhaps when you assault a movement, you may want to dig into the history a tad more. The Agile Manifesto appeared at least 5 years after "Extreme Programming Explained." Agile didn't start with the Manifesto. And Kent Beck is so close minded to feedback regarding XP that he wrote a second edition to Extreme Programming Explained. A second edition, by the way, that contains many improvements and additions compared to the first book. Feedback he not only accepted but sought. And the movement is so deaf to criticism that they invited Pete McBrean, author of Questioning Extreme Programing to their conferences. Giving him time on the schedule so his voice can be heard. So his anti-XP voice can be heard AT THE XP CONFERENCE. This kind of journalism wouldn't even cut it on Fox News. And by the way, defending your ignorance by claiming "those who disagree either don’t really understand agile or are irretrievably deluded." is not just bad form, it's a fallacy. And it doesn't excuse your ignorance.

United StatesCurtis Cooley

03/09/2009 06:34:47 PM EST

You said: It is easy to endlessly test and endlessly refine and refactor code to the point that it becomes an all-consuming diversion that does not advance the project. And the leading agile exponents Kent Beck, Bob Martin (especially) and others, tirelessly support this. In their writings and lecturing, THERE IS NO SENSE OF WHEN SOMETHING IS GOOD ENOUGH. ############################################################################################# In XP Explained, 2nd edition, Beck says: Software design is curious in that there are usually many designs that are GOOD ENOUGH for the software to be successful. Design quality doesn't ensure success, but design failure can ensure failure. ...[in some cases] purely instinctive design is sufficient. Any old design will do. You can go ahead and design today and be successful. ...[in some other cases]the question of when to design isn't as clear. Careful thought would lead to a GOOD ENOUGH answer, but experience would lead to a better answer. You don't have the option of not designing at all, because unconscious design will lead to failure. Should you make the bulk of your investment in design now, or wait until you have some experience? ...[in yet other cases] incremental design is inevitable. No amount of thought without experience will result in a design that is GOOD ENOUGH. Only experience will result in enough understanding to produce a GOOD ENOUGH design. One factor to take into consideration in deciding when to design is the value available through the different strategies. If pure thought creates most of the value without feedback, designing sooner makes more sense. If experience creates most of the value, designing just enough today to get going and then designing mostly in the light of experience makes more sense. Another factor in deciding when to design is the cost. If you design early, the initial cost of the design is simply the time you spend. Overall costs may be high if you make many mistakes that have to be repaired or worked around for the life of the project. The cost of designing based on experience is the time for the bare-bones initial design, which is lower than that of designing up front, plus the cost of retrofitting later design decisions into running code and live data. Many XP practices are intended to lower the cost of ongoing design. ##################################################################################### Refactoring and Testing are never all-consuming diversions that don't advance the project. They are two key practices that XP uses to lower the cost of ongoing design when it is needed.

United KingdomPhilip Schwarz

03/10/2009 10:42:55 AM EST

This whole article is mean spirited. I don't know why SDTimes would publish a piece full of personal attacks and accusing the reader of delusion for not agreeing.

United StatesStephen Rylander

03/10/2009 06:43:13 PM EST

Although I'm not a "Evangelist" for Agile I think it's pretty great and has lots of value. 1) If you are making the case that Waterfall *AND* Agile projects fail, wouldn't it be better to fail earlier (or know it isn't workable sooner) and spend less money in the process? 2) In your article you talk about software written "pre-agile" without agile techniques, but then you contradicts yourself by talking about Unit Testing (which I think the Agile movement has gotten the word out about) was Pre Agile. I'm sure other techniques that Agilists use existed "Pre-Agile" but it doesn't mean they weren't used in non "Agile" projects in the last fourty years. 3) Not really sure what the point of your rant was or how it adds value to the conversation. You say agile has value and you use it, but it seems you're edifying Joel's remarks which make it sound like a waste of time. If an activity doesn't add value, DON'T DO IT! I don't get why the strawman of bad refactoring is blamed as an Agile thing. Code could be refactored or changed in traditional development or Agile Development. Bad refactoring decisions aren't specific to a single methodology. It's like somebody saying they like a Porsche, but not a Ferrari because their friend crashed his Ferrari - maybe it's operator error at issue; not the choice of car.

United StatesGreg Ostravich

03/13/2009 04:46:08 AM EST

It's all about the people. Good teams will succeed no matter what the methodology and bad teams will fail. But that's the whole point of agile. Why invest loads of time doing a big design when it will not improve your chance of succeeding? Why have loads of methodology overhead when it doesn't pay? When people matter, set them up for success and leave them to do their jobs! The real people in any methodology to watch out for are not the zealots but the dogmatists, the people who try to enforce the rules to an extreme without understanding them. (Or in Spolsky's case the people who attack the rules without understanding them). As waterfall is bigger on rules it attracts more of them but I've seen some agile dogmatists too, although I've yet to see someone promote "endlessly testing and refactoring code" this goes against quite some agile ideas. Luckily the only place I have seen this is in the imagination of people like Joel Spolsky.

NetherlandsMendelt Siebenga

03/13/2009 01:27:02 PM EST

You brought out the XP zealots with your criticism, but that's predictable. If there's one thing that XP zealots hate it is hearing that traditional (heavyweight) methods had lots of successes before agile, and that lots of agile projects have failed. Pete McBrean's book "Questioning Extreme Programming" is a weak critique. It doesn't seriously challenge XP. It's like asking Tim Geithner to criticize Obama's stimulus plan. A more serious critique of XP can be found in "Extreme Programming Refactored: The Case Against XP" by Matt Stephens and Doug Rosenberg. Any real critique of XP needs to include the fact that the original XP project, the C3 project at Chrysler, was a failure. It's important to distinguish between criticism of agile and criticism of agile zealotry. I like agile, but I don't like the sophomoric zeal of so many agilists. Agile would benefit from a dose of healthy skepticism and less of the reactionary, thin-skinned attitudes on display in the comments here.

United StatesDean Schulze

03/13/2009 02:12:10 PM EST

This is getting interesting. Greg and Mendelt both say that one benefit of agile is that agile projects fail sooner than non-agile projects. I've not heard this claim made in favor of agile before, but maybe their point is valid. If a certain number of projects are going to fail it makes sense to have them fail sooner rather than later. Is there any evidence to show that agile projects fail sooner than non-agile projects, and therefore agile failures are less costly than non-agile failures? This is an odd way to defend agile, but it could be a valid point. As an aside I'll mention that both Greg and Mendelt confuse criticism of agile zealots with criticism of agile. They are definitely not the same thing.

United StatesDean Schulze