I think this question is the crux of the agile vs. waterfall lifecycle question.
If you're doing agile, a basic premise is that the code coupled with close developer interaction is better and faster than the detailed specification. The team prioritizes releasing new features and high quality over other things - like formal communication mechanisms such as detailed design specs. But there's a trade here - you have to have communication channels between team members that let them ask about nuances and detailed design intention when they need it.
If you're doing waterfall, you're working under the assumption that the work of filling in the code under the detailed design and then testing it is significant. And you want to give stakeholders early insight into how this work will proceed and what it will be like when it's done. That may be vetting the design with the customer to make sure you've scoped out features that make sense. It may also be to vet it with experts in other arenas - such as safety reviews, security reviews, and reviews by team members that have to integrate with your code. The assumption is that these reviews will save time in the long run because they will save you from investigating a large amount of time in developing the wrong thing.
Lately, I've seen some really great fusion between detailed designs and code comment tools - JavaDoc for example. Since most detailed designs are foot prints of the code and short explanations of what it will do - this is more or less the same thing you'd expect as code comments. So having a tool that will transform code comments into a detailed design spec is great - a much better way to keep it up to date than doing it by hand.
I believe that inaccurate assessment of how detailed design should be for the project, is a major factor in cost growth. The worst part is that you're damned if you do and damned if you don't:
- If your design is too detailed for the size of the team, the complexity of the work, and the requirements of the gates you must get through (security reviews, safety reviews, etc.), then you've wasted precious time and money on an artifact you will never use.
- If your design is not detailed enough, you will waste money as team members make incorrect assumptions that lead to integration issues, and you risk heavy rework when a final security or safety audit uncovers issues that could have been fixed early and cheaply if they had been clear aspects of the design prior to implementation.
I don't feel it's a black and white case - there can be plenty of times where some components are "good enough" if designed at a high level, while others need rigorous detailed work. And changing team or project environments can dictate new design needs as a project evolves.