←back to thread

Free software scares normal people

(danieldelaney.net)
917 points cryptophreak | 8 comments | 30 Oct 25 15:07 UTC | HN request time: 0.001s | source | bottom
Show context
squeedles ◴[30 Oct 25 16:12 UTC] No.45761639[source]▶
Good article, but the reasoning is wrong. It isn't easy to make a simple interface in the same way that Pascal apologized for writing a long letter because he didn't have time to write a shorter one.

Implementing the UI for one exact use case is not much trouble, but figuring out what that use case is difficult. And defending that use case from the line of people who want "that + this little extra thing", or the "I just need ..." is difficult. It takes a single strong-willed defender, or some sort of onerous management structure, to prevent the interface from quickly devolving back into the million options or schizming into other projects.

Simply put, it is a desirable state, but an unstable one.

replies(22): >>45761688 #>>45761787 #>>45761946 #>>45762556 #>>45763000 #>>45763132 #>>45763419 #>>45763515 #>>45764215 #>>45765589 #>>45766183 #>>45766281 #>>45768514 #>>45769691 #>>45771196 #>>45771307 #>>45771846 #>>45772026 #>>45773411 #>>45773951 #>>45776266 #>>45779651 #
duxup ◴[30 Oct 25 18:09 UTC] No.45763132[source]▶
It always amazes me how even just regular every day users will come to me with something like this:

Overly simplified example:

"Can you make this button do X?" where the existing button in so many ways is only distantly connected to X. And then they get stuck on the idea that THAT button has to be where the thing happens, and they stick with it even if you explain that the usual function of that button is Y.

I simplified it saying button, but this applies to processes and other things. I think users sometimes think picking a common thing, button or process that sort of does what they want is the right entry point to discuss changes and maybe they think that somehow saves time / developer effort. Where in reality, just a new button is in fact an easier and less risky place to start.

I didn't say that very well, but I wonder if that plays a part in the endless adding of complexity to UI where users grasp onto a given button, function, or process and "just" want to alter it a little ... and it never ends until it all breaks down.

replies(7): >>45763322 #>>45763345 #>>45764270 #>>45764775 #>>45765654 #>>45766997 #>>45771204 #
1. nerdponx ◴[30 Oct 25 19:30 UTC] No.45764270[source]▶
Don't fall into the trap of responding to the user's request to do Y a certain way. They are asking you to implement Y, and they think they know how it should be implemented, but really they would be happy with Y no matter how you did it. https://xyproblem.info/
replies(3): >>45764431 #>>45764808 #>>45765180 #
2. duxup ◴[30 Oct 25 19:44 UTC] No.45764431[source]▶
Yeah I often will ask for a quick phone call and try to work from the top down, or the bottom up depending on the client. Getting to the thing we're solving often leads to a different problem description and later different button or concept altogether.

Sometimes it's just me firing up some SQL queries and discovering "Well this happened 3 times ... ever ..." and we do nothing ;)

3. LegionMammal978 ◴[30 Oct 25 20:15 UTC] No.45764808[source]▶
On the other hand, I've not uncommonly seen this idea misused: Alice asks for Y, Bob says that it's an XY problem and that Alice really wants to solve a more general problem X with solution Z, Alice says that Z doesn't work for her due to some detail of her problem, Bob browbeats Alice over "If you think Z won't work, then you're wrong, end of story", and everyone argues back and forth over Z instead of coming up with a working solution.

Sometimes the best solution is not the most widely-encouraged one.

replies(3): >>45765172 #>>45770384 #>>45771222 #
4. nerdponx ◴[30 Oct 25 20:51 UTC] No.45765172[source]▶
Bob saying "you should use Z end of story" it's just as a hardheaded and unhelpful as Bob saying "X doesn't do that end of story".
replies(1): >>45772663 #
5. exasperaited ◴[30 Oct 25 20:51 UTC] No.45765180[source]▶
I think the XY problem thing is likely very common. But developers are tending to use the term in a very dismissive way, superior way now.
6. imtringued ◴[31 Oct 25 10:24 UTC] No.45770384[source]▶
I've seen this too. Explicitly talking about something being an XY problem is a red flag, because the goal is usually to dismiss you with a canned answer that doesn't help you.

The point of XY problems isn't to call people out on supposedly bad behaviour, it's to push them in the right direction and provide more context.

7. rcxdude ◴[31 Oct 25 12:19 UTC] No.45771222[source]▶
Yes, often an issue on stackoverflow. It's one of the reasons why it can be frustrating to use as you get more experienced: if an expert is at the point of asking on stackoverflow they're probably doing something at least a little bit unusual! But people who answer on stackoverflow mostly see questions from less experienced people and so default to operating in that mode.

I generally try to answer the Y but also indicate that it suggests there may be an X that could be better achieved some other way, and mention Z if I'm reasonably confident in what X is. It might increase the chance that the person asking just does Y anyway even if Z would be better, but frankly that's not really my business.

8. dwaltrip ◴[31 Oct 25 14:56 UTC] No.45772663{3}[source]▶
Unfortunately, still quite common. The ego is quite the tricky one.