Feature Driven Development Vs Extreme Programming

An article comparing FeatureDrivenDevelopment and ExtremeProgramming appeared in Issue 70 (Feb 2002) of TheCoadLetter newsletter, editor StevePalmer.

Full text at http://www.thecoadletter.com/article/0,1410,29684,00.html

See "Short Comparison with XP" section, for comments about XP.


The article says...

Hmmm... Forming teams based on design plans would place restrictions on what changes can be made.


Differences from ExtremeProgramming are interesting

The color modeling aspects is used as part of a ModelByArchetypes? approach that is an expansion of the earlier ideas from PeterCoad.

There is a very strong parallel to ExtremeProgramming in that PeterCoad seems to be warning against spending a lot of time getting the models right before getting some concrete working results. -- PeteMcBreen


Any thoughts on fusing or merging XP and FDD ? -- ChanningWalton

It's happening ... see AgileProcesses.

Somebody will undoubtedly dream up a meaning for the "fusion" if there is money to be made out of it.

Actually, FusionMethodology antedates all this agile stuff. TeamFusion/EvoFusion tried to follow along ... is anyone still doing any con-fusion?

Forgive the cynicism of someone who has seen the BigDesignUpFront method people gradually sidle first towards objects and then more extreme EvolutionaryDelivery-based approaches without these six rather significant words about their previous, very highly paid, model first efforts: "Sorry, we got it spectacularly wrong". (I would genuinely appreciate references if this is not fair regarding Coad, for just one example.) -- RichardDrake

FeatureDrivenDevelopment is iterative. It's hard to get the design spectacularly wrong if you're only planning a month (or a few months) in advance.

Working top-down also helps limit many high level risks. Of course, you could still make some design decisions you'll regret later, and find it annoyingly hard to work your way out of them. But I don't think "spectacularly wrong" is really in the FDD cards. -- JeffGrigg

I was referring not to FDD but to earlier method efforts by the likes of Coad (without having ever followed his stuff closely I'll admit; he may have got started on method with EdYourdon and perhaps always been a great influence). The point I'm making is that at a time in the 1980s that WardCunningham and TomGilb, say were pointing to a very different way of doing development, where were the majority of methods people pointing? Does it matter at all about the trillions wasted as a result (rough estimate)? I guess not.


Gee, methods may work for chunking a problem in manageable pieces. If someone is too lazy to perform a reasonably correct decomposition before jumping on his keyboard - well, of course will he tell that methods suck! It takes effort to chunk a project in parts. Most of the time it is 5% inspiration and 95% transpiration even if having a nice architecture and model. Development is still hard work as far as I can see how successful projects do. I saw a project lasting for two years with people not even doing a single model ! Two weeks there and some sweat put in modelling the problem space and most of the stuff is on track to be finished within one month. Methods with an experienced person won.


FDD doesn't sound as fun as XP. Probably good for environments where XP can't be made to easily fit.

-- GlenStampoultzis


Well, XP is fun leads to think that development is always fun. Well, chasing nasty bugs is not always that fun.

EditText of this page (last edited June 26, 2005) or FindPage with title or text search