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?
I agree - I rely heavily on documentation to trace the name trail. If I can't find the person listed (left the company), I find people associated with that person in other documents. Documentation also seems to run in cycles - not sure if you've seen that as well. Initial burst. Ages and falls apart. New initiative to clean it all up and establish domain teams! Team members pulled to other priorities. Documentation starts to age again. New corporate system, documentation lost or moved around and dispersed. New initiative!
ReplyDelete