I just read Paul's article about processes. And while I begin to realize that I'm already meta-blogging I totally agree with Paul that processes are nothing else than yet another tool.
So let's talk about tools. Imagine little Bob the builder. Bob wants to build a nice doghouse for his beloved puppy Rocky. Bob realizes that the first thing he needs for his little doghouse is some wood. But Bob is very inexperienced with wood acquisition. So he visits a nearby hardware store.
When he arrives at the store, Bob is impressed by the amount of tools available. And as far as little Bob understands the business (tree and force gives wood) everything that's sharp enough will do the job. So he starts to stroll through the store.
After a moment he is greeted by a smiling shop assistant in a green overall. "Hey there, shelves are ten percent off today". "But I need triangular shelves", says little Bob. "Then you'll need to cut them". The clerk gives him the direction of the tools department.
In the tools department Bob meets an old man sitting on a bench. Bob inquires: "Hello sir, do you know which tool I should use to cut shelves?" "Dynamite!", the old man replies, "we always used dynamite to cut into the stone back when we built the railroad tunnels. So dynamite should do the job for your little shelve-cutting business, eh?".
Some years afterwards Bob's experiments with explosives will make him a school hero. Today, he even knows how to use a chain saw.
The point is that even when there may be multiple processes to choose from, there are obviously processes that are not really helpful. And should we use Waterfall/BDUF just because engineers claim that it works for building electric circuit boards? I don't think so.
Note for the record: I don't consider Joel's Aardvark Spec to be BDUF. It's requirements analysis. If Joel can't imagine people designing a system up front for half a year, perhaps he's more agile than he knows...