maybe i'm getting trolled here :) but i don't see how joel's background makes his points less relevant: - it's easier to fix problems on sketches/paper than in code weeks later - specs cut down on amount of communication needed -- especially with outside stakeholders - and help with schedule estimates, etc.

sure, in your typical web 2.0 app, many things are easy to re-work, but others (e.g. end-to-end unicode support/other i18n issues, scaling, schema design, etc.) are better baked in from the beginning (just ask friendster.) or at least be cognizant of the tradeoffs you're making and budget time to throw away your prototype.

also, google and ms have pretty rigorous software engineering processes and tools (hell, they hired GvR just to write a code review tool.) sure, in the early days it was probably looser. but not zero structure whatsoever -- the total free-for-all that "just do it" implies -- hell, even "release early and often" is a kind of software engineering discipline.

there are benefits to cutting corners (i.e. the zero planning implied by "just do it") like getting to market faster for certain kinds of startups (early market feedback, etc.) but these come at a cost later on! i like dharmesh shah's idea of 'technology debt':

http://onstartups.com/home/tabid/3339/bid/165/Development-Sh...

and your assertion that QA is something that happens only after a product already exists is equally misguided -- you can save a lot of time overall by thinking early about how to structure and instrument your code to make it easy to test.

if your response is 'well of COURSE you'd think about all these things up front', then that's not really 'just do it', is it :)