One important distinction that a lot of agile people make is more around writing down the specs; as the PM you still do work up front to think about what to do, make mockups, do your homework, etc., but when it comes time to communicate to developers it's done as stories (much less detailed than specs) and with in-person communication for clarification (or, under less ideal circumstances, over the phone or e-mail or chat). The process of getting to the story in the first place ought to involve plenty of back-and-forth, design vetting, and mockups, but once you get there you don't build something based on a spec of any kind.
The theory there is that written documents will always be out of date, incomplete, stale, and open to multiple interpretations, so we might as well just accept that the face-to-face communication is infinitely higher bandwidth and will have to happen anyway and not waste the time trying to write it all down up front.
So if the PM needs to spec for their own edification, that's fine: do whatever works for you. But I, as the developer, will trust the PM themselves as the source of truth as to what the feature should do, and it's the PM's job to know what they want well enough to answer my questions real-time as I'm building.
As a developer on the receiving end of "stories" I find that a few sentences on an index card are, in most cases, woefully inadequate at describing the desired functionality. So what happens is you end up going back and forth to the PM with your questions, which is inefficient, OR you make assumptions to fill in the gaps, which sometimes works out well and sometimes does not.
On the other hand I've also had the unhappy experience of wading through dense, arcane specification documents written in stilted language ("the system shall...." ad nauseum) that are ultimately not much better.
In the end I think what this illustrates is that writing a good, concise, clear, complete functional specification is not easy. It requires a talented PM and no formulaic approach, whether it is agile or anything else, can get around that.
The solution to that in our case, at least, is that the stories aren't just handed down with no explanation from a product manager. Instead, there's a team-wide "estimation session" every week where everyone (dev, PM, and QA) attends and we take the higher-level feature ideas, including any initial supporting documents (market research, mockups, desired use cases) and break them out into smaller, estimated stories. At that point everyone has a chance to ask for more detail and clarify any concerns they have, point out potential difficulties, suggest alternatives, etc. So stories are only scheduled for work once they've passed that initial stage where everyone was involved; if things are too vague, or technically impossible, or otherwise unready for development, they don't make it out of the estimation session.
It definitely still requires good product managers, but again the idea is that no matter how good the spec or whatever is you'll still always have questions, and it's better to just build that fact into the process and get people used to asking questions rather than having people make assumptions. And the best way I've seen to make sure that the PM has the answer to those questions is the estimation session, since if the PM doesn't know what they want well enough to answer the questions quickly as you develop, you'll find that out in the estimation session before anyone is tasked with working on the feature. That at least largely avoids the situation where a developer starts working on something and finds out the PM really didn't have a great idea of what they wanted after all, or that it's technically infeasible, which (in my experience) is just a really bad situation to be in.
The story approach still presents endless ways to screw up, but it's far better than any other approach we've tried over the last 7 or so years.
"In the end I think what this illustrates is that writing a good, concise, clear, complete functional specification is not easy."
A complete, unambiguous, and functional specification is called a program. May or may not be "good".
The going back and forth that you describe as inefficient is where the collaborative creative act occurs, where you work with the person that needs a custom system to define what you can build for them.
Not only writing the code first, but write with the idea that because they're "agile", their code is somehow easier to change 15 times as the complete understanding of the functionality emerges.
It would have been helpful for me to have read that context rather than the weird insult. That only seems to escalate the confusion caused by his title.
When the "functional spec" is the exact same thing as the html code, it is no longer recognized as a functional spec.
The functional spec usually comes before the html code.
Sure, Fried treats his html code as a functional spec, but others who work differently would not be able to find what they are used to calling a functional spec.
He's opposed to BAD functional specs, which is fine, but too many people read his title and decide it's OK to skip to writing the code first.