>Nikki
>
>Ha! Consultant! That's their job - to document, criticise and, ultimately, cock-up. cf a chef vs a food critic, playwright vs critic, artist vs art critic, cat vs a flea, bowel vs a tape-worm.

LOL!!!

>
>I *did* go the full nine yards university degree route, learned all that stuff, loads on documenting a system before and as developing, but in the real world one doesn't always have the time to do all, and usually a boss patient and generous enough to pay you for that period.
>
>IMHO putting good comments in your code as you go along, writing meaningful names and functions, etc, (eg lnRecordCount vs XX) goes a long, long way.
>

Aw c'mon - using X (not XX - far too lengthy) as the standard variable, object, cursor, program and control name saves typing time and disk space.

>functional analysis and program analysis? You gotta ask first who is gonna read it and when. And if they do, who ever will again?
>
Agree - I've only seen real attempts at program documentation on a few projects, and they absolutely never were even close to up-to-date and were, for the most part, useless.

>As for user manual: Well, if as you say, all hands in the company know the system, and they're the users, what's the point? If it's for others then I'd approve. As a matter of fact, that's just what I'm doing at the moment.
>

I do think a user manual is a good thing in a larger organization, but again the only one I ever saw that was up-to-date was one my company did for a client as we wrote their application. The manual was not kept up-to-date after it was released to the client.

IMO a user manual is something that should be written by users, not developers. The developers understand the underlying program but generally do not understand the program usage from a user POV. It's one thing to say that a certain button does something - it's another to give the business process and reason a user should push the button.


>My two penn'orth
>
>Terry
>
>
>>i hv been a progrmmer for a few years most of it self taught, no fancy college stuff. recently our company hired a consultant and he was surprised that i hv not yet created a
>>
>>functional analysis
>>program analysis
>>user manual
>>
>>of the program
>>
>>and a lot of other stuff,
>>
>>we only have 5 employees in our company, everyone knows the program inside out.
>>
>>my question here is
>>
>>1. how important are these things and what are these things (except the user manual which i understand)
>>
>>2. is the consultant just trying to impress my boss
>>
>>3. what other documentations are there which are necessary to be done along with the program?
>>
>>4. where do i get to learn all this stuff?
>>
>>any help is welcome
>>
>>thanks