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

FDD is more scalable to larger teams than XP.
FDD does design up front (not big design, but design, nonetheless).
FDD has code ownership: Each class is owned by a single person. They form "feature teams" of people whose classes will change.
FDD encourages formal inspections and automated regression testing, but does not require them.
FDD has ChiefArchitect and ChiefProgrammer? positions.

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

Differences from ExtremeProgramming are interesting

It uses a ChiefProgrammer? for hard parts of design (and the availability of developers able to take on the ChiefProgrammer? role is acknowledged as a limiting factor).
ClassOwners? are defined for every class.
Design is done in terms of InteractionDiagrams?. (This was not mentioned in the description on PeterCoad's web site)
CaseTools are an integral part of the process.

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.