My current work lives here: Oddball Empire - Rock on.
Most development projects spend effort in creating specifications: functional, technical, detailed, global. Putting the designs in writing takes a lot of work, and it will not be used in the end result; specifications are supporting artifacts.
So, the question if specifications are worth the effort is legit. Jeff Sutherland quotes some research in this area in his article Future of Scrum: Support for Parallel Pipelining of Sprints in Complex Projects
Two metrics are mentioned: the productivity of the development group and the defect rate. In a tongue-and-cheek definition, the productivity is the amount of features / lines-of-code build in a given time frame, and the defect rate is the number of bugs found per amount of features / lines-of-code.
The article of Sutherland mentions that there is a strong relationship between the completeness of the formal specification and the productivity. The better the sense of the developers is of the desired end product from a functional perspective, the faster the program.
The other way round with completeness of design specifications and the defect rate. The relationship between them is found very weak. So, writing more detailed designs before programming doesnt reduce the amount of bugs.
Leaving us with the question what can we do about defect rate and productivity. In the mentioned article the following options are provided for lowing the defect rate: early prototypes, design reviews and testing at code check in. Increased productivity is reached by early prototyping and daily builds of the software.