Feature Driven Development

How do people manage creativity and creative types on projects? How do you identify it, capture it, encourage it, contain it, reward it? Creative people have a reputation for being difficult to manage - do you have particular experiences that shed light on this? What sort of project environment works best? How does the software process help and/or hinder creativity in your experience?

These photos show the How To Design/Deliver Better Software Using FDD workshops in Wellington, New Zealand November 21-24 2005.

Nice place, nice students, nice teacher.

Thanks a lot Jeff!

What are the books on Jeff's A-shelf? In response to possibly the number 1 FAQ from the FDD workshops I have created a new books page on the FDD website.

The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition author: Frederick P. Brooks asin: 0201835959

Chad Dickerson at Infoworld has an article on the top 20 I.T. mistakes to avoid. You can read the multi-page article by clicking here.

This is number 9 from his list.

In his seminal book The Mythical Man-Month, Frederick Brooks posited that planning software-development projects based on per-unit “man-months” ultimately does not work due to the unique nature of software development.

Even if the building of software could be broken into easily managed, interchangeable time units, the vast productivity difference between the best coders and merely average ones means IT managers might get their best work out of fewer, but more talented, programmers doing their work in less time.

Hello,

I am new to this discussion board, so I am going to shortly introduce myself first.
My name is Ivica Aracic, I am a research assistant in the Software Modularity Lab at Darmstadt University of Technology.

Recently I am working on a development methodology for the aspect oriented language CaesarJ (http://caesarj.org).
FDD seems to me like a very promissing starting point for my work, since its feature-driven organizational structure is pretty much compatible with the concept of aspects in AOP. Indeed one could say features are aspects of the considered system.

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

Hugh Walcott inttroduced himself to me in New Zealand on a recent roadshow I was doing for Borland. He handed me a copy of this article from CIO magazine.

A correction though. The book A Practical Guide... was not written by me or Peter. Steve Palmer is the lead author of that book.

Hi,

I like to thank Jeff for a great week of FDD workshops in Wellington / New Zealand. I enjoyed.

Many thanks,
Darya

Somebody makes existing FDD use to carry through maintenance of softwares already and not in new projects?

The main purpose of FDDI is to enable the exchange of FDD project related information between diverse software systems and components.

FDDI (f ĭ dˈē) is pronounced fiddy (as for the word giddy but replacing the g with an f).

I'd like to revisit (and hopefully reassert) the FDD view on version control, and configuration management.

In FDD we use the term "promote to build" as the final step in BBF, which directly refers to the action of promoting (re-labeling) a file in the CM system. Modern CM/VC systems such as Perforce and Microsoft Visual Studio Team System do not include the capability to do promotion groups and labeling. In a Perforce whitepaper, they explain that promotion groups lead to "bushy trees" which they describe as an anti-pattern.

I've seen some teams doing FDD advocate the notion that each Feature Team makes a branch for each Chief Programmer Work Package. This seems wrong to me. The claim is that modern tools make merging much easier than it was in earlier years and that the transaction cost of a branch and merge is almost zero.