As with all documentation.. it will be out of date after a while.
I agree that documentation is nice even with the maintenance burden, but most would be surprised at just how much outdated code is out there. If many struggle to keep even their code up to date and not full of CVEs, what makes you think that they will also be able to have up to date documentation?
> Imagine you throw away your codebase each time you deploy your executable.
Honestly, I'm tempted to do this sometimes.
For example, consider splitting up monoliths and replacing them with many smaller services. If there is a problem with updating one part of the system, it can be left to slowly rot in the backlog, until it becomes a priority, at the same time without blocking doing the things that matter in the other parts of the system. Code should be not just easy to read and change, but also throw away. Not only that, but some more modern frameworks are just less painful to work with than the old ones (e.g. no more XML configuration hell) and you also often realize that you can do things better than the first implementation.
In a sense, one can say the same about docs: make it a Markdown file when you need to write something down, that can be easily changed/replaced and included with a merge/pull request, as opposed to some 50 page .docx file with no version control in some random network drive subdirectory.
We had architecture sketches (informal, but highly taylored to show the gist of a system) that stayed valid and were used from after the first prototype to well after release, over a course of more than five years. It was a system of six embedded processors, 2 FPGAs, 5 different bus technologies, (luckily only) two different endianesses and coding and debugging would have gone horribly wrong without that overview sketch of just enough detail. There are cars in your town that drive around with it for a dozen of years now.
That's just rude so I'm not going to bother replying
This argument gets thrown up by someone nearly every time documentation gets mentioned.
1. Does it matter if not entirely accurate with the as-is? It showed the previous state or intention, that is typically very useful and a lit better than nothing.
2. Your unit test are out of date when your change code yet that typically gets updated, or new tests added, and is typically more work than updating the docs.
3. If what you document is so wildly different to the solution, you're probably documenting too much detail (this is where most junior devs go wrong), if it's that your arch has actually radically changed it sounds like your documenting too early, do you do spikes etc to figure out your arch before you commit to it?
Yes. I've lost more of my life to out of date misleading documentation than to documentation that didn't exist at all.