Feature Driven Development

computer systems and human organizations

A place to speak about complexity arguments applied to software development with no relation with any particular method, a group where everybody can speak about complexity, chaos, complex adaptive systems, etc, etc without the need to keep "On Topic".

Not only software development people but also others "men of science" interested in the field (biologists, mathematicians and, why not, experts in psychology and social interactions).

Starting from Mike Beedle work at http://www.livingmetaphor.org/ our main goals are:

When I first learnt about FDD, I was impressed by it's simplicity and clarity. As a development process, it stood well out from the crowd when compared to other far more cumbersome & complex processes that seemed only to make things harder. After learning more about FDD, my opinion of it as a development process was not in question, I wanted to use it. The issue was whether I could apply it to what I did, ie. web development And if that was possible, how to go about making it happen?

The short answer is yes, you can use FDD for web development. How? That's not so easy, as web development covers a wide range of project types, how to apply FDD will depend on the nature of the project at hand.

The original Visio file of the one page FDD process diagram if anyone needs to modify it for use.

De Luca on FDD Newsletter #2003-03

There is a problem that crosses gender, that crosses culture,and crosses international boundaries. Programmers all over the world - regardless of race, religion, sex or geography - have this significant word definition problem. The problem word is finished.

View the HTML archive of this newsletter. Subscribe to the newsletter by using the Newsletter box on the home page of this site or by clicking

A Practical Guide to Feature-Driven Development (The Coad Series) author: Stephen R. Palmer,John M. Felsing asin: 0130676152

This is a diagram I put together for my team based on Jeff De Luca's work and the book "A Practical Guide to Feature Driven Development"

A short but interesting article:

"Understanding the Psychology of Programming", by Bryan Dollery

Read on for the Abstract and some comments...

"Contrary to popular belief, programmers more frequently resemble artists than scientists. If you want to maximize the creative potential on your development team, you've got to start thinking about the psychology of the programmer and be willing to back it up with management policy."

The article begins with the presumption that programming is in many ways a creative activity. FDD considers devleopment to be a human activity, which is not exactly the same thing, but the principle that development is not a mechanical process is something that we can hopefully all agree on.

"Agile development is an attitude, fitted with selected policies and techniques. It is achieved by the sponsors, managers, and developers, jointly.

This conference is an integrated, 4-day conversation about those attitudes, policies, techniques; about both development and management; accessing the latest thinking and bridging communities that rarely get a proper chance to exchange thoughts." Alistair Cockburn, conference chair.

"Agile Software Development is an emerging and dynamic discipline. The overriding objective of the Agile Development 2003 Conference is to spread knowledge about the state-of-the-art in Agile Development practices and provide a forum for advancing the state of the art.

After reading the discussions on continuous frequent delivery, I was reminded of some misconceptions regarding the "two weeks" rule that's mentioned in FDD.

Firstly: what is it? When building the features list in process #2 we decompose the domain into a Subject Area (SA), Business (BA) and Feature hierarchy. The guideline for the granularity of features is that it should take no more than two weeks to complete, i.e. to put through processes #4 and #5 (design and build by feature). If it's bigger than that we break it down further.

The first common misconception is that all features are two weeks long, and that we perform processes #4 and #5 for a single feature that lasts for two weeks. This isn't how we do it. There's a discussion of workflow elsewhere on this site, but bascally the Chief Programmer (CP) bundles up a set of features into a work package, forms a feature team, and then takes the package through processes #4 and #5. The size of the work package is not fixed, and depends on a lot of factors. There is no hard-and-fast rule about how big a work package should be.

This is hardly a surprise move but it still will be very interesting. Read the story here.

In this article, I would like to look at the Agile Manifesto Principles and see how FDD relates to each.

This article is only a draft, and feedback is actively solicited!

Agile processes have rapidly gained mindshare over the last few years as practitioners, disillusioned with the so-called "heavyweight" processes have sought to find better ways of delivering software to spec.

FDD was around before the Agile Manifesto was published. But FDD seemed to be aligned with the values expressed in the Manifesto, and thus was placed under the same Agile umbrella term. There are quite a few processes that fall under this same umbrella; apart from eXtreme Programming and FDD, there is Scrum, and others.