567
submitted 5 days ago by [email protected] to c/[email protected]
you are viewing a single comment's thread
view the rest of the comments
[-] [email protected] 80 points 5 days ago

There's a quote along the lines of "User error is not a thing, the system allowed for the error through bad design"

Which can be true depending on how far you stretch it. I'd say that if a chunk of the user base is having a problem, it's a design problem

[-] [email protected] 43 points 5 days ago* (last edited 5 days ago)

I recently had a case at work where you could move an object by holding the left mouse button and delete it with the right mouse button. If you deleted it while moving, you got an error message and the program would crash. It was an easy fix but afterwards I had a one hour discussion with our usability engineers if what I had fixed was a bug (my opinion) or a user error (theirs).

[-] [email protected] 32 points 5 days ago* (last edited 5 days ago)

That one's easy. Is the crash part of the program's design?

If not: It's an implementation bug, the program is not behaving as intended.

If yes: It's a design bug, crashes shouldn't be intended behavior.

[-] [email protected] 22 points 5 days ago* (last edited 5 days ago)

Their argument was along the lines of "The requirements and design don't specify what should happen if you move and delete at the same time so it can't be a bug. Behavior that doesn't violate the design but also doesn't lead to the result the user wanted is a user error". My argument was that we can't always specify the interaction between arbitrary features other than "If the user does two things at once, at least one of them should be executed, ideally both" and "the program shouldn't crash just because the user did something unexpected". Otherwise our design document would be ten times as long.

[-] [email protected] 27 points 5 days ago

I think that there is always an implied design requirement of the program shouldn’t crash.

[-] [email protected] 12 points 5 days ago

You would think so, right? But that doesn't have a requirement ID so apparently it can't be referenced in the incident report.

[-] [email protected] 4 points 5 days ago

Sounds like the devs are cowards. Or maybe their pay counts on it not being a bug

[-] [email protected] 9 points 5 days ago

Software for a medical device. Everything needs to be done exactly right and documented in three different places or else the regulatory agencies from at least three countries get really angry at you and worst case pull your device from circulation. Less cowardice and more cover your ass. Still annoying though.

[-] [email protected] 3 points 5 days ago

I see, so it's a situation where catching the full blame can tank your career. Yeah, that makes sense.

[-] [email protected] 21 points 5 days ago

Yeah, that's basically the kind of logic you use when designing a low-level programming language: If we didn't define what happens here then anything that happens is correct behavior and it's up to the user to avoid it.

Of course applying that logic to a GUI application intended for a comparatively nontechnical audience is utter madness.

[-] [email protected] 6 points 4 days ago* (last edited 4 days ago)

That's the kind of logic people historically used when designing low level programming languages. It's not the kind of logic you should use or that people nowadays usually do use. Undefined behavior is widely seen as a Bad Thing in the programming language design community.

[-] [email protected] 2 points 4 days ago* (last edited 4 days ago)

Oh, don't get me wrong, I fully agree. Undefined behavior is terrible UX and a huge security risk.

Undefined behavior was kind of okay when RAM and storage were measured in kilobytes and adding checks for this stuff was noticeably expensive. That time has passed, though, and modern developers have no business thinking like that, even ones working on low-level languages.

I should've phrased my comment differently.

[-] [email protected] 17 points 5 days ago

That is the type of thinking that causes a massive amount of CVEs in those languages.

[-] [email protected] 7 points 5 days ago

Hey, the design specs never said the program shouldn't blast out and air raid siren at full volumn every time the user clicks a button. Cannot be a bug, must be user error.

[-] [email protected] 8 points 5 days ago

They were holding it wrong, obviously.

[-] [email protected] 7 points 5 days ago

God really should get on that and fix the design issues with humans

[-] [email protected] 5 points 5 days ago

I dunno, if we're really designed in that dudes image then I wouldn't trust him at all personally.

[-] [email protected] 4 points 5 days ago* (last edited 5 days ago)

But IMO that's one reason weird UX/design is not uncommon and can persist in dev ecosystems. The intended users are more proficient than average and most are able to work around most issues.

[-] [email protected] 1 points 5 days ago* (last edited 5 days ago)
this post was submitted on 26 May 2025
567 points (96.4% liked)

Programmer Humor

23563 readers
3058 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 2 years ago
MODERATORS