I think both Joel and Paul are right. Most of the code Paul talks about writing took a "few hours" to write, what Joel is talking about are massive projects that take weeks of effort only to find out that they solve the wrong problem.

So, rapid prototyping: good, unspecced large projects: bad.

The only thing good about a large project that is specced that still goes wrong is that the developers can feel good about it not being entirely their fault.

In short: do whichever lets you explore the important effects faster. Sometimes a spec will make you faster and sometimes it isn't worth it. You can generalize from these two examples, but the more data points you have the better you will be able to tell when a spec will probably be helpful and when it won't.