Having just completed my first (and last, for a while) shipping SwiftUI app, I <i>very much</i> think that documentation has been treated in shabby fashion, in the modern tech scene. I sorely miss the work done by all those great tech writers that Apple fired. Their engineers are <i>terrible</i> documenters.<p>I'm always a bit leery of "dogmatic" approaches, though, because they tend to develop a "priesthood," that refuses to bend; even when reality demands it.<p>In my experience, the initial developers of the dogma use it to marvelous effect, but subsequent "priests" screw the pooch; sometimes, turning the approach into a curse. Many good ideas have been destroyed by too-rigid applications (What is "Agile"?).<p>I see any documentation as having basically two faces: The maintainer, and the user. Each, has drastically different needs, and should probably be addressed by completely different teams.<p>As has been alluded to, in other comments, you can have issues with multiple instances of documentation, falling out of sync (the curse of most wiki-style documentation), but results matter. If the multiple instances can be effectively synced, then the documentation is effective and useful to its consumers. If no one reads the perfectly formatted and synced documentation, it's worthless.<p>On SNL, Phil Hartman<i>[n]</i> used to play The Anal-Retentive Chef. In one skit, he spent so much time prepping, that he couldn't actually demonstrate the recipe.<p>I see a lot of that, in tech. Toolchains and libraries that are absolutely perfect, but are unusable, in practice.<p>Documentation is an amalgam of many disciplines; human nature/psychology, graphic design, information architecture, technical infrastructure, publishing and distribution, etc.<p>I really think it's often treated as an afterthought, in most projects, and I believe that it should be a first-class consideration, at the Requirements stage, onwards.