Feature Driven Development

From email correspondence ...

I just heard PeterCoad speak tonight at the local Java User's Group event. He's promoting (among other things like "color models" and TogetherJ) a thing he calls Feature Driven Design. He's had the motto "delivering frequent tangible working results" for a while, but I hadn't seen this FDD thing. Sounds in many ways similar to ExtremeProgramming:

It's a "lightweight methodology"
short 2 week cycles to deliver features
in the two week cycle, they design and code... including the test harness
In the early phase they
1. do a "model"
2. define the feature list
3. plan by feature
They report progress to management and clients based on features completed (or in progress).

Of course there are a lot of things I didn't hear, and some obvious differences in what I heard, but I'm pretty confident it would work.

I asked him how it compared to XP and he said he didn't know anything about it. Of course some others at the User's Group asked me to present XP there soon (probably June). -- KenAuer

Available Online References

Feature Driven Development Website, http://www.featuredrivendevelopment.com
Details of Java Modeling In Colour With UML http://www.step-10.com/Books/JMCUBook.html
Feature Driven Development and Extreme Programming, Coad Letter #70, http://edn.embarcadero.com/article/29684
Process -- Chief Programmer Work Folders, Coad Letter #72, http://edn.embarcadero.com/article/29682

A Practical Guide to Feature-Driven Development, by Stephen R. Palmer (StevePalmer) and John Felsing ISBN 0130676152

See FeatureDrivenDevelopmentVsExtremeProgramming

We all seem to be rediscovering EvolutionaryDelivery, the EVO stuff from TomGilb. I swiped my version from JonHopkins?. --KentBeck

I used a slightly modified form of FeatureDrivenDevelopment with great success on a smallish (four developers, four months) project. The biggest difference was that I used CollectiveCodeOwnership rather than ClassOwners?, which reduced bottlenecks and improved code quality, in my opinion. -- JimLittle

Jim, I wonder if you had a baseline before coming to an opinion. Did you try the full prescription of class ownership and regular peer reviews? I have real project experience to show that occasionally classes do become bottlenecks, so I agree with your observation. However, when we break the class ownership constraint and allow a free for all on a class, the internal code quality of the class atrophies dramatically within days. I do not believe in breaking the class ownership rule expect under extreme circumstances. -- DavidAnderson

For me, FDD answers the question: what goes into the increments? Typically one finds that use cases tend to be too coarse a unit to fit into a 2-3 week increment. Features, however, are by definition doable in a two-week increment. Furthermore, features are prioritized according to Must-haves (essential), Could-haves (competitive advantage), Should-haves (nice to haves) and Would-haves (future) - MoSCoW, for short - and thus increments can be scheduled (PlanByFeature?) to incorporate some must-haves, a few could-haves and maybe a should-have. This provides a point of negotiation with users when last minute changes to the schedule are required - a must-have can be added to an increment, provided that a could-have is then rescheduled for a later increment.

A limitation of FDD does indeed seem to be the need for many ChiefProgrammers? since they determine the amount of parallelism you can tackle or ultimately how many increments you will need to complete the project. However, we do see the feature team construct (ChiefProgrammer? + ClassOwners?) as a means for dealing with a shortage of experienced developers, combined with a BigDesignUpFront. To tackle the issue of code quality, the BuildByFeature? process incorporates a verification task, CodeInspection?, conducted by the team and outsiders if necessary.

What I am quite interested in doing is incorporating the ExtremeProgramming practice of coding the UnitTest first into the BuildByFeature? process. Some questions I have are: who is then responsible for coding the UnitTest - the ChiefProgrammer? perhaps? and is a feature (which is a unit of deployment) also a unit of testing? -- JamesAitken

I've done enough TestFirstProgramming to think I know the answer: Each programmer should write their own UnitTest(s), preferably before they create the corresponding method(s). The reason is that when you do TestFirstProgramming, you spend the vast majority of your time thinking about and writing the unit tests. That's not because unit testing is slow (although it is slower and harder than regular programming) but because when you do TestFirstProgramming, all of your low-level design occurs as you write the test. Once your done with the test, generally the code itself is easy. So if the ChiefProgrammer? did the unit tests, there wouldn't be anything for anyone else to do. :) If the tests were done after the code, they wouldn't get done. -- JimLittle (Features, by the way, should be tested by AcceptanceTests.)

Some background for those interested: The formalizing of FDD was a collaboration between JeffDeLuca?(http://www.nebulon.com) and PeterCoad while both working on a project in Singapore. Ideas were 'reused' from FredBrooks's book, The Mythical Man Month, TomDeMarco's book, Peopleware, + books by GeraldWeinberg. Add Peter's ideas on features, object modeling in groups and his mantra of 'deliver frequent, working, tangible results' to Jeff's background of rigorous development process at IBM's AS/400 lab in Rochester, Minnesota, USA and a project in serious trouble. FDD was the one of a number of significant results (Peter's modeling in color technique was also pioneered on the same project) - another was the project built on time and to budget. --StevePalmer

I tried XP. Well, some core concepts are okay (DoTheSimplestThingThatCouldPossiblyWork is one of the best ones). To have visibility for upper management, it is not that cool. FDD is better in that respect. I have read the books mentioned up there and believe in them after having led quite some projects. Having made quite some sinful things to developers and having at times paid the price, my deep belief is that FDD is really workable. Especially when the team is not made out of experienced people. By the way, I inherited a project full of junk and I am busy putting it back on track. Damn! -- PhilippeBack

Please tell us more about the visibility problems with upper management. Thanks.

One thing i can see is that customers expect deliveries in terms of features at a particular time. Everyone, documentation, manufacturing, development, system test, field operatives, marketing, etc., all coordinate around those features and delivery date. These are carefully negotiated and scoped.

A constant delivery of small features is not manageable in this framework. A set of important visible features at regular delivery intervals is the organizational principle.

Another issue is the merging of features into multiple simultaneous product branches. This can't be a constant process because of the overhead. It must be scoped and planned with great care.

Each of these issues has zillions of little parts. Management doesn't care about the little parts. It's the large scale features that have visibility. See DevelopmentInProductReleaseContext for more details.

Like JimLittle, above, we have used FeatureDrivenDevelopment on several projects with great success. I wish we had experience with the ColorModeling? approach because we feel it would help ControlVariability?, but the approach and the very straightforward and effective metrics made it very easy to manage these projects. Additionally, these projects have been subject to both military (DO1078(b)) and medical (FDA) regulations and came through with very few audit problems. -- EricWilleke