
Image by JanneM via Flickr
One of the challenges I've been facing as a tech writer is the growing preference for this kind of quick-and-dirty approach to documentation. I saw a lot of it at Sun, and the impression I got then was that it was part of the current infatuation with wikis and other crowdsourcing technologies. But I'm beginning it see that it also has a lot to do with the rise of Agile software engineering. If the software development cycle can be streamlined, deformalized, and drastically shortened, why can't you do the same with the documentation cycle?
Well, there are reasons, but I'm not going to get into it now. Suffice to say that I believe that documentation needs to be more structured, not less. However, this is not an issue you can deal with through argument; the issues are just not understandable to most engineers. (Or a lot of tech writers, for that matter.) You have to demonstrate how structured methods make for better docs. And you have to do it in such a way that your formalized doc process fits in with the deformalized software development process.
It's a pretty problem. I suspect the answer might involve using both formal (XML, specialized authoring software, etc.) and informal content management tools. More on that later.
Zemanta has suggested a lot of related articles, based on what I just wrote. I'm going to insert links to some of the more interesting ones, without too much regard to their being ontopic.


Leave a comment