pull down to refresh

Writing software: robustness vs being exact
1789 sats \ 3 comments \ @zuspotirko 31 May devs
Hi there,
today we had a simple but interesting discussion because a user complained about our software refusing to generate his Excel file because the name he typed in was .txt. Software threw an error "ValueError: Invalid extension for engine blablabla : '.txt'. Might not have been the most understandable error message but whatever. So far so good.
The uninteresting part in this specific example: It would take 1 minute to catch this error and rename the input to .xlsx. That's what I call "robustness" approach. The "being exact approach" would be to insist on the user input being used as intended. And every component insisting of getting correct inputs before it.
The interesting general question: What is your opinion on how software should handle things like that in general? Especially deeper in the stack. If we build software on top of software on top of dependencies on top of dependencies. Should we always insist our software to be used precisely? Which things should be catched and handled? There are extreme cases in both directions. But what is a good rule of thumb
Poll is how you would handle our situation (I chose the "robustness" approach). Tell me your thoughts on this general topic in the comments.
robustness50.0%
exactness50.0%
18 votes \ poll ended
write
preview
related posts
173 sats \ 0 replies \ @netstatic 31 May
Your question of robustness vs exactness frames the 2 as if they're at odds with each other, you can have both robustness and exactness. The UX problem encountered by your user wasn't about robustness, it was about how you decided to engineer your experience.
If you were going to force an extension for a specific output type, why allow the user to specify an extension at all? Doing it this way is setting them up for failure. It's like if I asked you for advice on something I've already made a decision on.
If you're building on libraries that have this problem, make sure as many inputs that would lead to inconsistent states in the library are disallowed at the user input generated from your code. Never correct things for the user implicitly if you can help it.
Best case is you never allow them to make a mistake in the first place, but if that's not possible, you can catch inputs that would potentially lead to errors and inform the user to take action on a proposed fix. And if you need to implicitly correct input as a last resort, although I can't imagine a scenario where this would be needed right now, then you should absolutely notify the user that this correction happened so that they don't get confused on how they got their output.
reply
30 sats \ 0 replies \ @mateusdeap 31 May
I only vote for exactness because I think in this case it would be better to ask the user if they were sure they wanted that extension and give them an option to never ask again and use the robustness approach after that
reply
20 sats \ 0 replies \ @Lumor 31 May
Pop up warning dialog with options:
  • Go back
  • Fix - Rename to .XLSX
  • Ignore - Keep .TXT
reply