Joel's background is Micro$oft and Yale. He has a traditional approach to software engineering. MS is not a hub of innovation and never has been:
http://online.wsj.com/public/article/SB116490323676636989-Hn...
Here's Dave Winer in that WSJ article:
"Microsoft isn't an innovator, and never was. They are always playing catch-up, by design. That's their M.O. They describe their development approach as "chasing tail lights." They aren't interested in markets until they're worth billions, so they let others develop the markets, and have been content to catch-up. This worked well for them in the 80s and through the mid-90s, when they were a more nimble company with stock options that were attractive to bright young people, when Bill G had something to prove, and was current on the latest technology. Maybe it still does work (obviously I have doubts), but it sure isn't innovation, in any usual sense of the word."
Scoble from the same article:
"I agree that they don't do big things that are innovative, and this leads to disconnects as to what innovation is." [Typical ex-microsoftie trying to change the meaning of the word innovation]
Google's dev mantra is "release early, release often". There's an important business reason they do this - to get apps out in front of the customer very early to find out if there's any interest in them at all. Most of the apps are Beta and many of them have horrible bugs. If that makes them gunslingers, then I'll take my chances as a gunslinger.
The problem I have with your last paragraph: "but spending a few hours planning out exactly what the thing will _do_ (just the 'what'; not even the 'how') usually teases out problems that you'd only find a few weeks into winging it" is the following:
Sometimes you don't know what's possible. If you sit down and write an english description for a few hours, you're only drawing on your existing knowledge. I'd rather my developers sit down and write code for 3 hours to see if somethings possible. That way they may come up with a completely original idea.
You're focusing on finding problems with software rather than creating something new and useful and potentially ground-breaking. There's a time for finding problems - it's called QA and it happens after product already exists.
Writing software isn't hard. For a good developer it's just as easy as writing a spec. JUST DO IT!
Mark.