home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / mac / oop / macapp3 / 268 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  2.0 KB
  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!olivea!apple!applelink.apple.com
  2. From: D4887@AppleLink.Apple.COM (Advanced Comm Eng, G G Apple,PRT)
  3. Newsgroups: comp.sys.mac.oop.macapp3
  4. Subject: Re2: * Takeover Proposal *
  5. Message-ID: <725049273.0169828@AppleLink.Apple.COM>
  6. Date: 22 Dec 92 18:31:00 GMT
  7. Sender: daemon@Apple.COM
  8. Organization: AppleLink Gateway
  9. Lines: 37
  10.  
  11.  
  12.  
  13. ----------------------------------------------------------------------------
  14. >"this cannot possibly affect
  15. >anything except..." changes actually broke lots of things.]
  16.  
  17.     You are absolutely correct.  As someone who has served as a communications
  18. systems engineer and systems manager on commercial, military, and space
  19. programs (including the space shuttle), I can assure you that even small
  20. changes require extensive testing and reverification for which we used to
  21. charge the feds beaucoup bucks to make up for the buy-in bid prices.
  22.  
  23.     Back in the 70's we used to anticipate the transition from doing things in
  24. hardware to doing them in software.  Problems could be fixed and systems could
  25. be maintained because at least the "software could be changed".  Later, we went
  26. back to doing many designs in hardware because we learned that at least the
  27. "hardware could be changed."
  28.  
  29.     An example is the present situation in MacApp where it can't handle more
  30. than one scrap type at a time because of a fix for an earlier bug.
  31.  
  32.     A proper combination of OOP and framework/system design can minimize these
  33. problems and limit the effects of change propagation.  However, determining the
  34. effects of any change is still not easy or obvious.
  35.  
  36.     Also, there is a very strong need for centralized configuration/version
  37. management unless you want total chaos and version dispersion.  That is why we
  38. prefer officially (Apple Computer) blessed solutions to our own or someone
  39. else's hack solutions.
  40.  
  41. G. Gordon Apple   D4887
  42. Advanced Communications Engineering, Inc.
  43. Redondo Beach, CA
  44.  
  45. *** Anxiously awaiting news that the BedRock Marines have landed and wondering
  46. how long it will be until the code-starved can be fed. ***
  47.  
  48.