CoadLetter articles related to FDD

steve palmer's picture

As editor, and more often than not author, of the online newsletter, The Coad Letter ( between June 2000 and February 2002 I wrote a number of issues about FDD. Most of these found their way into my book, A Practical Guide to Feature-Driven Development in some form or another and some were draft versions of some of the chapters in the book.

Coad Letter #86: Integrating Best Practices - (from chapter 3)
"Like all good software development processes, Feature Driven Development is built around a core set of ?best practices?. The chosen practices are not new but this particular blend of the ingredients is new. Each practice compliments and reinforces the others. The result is a whole greater than the sum of its parts; there is no single practice that underpins the whole process. A team could choose to implement just one or two of the practices, but would not get the full benefit that occurs by using the whole FDD process. ..."
full article...

Coad Letter# 85: Projects and People - (from chapter 2)
"... The reality of life is that we are members of development teams of mixed ability and experience from varying walks of life. We work in less than ideal environments and often have little power to change them. So we have to make the best of what we have. Feature Driven Development defines six key project roles and implicitly suggests a number of supporting and additional roles. The FDD roles when combined with the FDD processes organise a project so that individual strengths are fully utilise and support is available in areas of weakness. ..."
full article...

Coad Letter# 78: Developer Ailments - (not in the book but maybe it should have been?)
"The following ailments seem to cross cultural and geographic boundaries and afflict developers everywhere. As with all ailments, they can be recognized by their symptoms and have established cures or recommended treatments. These cures and treatments are often embedded within a process such as Feature-Driven Development. As with other sorts of ailment, developer ailments may also have dire consequences if left untreated. ..."
full article...

Coad Letter# 72: Chief Programmer Work Folders - (expanded in chapter 6)
" ... We do not want to force developers to spend significant time creating unnecessarily large volumes of design documentation and project plans; many of us working on internet time can no longer afford the luxury of the time required and few developers relish the task. The resulting documents are also hard to maintain, seldom fully read and understood, and they are frequently lost over time. ..."
full article...

Coad Letter# 70: Feature-Driven Development and eXtreme Programming (some bits scattered throughout the book)
"... Both FDD and XP are designed to enable teams to deliver results quicker without compromising quality. Both processes are highly iterative and results oriented. They are both people focused instead of document focused (no more thousand page specifications to write). Both dismantle the traditional separation of domain and business experts/analysts from designers and implementers; analysts are dragged out of their abstractions and put in the same room as developers and users. These new processes, together with new tools and techniques are enabling and encouraging analysis, design, code, test and deployment to be done concurrently. So where do FDD and XP differ? ..."
full article...

The full archives of Coad Letter issues are at

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

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
steve palmer's picture

Coad Letters moveed

The CoadLetter site is no more. Some of the Coadletters have been reproduced on the borland developer network. Most of the issues I wrote are now on my website at

Never attribute to malice what can adequately be ascribed to incompetence