Clear questions and runnable code get the best and fastest answer |
|
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Every software development project should have a writer. For a big, well funded project this person may have the title of 'technical author' ... Coder hate to document ... write stuff that is entirely unreadable by anyone without a CS/coding background and intimate knowledge of X, Y & Z.
There is some truth to the comments here. But I will add, "who are the documents for?". Coders need specifications where everything spelled out in great detail. Be it formal specifications or an agile process you have to be able to express the result in binary. There is no room for interpretation. If you are on a large team and assigned Foo class you may well be interested where it fits in the class heirarchy - something a BA or non-cs/it writer cannot reasonably provide. Management types want to know *what they are spending their money on* and *is this product alligned with my business objectives*. It is here that a *writer* may be of some use, distilling the *bar* product into some language that makes business sense. Users dont read documents and only want documentation if *all else fails*. But end user documentation is worth it's weight in gold. Many a project has failed because users cant just *read the source*. Hence writers again prove useful in generating documentation. As a result I never really mandate any one *documentation/specification* process or set of *hard rules*. Each project is different. Instead I try to provide the right balance of documentation between coder, phb and user. In reply to balance b/w coder, business and user documentation
by g00n
|
|