The main purpose of documentation is to be. And the most common is not to have one.

Accordingly, everyone wants one, but there is no one in the company who can do it properly.

The above contradiction has been a constant source of tension for me throughout my twenty years as an entrepreneur and programmer, and this whole issue has always The sword of Damocles hanging over me. 

By the time I was an employee, the timid request "it would be nice if you wrote a doxie" kept turning into a firm request and finally into a desperate wait. After all, every manager has his or her rubber stamps, what else to give up but documentation, right? No.

My experience is that all bids should include that you write documentation. Then no one reads it. After all, you can write anything you want, I've never had anyone tell me they didn't have one (maybe because they did) or didn't like it. Everyone hates reading, interpreting text. Just keep the code running and the reporting good. 

And then there is the fact that everything changes and evolves. Who is going to translate the changes in the doctrine? If anything was done after the first development, just to pay for it, it will probably stay that way forever. Like a website that hasn't been updated in three years. I would rather delete the whole thing instead of burning themselves with it.

Finally, what should the documentation look like? Has anyone, anywhere, ever been given a sample that, here's the expectation, this is what it should look like? Or have you ever seen one that you liked? And there's the code anyway, read it, decipher it.