[HN Gopher] Big Problems
       ___________________________________________________________________
        
       Big Problems
        
       Author : memorable
       Score  : 64 points
       Date   : 2022-10-01 01:31 UTC (1 days ago)
        
 (HTM) web link (thoughtfulatlas.bearblog.dev)
 (TXT) w3m dump (thoughtfulatlas.bearblog.dev)
        
       | chubot wrote:
       | The opening quote is probably from Richard Hamming, not Richard
       | Feyman:
       | 
       | https://news.ycombinator.com/item?id=2301089 (found through
       | Google)
       | 
       | https://www.cs.virginia.edu/~robins/YouAndYourResearch.html
       | 
       | Although maybe they knew each other and both gave the same advice
       | ...
       | 
       | Actually that 2011 HN thread links to this paper, which
       | attributes the same sentiment to Feynman, without an exact quote:
       | 
       | https://people.tamu.edu/~huafei-yan//Rota/tenlesses.pdf
        
       | krschultz wrote:
       | For many years my "big question" has been "why do software
       | engineering projects fail at a disproportionally higher rate than
       | other engineering fields?"
       | 
       | Though I have to say the other engineering fields are not doing
       | so hot lately either, so I might have the wrong question.
        
         | mynegation wrote:
         | After 20+ years in the field: main reason is unclear
         | requirements. Software malleability is taken for granted so
         | much that the under specification and fluidity of requirements
         | became a norm and canonicalized in "agile". That's not
         | necessarily a bad thing, it does allow for quick advancement of
         | what is possible but high failure rate is the price we pay.
         | Second: unlike traditional engineering, there are not too many
         | university or college programs that take rigorous approach to
         | building software at scale. Till today, software is a free-for-
         | all industry. That allowed us to grow very fast, but - again -
         | high failure rate is the price we pay. Third - lack of formal
         | standards and by that I mean not just APIs or protocol specs
         | but formal requirements on things like performance, fault-
         | tolerance, lifespan etc.
        
           | amelius wrote:
           | Also, bugs in software are seen as a fact of life. You can't
           | get warranty on software (at least this holds in practice for
           | most consumers). If MacOS deletes all your files, good luck
           | proving that it wasn't your fault, and good luck suing Apple.
           | 
           | So this gives programmers a carte blanche to create crap,
           | effectively.
        
             | gonzo41 wrote:
             | Auto companies do big recalls as well. They just have to
             | pay more to fix a bug so there's more effort in front
             | loading QA
        
         | bombcar wrote:
         | Many many engineering problems are basically "build a copy of
         | that thing over there, but build it here". Software is often
         | vastly different each time.
        
           | krschultz wrote:
           | How many software engineering projects are CRUD apps or yet
           | another ETL pipeline?
        
         | fragmede wrote:
         | That's a very broad big question. Like, do they really fail
         | more? What's the numerator and denominator? There are are tons
         | of high-profile failures, but there are innumerable successes
         | as well. Do you count pushing the 100 or so versions of Chrome
         | that have been pushed out, across millions of devices as one
         | success, or a billion? How do you count projects that don't
         | work right at launch, but do end up working okay after a couple
         | versions?
        
       | baxtr wrote:
       | _> You have to keep a dozen of your favourite problems constantly
       | present in your mind, although by and large they will lay in a
       | dormant state. Every time you hear or read a new trick or result,
       | test it against each of your twelve problems to see whether it
       | helps._
       | 
       | Reminds me of similar patterns elsewhere. People keep "tabs" open
       | on specific topics and add information over time.
       | 
       | - Mathematician Serge Lang kept correspondence and related
       | documentation in extensive "files"
       | 
       | - Tony Fadell says you should keep coming back to ideas that you
       | can't stop thinking about and add more insights over time
        
       | lifeisstillgood wrote:
       | I like the paper idea - that paper and ink becomes an extension
       | of our bodily selves (probably more priopeeception than some
       | spiritual thing).
       | 
       | I mean I can remember and riff off a great paragraph in physical
       | book, where the book is on the shelf, which page the writing is
       | on, did I write next to it? But doing something like that on this
       | iPhone - forget it, it is not "there" in any useful sense
        
       | informal007 wrote:
        
       | anonymous344 wrote:
       | my big question is: what frequency (or should I say spectrum) is
       | smell.
       | 
       | and more new from one man's prophecy that said that whole cities
       | will get their energy from a device as small as matchbox... how
       | can that huge energy come out even because ou need thick wires..
        
         | mistermann wrote:
         | Maybe it is a different form of energy, for example the kind
         | referenced in "Gosh, I feel incredibly energetic today!"?
        
         | isoprophlex wrote:
         | The qualia of smell are our subjective experience of chemical
         | space
         | 
         | https://en.m.wikipedia.org/wiki/Chemical_space
        
       ___________________________________________________________________
       (page generated 2022-10-02 23:01 UTC)