I really don’t think this has ever really been an age-old discussion. Business in the past had never really done much in the line of documentation (and for some businesses these days, it’s starting to show). Employees in the past knew specifically how to perform their tasks because they had become so engrained in the every day routine that it wasn’t necessary to document. I guess they also either had an underling that shadowed their every step so that they could step in, or business just didn’t get done then until the person responsible for that process got back into work.
Today, things are much different. Business moves so rapidly (especially in IT) that it’s impossible to rely on specifically one person to be the only person to get a job done. Furthermore, turnover occurs at a much higher rate, and the typical period that people are around for after they turn in their resignation is a mere 2 weeks (sometimes less than that, depending on the company).
So, documentation has become increasingly important from an operational perspective, as well as a business continuity perspective. Should an employee that had previously setup a particular service get “hit by a bus”, as the situation is called at Texas A&M, can business continue as normal with someone else filling his shoes? With the advent of Wikis (we use Confluence at the College of Architecture), it’s easy to author documentation, and a lot of it.
However, I see a potential problem - the number of new services we are standing up and web sites we are putting together is increasing and occurring faster than ever before. But in order to keep the documentation up-to-date, I find myself spending just as much time documenting my steps and changes as it took me to stand up the new service or web site. At what point should the documentation stop? How much information do I really need to convey through my documentation, and how much reasonable business time should I spend documenting my work?