In article <chunr7$e91@odak26.prod.google.com>,
Tony Lawrence <pcunix@gmail.com> wrote:
>
>FyRE wrote:
>
>>
>> Bit of a pet niggle of mine, since a new policy at my current
>> workplace requires me to document all kinds of processes I go through
>> to create a guide for others. Since the manager (and others) are
>> point'n'click monkeys, the documentation goes along the lines of "use
>> PuTTY, with username x, password y to log in. Type cd blah/blah, type
>> ls -ltr, then...". This is due to the fact the manager doesn't want
>to
>> actually learn anything new, just parrot what's written down. If I
>> change anything, it's a whole new load of docs. I did question why
>the
>> docs should be "idiot proof", since it's generally not a good idea to
>> let an idiot run around as root on a commercial UNIX system (and yes,
>> we have had incidents, like somebody changing to the root dir by
>> mistake (again, parroting my notes - and mistyping), then typing chmod
>> 700 *, which basically knocked 200 people off the system during a busy
>> afternoon. Then the manager editing scripts (to change some comments
>> to his liking for some reason) with MS Word, using Samba, which again
>> went unnoticed until we realised that no orders had been allocated
>> stock all afternoon. It also seems that if someone neglects to
>> document any possible error or problem that could occur with any
>> system (in idiot style), it's neglegent...

>Or the wannabe who broke one of my systems recently with a "chmod -R
>777" of / :-) I did NOT want this kid to have root access but his
>manager insisted..

Any word on what the manager said after he did that. Am I correct
in assuming you had to go back to fix it?

>Documentation is difficult and expensive. I was talking about that
>with one of my clients yesterday. We have a whole pile of vaguely
>related Perl scripts that are mostly undocumented and many of which are
>in partially unfinished state - items that should be config file
>candidates are hard coded, the script is putting too much or too little
>in its log file, it isn't cleaning out old data from its own store
>reglarly, that kind of thing. And of course documentation and comments
>are sparse if present at al.

If someone wrote a game program where the old scores were lost that
would be fixed immediately wouldn't it?

>Most of the problem is that these folks get new requirements from their
>clients very suddenly and need to have the new thing in place fairly
>instantly. It's typical for them to call me on Thursday afternon to
>describe something they want working Monday AM. I do what I can, but
>"slightly unfinished" is the usual result. There's always a budget to
>"get it working", but never one to go back and clean things up, and of
>course the longer that is delayed the more expensive it ultimately
>becomes.

I got called in one project that had a dealing of 12 days in the
future. The person at the company who had been working on it had
been at it for about 6 months and had less than 10% done.

A friend called me in and we both worked 18 hours days for the next
12 days - and some other really good programmers would come in
after they day jobs and work until about 2AM so they could go home
and get sleep for the next day.

There was only one trivial piece - that was window dressing and not
needed - that we didn't finish. The original budget was supposed
to be about $10K. At the end of the two weeks the guy I was
working for gave them a bill for over $60K. It had to go to the
home office to get approved - and at that time it was a Fortune
10 company - and one that no longer exists by the way.

So it's not just small companies that have these unreasonable
expectations.

The project was so successful they moved it as a main ap for their
transporation division however.

>The embarassing part is that you know somebody is going to have to fix
>it someday and they'll be royally pissed at the original creator :-)

Then be sure to put a nome de plume in the code as the author.

>Oh well - it's Sat am and I've got to go finish up one of their
>projects. Except it won't really be finished, it will just be
>"working".

I hate those.

Bill
--
Bill Vermillion - bv @ wjv . com