🚀 go-pugleaf

 
----------------------------------------------------------------------------
>"this cannot possibly affect
>anything except..." changes actually broke lots of things.]
 
    You are absolutely correct.  As someone who has served as a communications
systems engineer and systems manager on commercial, military, and space
programs (including the space shuttle), I can assure you that even small
changes require extensive testing and reverification for which we used to
charge the feds beaucoup bucks to make up for the buy-in bid prices.
 
    Back in the 70's we used to anticipate the transition from doing things in
hardware to doing them in software.  Problems could be fixed and systems could
be maintained because at least the "software could be changed".  Later, we went
back to doing many designs in hardware because we learned that at least the
"hardware could be changed."
 
    An example is the present situation in MacApp where it can't handle more
than one scrap type at a time because of a fix for an earlier bug.
 
    A proper combination of OOP and framework/system design can minimize these
problems and limit the effects of change propagation.  However, determining the
effects of any change is still not easy or obvious.
 
    Also, there is a very strong need for centralized configuration/version
management unless you want total chaos and version dispersion.  That is why we
prefer officially (Apple Computer) blessed solutions to our own or someone
else's hack solutions.
 
G. Gordon Apple   D4887
Advanced Communications Engineering, Inc.
Redondo Beach, CA
 
*** Anxiously awaiting news that the BedRock Marines have landed and wondering
how long it will be until the code-starved can be fed. ***