BL> It dawned on me that as soon as a program gets larger than one
 BL> person can assimilate, and "know" properly, then the wheels
 BL> have to fall off. This must have happened at Microsoft and IBM
 BL> already. They create monsters that no one really understands,
 BL> all patched together with sticky tape showing the joins.

 BV> It's worse than that Bob. You end up with half a dozen goons
 BV> who always know better after the event. They can invariably see
 BV> something which has been left out or can simply be done better,
 BV> so they do. Most of the time they are not aware of the _real_
 BV> reason why the particular feature was not implemented in the
 BV> first place or _why_ it was done the way it was.

  Yair... but once the program gets truly large, the process is
inevitable from the start. All the later fiddling will only make it
worse, as you say.

 BV> Cripes, I have that problem with stuff I have written myself
 BV> when I come back to it 6 months later.

  Do you come back to stuff you did a few years ago and think: "Jeese!
I must have been a genius! This is really clever."

  I have kept a Lab book all my working life, where I jot down ideas
and problems solved, pet circuits and that sort of stuff, and after a
few years I always impress the shit out of myself with what I could do
a few years ago. It's a good way to measure how much you run down with
age.

 BV> I reckon that is what creates half of the problems. The other
 BV> half are probably just fuck-ups.

  Yes... but if a project is *too* big for one man to know it all and
give it continuity, then the fuckup is inevitable. We saw it happen
with NASA, and Microsoft and IBM. There must be a top limit to what we
can do - no matter how many people you put on the job, or how well you
manage it. It has to come back to one person finally, and if *he*
doesn't know what the fuck is happening, then no one knows.

Regards,
Bob
 
___ Blue Wave/QWK v2.12
@EOT:

---