In the world of corporate software, there are two facts about documentation. It exists and very few people read it. You see it in many companies, particularly big ones. A project starts out with gusto -- a thirty or forty page "whitepaper" or "roadmap" outlining the particulars of the business or technical concept du jour that is going to either set, or change, the direction of the organization for years to come. As implementation gets underway, reality takes over and the brilliantly written documentation collects dust while the project goes on to become a wild success, utter failure, or most commonly join the ranks of the countless corporate software projects that bumble along doing an adequate job of what they originally set out to do. Eventually some or all of the original developers on the team move up or out and new blood takes over and gets up to speed on the details of the project by reading...code. The documentation is however often good for something -- finding the name of a developer who can help you fix bugs.
Title: Why do you think I hate documentation so much? Snarky: Why are you fixing bugs in that code? Weren't you off that project like three years ago?