[FM Discuss] why documentation lags software

Bill McConnaughey mcconnau at biochem.wustl.edu
Mon Jul 6 11:13:01 PDT 2009


Andy Oram makes a lot of good points regarding the fun, rewards and 
support that surround programming vs. the drudgery of documenting it. I 
have another perspective, as a creator of software for use in my 
biophysics research lab. I always make manuals and online help. But will 
anybody read them? NEVER! They come to me with a specific thing they want 
to do and expect me to guide them step-by-step in doing it. If I try to 
instruct them, not just do their work for them, it ends up a frustrating 
waste of everybody's time. Am I just a very bad doc writer? I can't find 
out because nobody reads the damn docs.

The GUI paradigm has got everybody expecting to see buttons, dialog boxes, 
pull-down menus and the like. They don't have the attention span required 
for expressing what they want in a command line. They want to scan the 
screen with the mouse and look at the little helps that pop up until they 
find something that sounds like what they think they want do do. When it 
"doesn't work" they have no idea why. When it does work, they may not be 
able to remember how they got there.

So I am going over the CommandLineIntro, trying to learn what makes docs 
good or bad. Eventually I want to use FM to re-work and publish the docs 
for my experix project.




More information about the Discuss mailing list