It depends a bit on your target audience, but my experience ( more in small/medium scale development than very large scale work ) is that detailed design documents are arduous and boring to write, rarely read and tend to end up out of date by the time a project is delivered.
This does not mean that they are worthless - if you are delivering something for someone, there needs to be an authoritative and agreed statement of what will be delivered sufficiently detailed that everyone can point to it in case anyone is dissatisfied with the deal and say "this is what we promised" and evaluate it against what was delivered.
If I were setting up a company to build a product, however, I wouldn't worry so much about a detailed specification. I would want to document what we were going to do, but I wouldn't want to go into too much depth regarding how - that is the part that is most likely to change and leave the documents out of date and useless or even inaccurate enough to be actually obstructive. I would prefer to document the "how" stuff in code using whatever documentation format the language or IDE supports best, so that as the code changes it is easier to update the documentation at the same time. It won't stop it going out of date, but it will reduce it somewhat.
Ideally you would want a design document that could double as your manual when your code is complete, but I don't know of anyone who has managed that successfully.