Documentation is good in general, but I think this approach is flawed:
These are relatively informal documents that the primary author or authors of a software system or application create before they embark on the coding project.
"Before they embark on the coding project". The design is the coding project, it's all the same thing. The idea that you can work out the design on paper before committing any code is just wrong. (The design doc approach in fact admits that you need to write some code up front, but tries to strictly compartmentalise it as "prototypes that show the implementability of the design".)
A big feature of the up-front design doc is that it gives people license to nitpick, AKA review, before any serious coding starts. In my experience this usually means the doc gets extended by more and more caveats and discussions of pointless alternatives, and can become less of a "design doc" and more of a "please just let me start building this thing" doc.
In cases where there are significant architectural problems that require a change in direction, they're better solved by talking to and collaborating with the right people in advance, rather than crafting a detailed design doc only to have it shot down.
If you stick closer to the "relatively informal document" idea, and maintain the doc as you go, that can actually be useful, as it helps you produce useful documentation as well as a working system. But that's less "design doc" and more "write documentation as part of a continuous, collaborative process".
If a project is sufficiently large and well thought out then architectural changes can be incorporated without too much extra work relative to the whole.
These are relatively informal documents that the primary author or authors of a software system or application create before they embark on the coding project.
"Before they embark on the coding project". The design is the coding project, it's all the same thing. The idea that you can work out the design on paper before committing any code is just wrong. (The design doc approach in fact admits that you need to write some code up front, but tries to strictly compartmentalise it as "prototypes that show the implementability of the design".)
A big feature of the up-front design doc is that it gives people license to nitpick, AKA review, before any serious coding starts. In my experience this usually means the doc gets extended by more and more caveats and discussions of pointless alternatives, and can become less of a "design doc" and more of a "please just let me start building this thing" doc.
In cases where there are significant architectural problems that require a change in direction, they're better solved by talking to and collaborating with the right people in advance, rather than crafting a detailed design doc only to have it shot down.
If you stick closer to the "relatively informal document" idea, and maintain the doc as you go, that can actually be useful, as it helps you produce useful documentation as well as a working system. But that's less "design doc" and more "write documentation as part of a continuous, collaborative process".