• Wrench@lemmy.worldEnglish
    451·
    9 months ago

    That’s awesome. Reminds me of programming UIs.

    I wrote the UI for a media player once. Our QA found a way to crash the player.

    “OH hey! I think I found a bad bug. Here, watch. You start a video, immediately hit stop, then start, then rewind, all before the video is done buffering. See? Crashed.”

    Me: “I… who would… all before playback begins? Uh… OK yeah, I think I know why it’s… is anyone actually going to… FUCK. Guess I’m staying late tonight”

    Rule number 1 for engineering. No matter what, there IS someone stupid enough to get themselves into that edge case if it exists.

    • Plopp@lemmy.worldEnglish
      22·
      9 months ago

      I mean, of course it should be able to handle that. Hitting the playback control buttons in any sequence, at any speed, at any given time or any state of the program or media shouldn’t crash it. If it does you did something wrong. Asking questions about who would ever do that is bizarre to me because that’s not the issue. It’s not the user being stupid, it’s just a fragile system that should be robust.

      • Wrench@lemmy.worldEnglish
        11·
        9 months ago

        Yes, hence the reluctant acceptance that it was something urgent I needed to fix, and why I fought so hard to get a QA on my team in the first place. They think so much differently than devs, and dream up conditions I couldn’t begin to imagine.

    • AA5B@lemmy.worldEnglish
      9·
      9 months ago

      I’d say it’s also bad engineering to assume everyone has a good internet connection. These actions become much more likely as the buffering g time increases

      • mindbleachEnglish
        2·
        9 months ago

        There’s a tool for simulating bad internet, named “comcast.”