X-no-Archive:yes
Been there, done that, have the life vest from the sinking ship. Was shown
large red notebooks chock full of system documentation. They weren't enough.


I'll give you that good documentation is as necessary as good people, and I
should have mentioned that as well. OTOH, even good documentation is hard to
deal with after the brain trust has left, or mass turnover in your words.
Mergers and outsourcing have their own problems to deal with for good
documentation and good people policies. OTOH, one thing that leads to this
anarchy is inane procedures that get ignored because developers have seen
that they add no value. I've seen a shop were there was a grey market for
version control work arounds, and the existing version control system was so
badly implemented that it was later replaced. I will gladly produce audit
trails, and document my work, and sit down and explain to genuinely
interested parties, but am frankly sick to the teeth of spending a few hours
here and there over the course of months, to accomplish ultimately very
little, because it takes people in very different groups with different
agendas and little trust or respect between them (and in our case, working
for different companies, but outside of a normal outsourcing or consulting
relationship). I do not see how discouraging cooperation across such
functions, especially within a company, in the name of audit standards is
going to improve that situation.

And I find Wirt's argument persuasive: that the 3000 can be found in
businesses with no IT group, and that this is a good thing, to be greatly
encouraged. Computing can be a low maintenance activity. Where a company has
an economy of scale to have such specialists, and to organize them into
groups with some functions, does it necessarily make sense to prohibit
someone from performing some function because they also have other
responsibilities? I am loathe to think what it would take to write and
maintain (system programming) a secure (security) ftp job (networking,
application development) that runs as part of the production schedule
(production support, system administration), if there is no one who actually
understands more than one of these areas, and can think thru all of the
implications that activity in one area has on another.

FWIW, I do recall a brief article discussing RAD as Rapid Application Death,
where the author suggested that these hacked up 1.0 releases that would be
replaced by another cheap product's 1.0 release, none of which would ever
see a 2.0.

> -----Original Message-----
> From: Richard Gambrell [SMTP:[log in to unmask]]
> Sent: Wednesday, December 30, 1998 2:40 PM
> To:   [log in to unmask]
> Subject:      Re: audit issue
>
> Then one needs to consider mass turnover, mergers, outsourcing, etc.  What
> happens then?  Good (documented - and followed) procedures at least
> maintain
> the integrity of the source code and operational scripts, etc.  But, this
> presumes the value of maintaining those systems through time.
        <snip>