Ingo Rammer has an interesting piece on quality of documentation.
True. Because most developers don't like to write it as they know (or at least believe) that they write it for the sole purpose of fulfilling The Process. The other developers don't like to read it because it heavily lacks quality as it has been written only to fulfill The Process. So when they have to write another piece of documentation, they know (or at least believe) that they write it for the sole purpose of fulfilling The Process.
This couldn't be more true. For the past few years, I've worked on an internal framework for application development. For a product of this nature, documentation was obviously critical to its success. We automated the API doc generation, and had a pretty good system for keeping the other things reasonably up-to-date (although when I was the sole developer, there was only so much work I could do and unfortunately it was the documentation that suffered). An automated system is key - it allowed us to deliver quality documentation with minimal effort. And the quality of documentation really helped to set this project apart - it was very successful and generally perceived as a highly polished product.
The end user may not notice the lack of quality documentation up-front, but they will when you need it. Let's say your project has a particular feature, but the user can't figure out how to use it on their own. If the documentation doesn't help them, you might as well have omitted that feature in the first place - because as far as they're concerned, it doesn't exist.
After all - a movie can have a great leading actor (the application), but with a poor supporting cast (documentation, etc), you probably aren't going to watch it.