‹ BackHN Continuity

Thread

The Normalization of Inexplicable Failures

277 points · 124 comments · pxx

  1. theamk · · focus · HN ↗
    > When a button breaks on a website, I have a model about what should have happened. Somewhere a contract got broken. [...] I might not have access to debug just an HTTP status 500, but I expect there to be somebody whose job is to understand why the endpoint is 500ing. The ownership is well-defined albeit opaque³.

    > For many users, however, the actual experience is roughly just "stupid thing sucks." Software already feels capricious; more failures just change the rate of frustration.

    I am betting author does not use cloud services much. It is not just "users", it's developers as well. Github is returning 5xx? AWS service does not work? Your email did not get delivered? Nothing we (developers) can do, "stupid thing sucks".

    1. ryandrake · · focus · HN ↗
      We see this fatalistic attitude all the time in software. "Bugs are inevitable." No, they aren't! Bugs are a choice. Almost all companies choose bugs because "no bugs" is too expensive. It's sometimes the right choice but we need to acknowledge that it's a choice and not some natural property of software. Imagine if people who built bridges or airplanes thought "bridge collapses and airplane crashes are inevitable, no way to solve it."
      1. parpfish · · focus · HN ↗
        I’ve had several occasions where I would build a feature “properly” with defensive guardrails and handling of edge cases “that will never happen (but are technically possible)” and then you run into the coworker that says “it’s overengineered. YAGNI. Just do the one-line fix”
        1. jeremyjh · · focus · HN ↗
          But...were they wrong? There is a difference between "edge case" and "cannot ever happen". I've seen this trend a lot lately where Claude suggests a lot of extra code to handle things that cannot possibly happen. Unless you ask it to, it won't trace the flow of data through the app to confirm the edge case actually exists, if local conditions appear to allow it. Then the developer lets it implement this crap without asking that one question, and I have to say YAGNI in the review.
          1. [deleted] · · focus · HN ↗

            [deleted]

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.