Developers hate to document their code, you say? Ask one at random what happens when they get assigned a piece of code that someone else wrote, or even a piece of code they wrote themselves six months ago.

Go ahead. I'll be waiting right here.

Done? I hope they didn't use TOO much bad language.

The most famous (well, most widely available) is probably the Java JavaDoc system.

The developer follows some standard conventions for writing in their code, and then they can generate an HTML file that explains everything in their code. Working together, you can format some very nice documentation for an API guide or the like. See http://java.sun.com/ for examples.

But what if you're not working in a Java shop?

Doxygen offers a few more choices in languages: to quote from the Web site (http://www.stack.nl/~dimitri/doxygen/)

"C++, C, Java, Objective-C, Python, IDL (Corba and Microsoft flavors) and to some extent PHP, C#, and D."

In addition to the languages supported, Doxygen also offers an intriguing range of output formats, HTML, LaTex, Man pages, and RTF (compatible with Word 97 era RTF, according to the author).

VB.NET? I confess to not being as familiar with tools in this area, but a simple Google search turns up this site (among many others):http://authors.aspalliance.com/ Some of the sample outputs look quite useful.

The point is, with time and budget constraints, it makes sense to automate as much of the documentation production as you can. This has always been one of my professional interests during my technical writing career, and it has always paid off in the end.

The end? Yes, because (like everything) there is usually initial managerial resistance to any project that doesn't have the magic words "3.2 million dollars in revenue within the first year" in the executive summary.

So you have to spin this stuff from the point of view of expense reduction, which is almost as good as making more sales in most manager handbooks.

Do some rough estimations of time spent by both you in writing documentation and by the developer in working with and maintaining poorly documented or undocumented source code.

Contrast it to the benefits and savings obtainable if you get to implement some sort of documentation generation system in your company.

As a writer, do you enjoy chasing after people for knowledge? I know I never have.

Why not make them put knowledge into their output as part of their job?

Then you can both go home on time most evenings.