www.hitechsaloon.com

If you think that writing great software means writing tests, setting up continuous integration, following coding standards as well best practices then please read on.

If, however, you think that writing documentation is not necessary then please get a new career because what you are writing is not great software, it's a well polished piece of crap. It may look like a Renaissance sculpture but as you get closer you will soon realize that it stinks like ****.
One of the talks at the PHP UK Conference 2010 was about writing good software documentation, from functional through to technical documentation.
The speaker highlights the importance of writing PHPDoc blocks, detailed summaries of the changes you commit to your version control application (ideally with the ID of the bug-tracking ticket it relates to), blog posts about some complex solutions or workaround, FAQs and so on.
Even before attending the talk I knew of the importance of software documentation. Recently I've heard that you should not need to write comments because the code should be crystal-clear, i.e. by just looking at the method signature you should be able to understand exactly what a method does. This is certainly true about methods that were written with these principles in mind - what about the old ones? Why should a developer not write comments for those? Tools like phpDocumentor can make a difference.
One argument against in-code documentation is that it gets quickly outdated. I believe it is a developer's responsibility to keep the documentation up-to-date, it doesn't matter if it takes time. Just like a developer shouldn't cut corners when writing code and tests he or she should give as much importance to documentation because not all developers are the same: what is clear to a developer may not be crystal-clear to another one.