BL>  I wonder how they actually develop this stuff? I was comparing the
BL> design of a TV set to a large program with keith, and I realised that
BL> it's a valid comparison. The T-29 was 20,000 man-hours, and that's a
BL> pretty big program if you put the same effort into writing code. It
BL> has to be split up, and there has to be an overview with one person
BL> in charge or it doesn't work.

BL>  keith was talking about his own experience, with standard interfaces
BL> between various parts of the program; the same way that ant's dickhead
BL> with the video machine was talking, and that just doesn't work! The
BL> interfaces end up the main part of the project! The tail wags the dog.

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 have to
BL> fall off. This must have happened at Microsoft and IBM already. They
BL> create monsters that no one really understands, all patched together
BL> with sticky tape showing the joins.

It's worse than that Bob. You end up with half a dozen goons who
always know better after the event. They can invariably see
something which has been left out or can simply be done better, so
they do. Most of the time they are not aware of the _real_ reason
why the particular feature was not implemented in the first place or
_why_ it was done the way it was. Cripes, I have that problem with
stuff I have written myself when I come back to it 6 months later.

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

Cheers, Brenton
@EOT:

---