News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 2/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Visual Studio 2010 Release Candidate Available Today
A Visual Studio 2010 release candidate is available on MSDN.
02/09/2010 09:45 AM EST

Is Microsoft eyeing Office subscription pricing?
Microsoft may be preparing to offer a new Office pricing option called "union," which charges the same for cloud as on-premises.
02/01/2010 09:38 AM EST

Facebook rewrites PHP runtime
Facebook is about to open source its own PHP runtime, written from scratch for speed.
01/30/2010 08:53 PM EST

 

Events calendar tab
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

2/10/2010 to 2/12/2010
San Francisco
BZ Media

2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

2/19/2010 to 2/20/2010
Los Angeles
SCALE

2/21/2010 to 2/24/2010
Las Vegas
IBM


 
Most Read Latest News Blog Resources

Integration Watch: The zealots of agile




March 1, 2009 — 
The agile movement has been nothing if not evangelical, even messianic, since its inception. From its founding with the publication of a manifesto (a manifesto!) to its subsequent, continual attack on the so-called waterfall model, agile and its exponents have hewn closely to the position that theirs is the one true path. And, consistent with this evangelical view, those who disagree either don’t really understand agile or are irretrievably deluded. For the deluded, only spectacular failure of their project will open their eyes.

This point of view makes dialog about agile’s strong points difficult and about its weak points impossible. It fails to acknowledge that agile projects also fail and that, prior to agility, many very large software projects came to fruition without using agile techniques. We did, after all, land a man on the moon without agile. We also routed phone calls, conducted the census, flew aircraft, made reservations, and performed many other activities that relied on large-scale software that met requirements and generated valid results—all without agile. Every major operating system in use today was written with pre-agile techniques. So before lecturing on the one true path, it’s important to acknowledge that other paths can indeed generate successful projects. There is not a single true path. There are at least two.

The agile zealot’s take on the successes of the “other” path generally runs along the lines; that’s all well and good, but the vast majority of all software development projects are failures. The presence of some notable successes does not belie the landscape littered with the detritus of dead or abandoned projects.

I am in full agreement. And in fact this argument brings me to my second gripe with agile evangelism. Agile projects fail too. The widely quoted failure rates of projects have barely dropped since the Agile Manifesto. And while the agile movement might want to lay claim to this small drop (and attribute its small size to the fact that so many projects are not agile), I would disagree.

I speculate that two other factors have contributed more: the huge improvement in the quality and capability of development tools, and unit testing. (Unit testing is not an agile technique per se. In fact, it was used and known by its current name for many years before other agile techniques—Scrum, Extreme Programming, etc.—were formulated. However, unit testing is associated with agile primarily through the prominence of test-driven development.)

Before continuing, I want to make clear that I do not quarrel with agile techniques, only with the movement’s evangelism. In fact, when developing, I very much veer towards agility, although I still occasionally blend in elements from the traditional model. (I would refer to this model as the “waterfall model,” but the term is incorrect. The history of waterfall dates to 1970, when it was presented as a straw man by Winston Royce, not as an actual model to be used.)

Evangelistic fervor has sprung up again in the rather public head-butting going on between Joel Spolsky and various agile proponents regarding Spolsky’s comment: “It doesn't seem like you could actually get any code written if you're spending all your time writing 8 million unit tests, and every single dinky little class […] becomes an engineering project worthy of making a bridge, where you spend six months defining a thousand little interfaces.”

Spolsky’s point is correct, even if the imagery is overblown. 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. Their desire to gild the lily seems inexorable and frequently leads to unconvincing results. (I broke up that code into a separate class and added seven methods for what benefit, again?)

This behavior is tolerable only on small projects. And that’s where the agile exponents leave developers hanging. There is so little experience on all-agile projects with more than 6 million lines of code and, say, more than 2 million unit tests, that we don’t really know whether agile methods scale well, especially since they’re predicated on the use of small teams. Nor do we know what changes need to be made at the level of large projects.

Agile is a set of good development techniques. But by no means is it the only, nor necessarily the best, path. Says Michael Feathers, one of the moderate agile proponents: “Design by Contract works. Test-driven development works. So do Cleanroom, code inspections and the use of higher-level languages.” Any valid techniques applied with discipline leads to quality code. Amen.

Andrew Binstock is the principal analyst at Pacific Data Works. Read his blog at binstock.blogspot.com.


Related Search Term(s): agile


Share this link: http://www.sdtimes.com/link/33300
 

Comments

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


Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading