Getting Real? Why is Spec a Dirty Word?

Over the last few months, I’ve spent a bit of time researching various development methodologies and have seen a lot of different approaches when it comes to the software development life cycle. After attending this year’s SDExpo, I can say that I had a lot of exposure to some agile approaches and am eager to start incorporating some of these lightweight methodologies. I also happened to pickup (download) the book “Getting Real” from 37 Signals, and have to say it’s a great book and offers some great advice.
One thing I don’t quite get is the idea that you should *never* write a functional spec.
From the 37 Signals blog post (Feb 2005):

Step 1: Don’t write a functional specifications document
Don’t write a functional specifications document. Why? Well, there’s nothing functional about a functional specifications document.
Functional specifications documents lead to an illusion of agreement. A bunch of people agreeing on paragraphs of text is not real agreement. Everyone is reading the same thing, but they’re often thinking something different. This inevitably comes out in the future when it’s too late. “Wait, that’s not what I had in mind…” “Huh? That’s not how we described it.” “Yes it was and we all agreed on it — you even signed off on it.” You know the drill.
Functional specifications document are “yes documents.” They’re political. They’re all about getting to “yes” and we think the goal up front should be getting to “no.” Functional specs lead to scope creep from the very start. There’s very little cost in saying “yeah, ok, let’s add that” to a Word document.

While I do agree that the point is to build functional software, not perfect specs. There are a great number of situations where the type of product you are building, the size of the team, or the type of organization demands a more structured (and documented) approach to building software. One particular comment on this post caught my eye, and I have to say it summarizes my feeling on this whole debate… to spec, or not to spec? That is the question.
Comment from One of several steves:

I’m highly suspicious of absolutist statements when it comes to software design and development. Always write a functional spec. Never write a functional spec. Both are equally dogmatic and equally full of pitfalls.
A “story” is never going to give developers enough to go on if you’re building a web-based app that has to interface with a multitude of exterior systems, legacy databases, etc. Interface design isn’t going to help them much, either. Good database diagrams would. Good technical requirements document would. But the “story” and the wireframes and comps aren’t going to help them much. And, like it or not, sometimes we do have to make the interface accomodate what’s going on in the backend, or else spend a ridiculous amount of money to get legacy technology to behave the ideal way, instead of a reasonable amount of money to get it behave in an acceptable way.
The key takeway is to have the right criteria drive the design and development, and use whatever tools needed to best communicate that. Call them whatever works (as Geoff correctly points out, a BRD by any other name still smells as sweet).
Flexibility and using the available tools to get the job done effectively is paramount. Dogmatic approaches get in the way. “Don’t write a functional specifications document” is frankly just as stupid as “Always write a functional spec.” Sometimes it makes sense not to; sometimes it doesn’t. Dogmatic rules don’t encourage that kind of flexibility.