[HN Gopher] On Building Systems That Will Fail (1991)
       ___________________________________________________________________
        
       On Building Systems That Will Fail (1991)
        
       Author : rramadass
       Score  : 47 points
       Date   : 2024-07-14 14:56 UTC (8 hours ago)
        
 (HTM) web link (larch-www.lcs.mit.edu)
 (TXT) w3m dump (larch-www.lcs.mit.edu)
        
       | rramadass wrote:
       | Pdf of the lecture here :
       | https://dl.acm.org/doi/pdf/10.1145/114669.114686
       | 
       | Note the six points mentioned in the final "Conclusions" section;
       | 
       |  _First it is important to emphasize the value of simplicity and
       | elegance, for complexity has a way of compounding difficulties
       | and as we have seen, creating mistakes. My definition of elegance
       | is the achievement of a given functionality with a minimum of
       | mechanism and a maximum of clarity.
       | 
       | Second, the value of metaphors should not be underestimated.
       | Metaphors have the virtue that they have an expected behavior
       | that is understood by all. Unnecessary communication and
       | misunderstandings are reduced. Learning and education are
       | quicker. In effect metaphors are a way of internalizing and
       | abstracting concepts such that one's thinking can be on a higher
       | plane and low-level mistakes are avoided.
       | 
       | Third, use of constrained languages for design or synthesis is a
       | powerful methodology. By not allowing a programmer or designer to
       | express irrelevant ideas, the domain of possible errors becomes
       | far more limited.
       | 
       | Fourth, one must try to anticipate both errors of human usage and
       | of hardware failure and properly develop the necessary
       | contingency paths. This process of playing "what if" is not as
       | easy as it may sound since implicit is the need to attach
       | likelihoods of occurrence to events and to address issues of the
       | independence of failures.
       | 
       | Fifth, it should be assumed in the design of a system, that it
       | will have to be repaired or modified. The overall effect will be
       | a much more robust system, where there is a high degree of
       | functional modularity and structure, and repairs can be made
       | easily.
       | 
       | Sixth, and lastly, on a large project, one of the best
       | investments that can be made is the cross-education of the team
       | so that nearly everyone knows more than he or she needs to know.
       | Clearly with educational redundancy, the team is more resilient
       | to unexpected tragedies or departures. But in addition, the
       | increased awareness of team members can help catch global or
       | systemic mistakes early. It really is a case of "more heads are
       | better than one."_
        
         | 7thaccount wrote:
         | A lot of these are good, but not sure how easy it is to do
         | anymore with Jack Welch style management everywhere (thinking
         | about #6 in particular). In my experience management sees the
         | bench strength fading and becoming nothing, but then will do
         | nothing to fix even if the wider industry is fading.
        
           | detourdog wrote:
           | I think your point would be filed using the third rule. Jack
           | Welch style management concerns might ought to be considered
           | irrelevant.
        
           | runlaszlorun wrote:
           | What's Jack Welch management style in your eyes?
           | 
           | I know only a little about his history at GE. And I don't
           | have any reason to defend the guy, just curious what the view
           | is these days.
        
             | 7thaccount wrote:
             | Extreme focus on the stock price and thus highly short term
             | thinking. The accountants run the show and try to
             | aggressively cut costs at every corner which works really
             | well in the short term, but over time the company gets
             | decimated and nobody can take the bigger product risks that
             | allow a company to continue to evolve.
        
       | vmh1928 wrote:
       | From the title I was expecting a discussion of physical building
       | subsystems, like HVAC and elevators.
        
         | interpunct wrote:
         | I hear you, since I spend half my free time fixing stuff that
         | breaks on my house and its contents.
        
           | interpunct wrote:
           | "I regret that I have but one upvote to give to my fellow HN
           | netizen."
        
         | detourdog wrote:
         | I think the same principles apply. I would argue the second
         | point that value's metaphors allows. Demonstrates how malleable
         | the technique is.
        
       | rickydroll wrote:
       | Are not wrong about MA rotaries. The Concord rotary on Rt 2 was
       | exciting before they rebuilt it. The junction of 2a into the
       | rotary still is exciting.
        
         | runlaszlorun wrote:
         | Ha, I've hit a that rotary exactly once about 20 years ago and
         | I remember it was a bit of a sight.
        
       | pgraf wrote:
       | One quote that I find funny from today's point of view:
       | 
       |  _As we approach the present, corresponding to a personal
       | computer, the graph really should become more complicated since
       | one consequence of computers becoming super-cheap is that
       | increasingly, they are being embedded in other equipment. The
       | modern automobile is but one example. And it remains to be seen
       | how general-purpose the current wave of palm-sized computers will
       | be with their stylus inputs._
        
       | contingencies wrote:
       | Some nice pearls of wisdom in here.
       | 
       | Added to https://github.com/globalcitizen/taoup
        
       ___________________________________________________________________
       (page generated 2024-07-14 23:00 UTC)