It's more complicated than that, and it's hard to answer here.

Basically -- if you're building something big and complicated and you should know exactly how it's going to work, a big written spec really helps.

If you're building something brand new, a startup, or a crazy idea that you need to test quickly and iterate, you should use lots of little specs. It's ok if the specs aren't so fancy... a detailed map of what goes on the screen and what everything does is probably fine. It's ideal if you write lots of small specs for each small feature ("user story") right before you implement them and roll them out.

I just don't like the idea of typing code when you haven't thought through what it's supposed to do (in a disciplined way). Doing specs in small quick chunks, then writing code, is probably the best approach for lean/agile startup teams that don't yet have customer/product fit.

Let's be honest. Google wants us to use their services because the better they understand us, the better they can advertise to us. That's the profit model at Google. I don't begrudge them for it either. You've got to turn a profit if you want to keep the lights on.

I don't mean any offense, but the "Don't be evil" mantra is growing a bit tired. Evil is a strong word, and "not being evil" is a pretty low bar, IMO.