Fred Brooks wrote a classic paper over 20 years ago called “No Silver Bullet”. It's amazing over the years since, how many people have claimed to have found the silver bullet.
FDD is no silver bullet. It's a collection of practices from my 25 years experience and some of the resources I've come in contact with in that time – be they books, people, software, etc. In fact, I think of FDD as an optimal collection (solution) of sub-optimal parts. Coombs law states that the optimal solution always comprises sub-optimal parts and it's from that perspective that I built and thus see FDD.
I also want to point out that I'm not religious when it comes to methods, etc. That is to say, I'm not religious about you having to use FDD and only FDD. If you've already got something that works that's great! Stick with it. If it's reliable, then please consider writing about it!
What I am religious about is results. That is, the reliable delivery of working software in a timely manner. Peter Coad expressed this as frequent, tangible, working results. The Agile movement expresses this in one of its four value statements that begins “We value working code more than...”
What I am also religious about is changing the nature of I.T. and its relationship with the business. It's amazing how much that relationship can be affected just by frequent, tangible results. Vanessa Beer, of DMR Australia, gave an excellent presentation at a software conference in 2003/2005. She talked about a project that was in trouble using a very traditional, high ceremony, heavyweight methodology and the success she had when a switch was made to an Agile approach (that happened to be a combination of FDD's startup processes and Jim Highsmith's Adaptive SD). One of the things she emphasised was how the relationship between her team and the client changed dramatically due to the delivery of frequent, tangible results. There was more enthusiasm, understanding, respect, trust and flexibility (or should I say, agility).
She told a story of a meeting where the client asked for some new function, and her team responded by saying something like “Hmmm, that might be pretty hard to do. I guess we could look at x and y and then...” and before the sentence finished the client team simply responded with “oh, ok, well how about we try and achieve that this way instead.” I'm paraphrasing here, but the point was that the client asked for something, saw that it might be difficult and immediately thought of an alternative that might simplify things; a compromise. Vanessa made the point brilliantly when she said this was the affect that frequent, tangible results had on that relationship and that project.
