Big Problems


73 points | by memorable 60 days ago


  • chubot 58 days ago
    The opening quote is probably from Richard Hamming, not Richard Feyman: (found through Google)

    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:

  • lifeisstillgood 58 days ago
    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

  • krschultz 58 days ago
    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 58 days ago
      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 58 days ago
        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 58 days ago
          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
        • mistermann 56 days ago
          Democracy seems highly similar in this regard.
    • fragmede 58 days ago
      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?
    • P5fRxh5kUvp2th 58 days ago
      I once saw someone complaining because they moved into a freshly-built apartment building and things were constantly wrong. A/C not working, shower not working, every time it came down to the contractor doing something wrong.

      but the apartment building was finished, the project for building it didn't fail.

      In the same way, software projects don't typically fail either, they just have a million things wrong with them.

      I don't think I've ever actually seen a software project outright fail, it's more that it never lived up to expectations.

    • bombcar 58 days ago
      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 58 days ago
        How many software engineering projects are CRUD apps or yet another ETL pipeline?
        • smegsicle 58 days ago
          are those the kind that typically fail?
  • baxtr 58 days ago
    > 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

  • anonymous344 58 days ago
    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..

  • twitchard 58 days ago
    My big question is "what's for lunch?"
  • informal007 58 days ago