The trend has been in that direction since the dotcom bust, when a number of (formerly) highly paid developers found a comfortable job writing help files more appealing than unemployment or stocking the shelves at Wal-Mart.
While it is easy for technical writers to convince themselves of the value of what they do, the simple truth is that many users lack the linguistic and cognitive sophistication to distinguish between "good" writing and "mediocre" writing. Similarly, it is easy for technical writers to believe they are documenting the software, when in fact they are only documenting the interface. The trend in development is to make the interface more intuitive, hence easier to use; if the interface requires extensive documentation about how to use it, it is a failure of design, not of documentation. That follows the way the overwhelming majority of users actually interact with software--they start it up, click a few buttons, and generally try to figure out how it works. For a well-designed user interface, that should be enough to get started. The movement toward Extreme Programming and Agile Development is a case in point; documentation is considered a waste of valuable developer time, and only needs to be slapped together in minimalist form at the last minute. That is at odds with the "TW perspective" of involvement during the entire development process (which is ONLY appropriate for Waterfall, because everything else changes). Because there is already a dichotomy between the GUI developers and the "real" programmers, it is a small step to realize that the best people to provide the minimalist documentation necessary to use the interface are the developers of that interface. If the interface requires more than minimalist documentation, the core problem is the failure of the design, not a lack of technical writers. Minimalist documentation should be based on the remarks (in the code) of the developers, not a secondary understanding of a technical writer acting as a third party. If a technical writer wants to document software, he or she should learn to program competently. Similarly, a GUI developer who wants to stay employed should learn the basic skill set needed to convert remarks in the code to help files. The dichotomy between developer and writer is artificial, and not particularly useful. Developers don't need a Master's in English to write competent documentation, and technical writers don't need a BS in Computer Science to develop a competent interface. When the employers realize that, technical writing--as far as software documentation is concerned--is liable to become the 2008 equivalent of buggy whip manufacturing when automobiles chased the horse-drawn buggies off the road. The argument that documentation would erode developer time better spent elsewhere is spurious; the process is becoming, 1) release the software with a minimalist set of docs, then, 2) build an online help file based on the highest volume of calls to support. The concept may be uncomfortable for technical writers, but it is a concept used widely in business; "the squeaky wheel gets the grease." tekwrytr http://www.tekwrytrs.com/Specializing in the Design, Development, and Production of:Technical Documentation - Online Content - Enterprise Websites _________________________________________________________________ Windows Live Hotmail and Microsoft Office Outlook ? together at last. ?Get it now. http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL100626971033
