Free software scares normal people

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.

In my experience, this is a communication issue, not a logical or technical or philosophical issue. Nor the result of a fixation caused by an idea out of the blue.

In my experience it may be solved by both parties spending the effort and time to first understand what is being asked... assuming they are both willing to stomach the costs. Sometimes it isn't worth it, and it's easier to pacify than respectfully and carefully dig.

You are describing a form of the XY problem. https://en.wikipedia.org/wiki/XY_problem

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/

I think you are likely correct, thank you.

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 ;)

I always tell clients (or users): "If you bring your car to the mechanic because it's making a noise and tell them to replace the belt, they will replace the belt and you car will still make the noise. Ask them to fix the noise."

In other words, if you need expert help, trust the expert. Ask for what you need, not how to do it.

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.

If you tell the mechanic "my car is making a noise, fix the belt please" and then they just fix the belt, that's on the mechanic as well.

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".

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.

I would hope the mechanic would engage with the customer in more back and forth.

But sometimes power structures don't allow for it. I worked tech support in a number of companies. At some companies we were empowered to investigate and solve problems... sometimes that took work, and work from the customer. It had much better outcomes for the customer, but fixes were not quick. Customers / companies with good technical staff in management understood that dynamic.

Other companies were "just fix it" and tech support were just annoying drones and the company and customer's and management treated tech support as annoying drones. They got a lot more "you got exactly what you asked for" treatment ... because management and even customers will take the self defeating quick and easy path sometimes.

Yeah, I've had now a couple decades of experience dealing with this, and my typical strat is to "step back" from the requested change, find out what the bigger goal is, and usually I will immediately come up with a completely different solution to fulfill their goal(s). Usually involving things they hadn't even thought about, because they were so focused on that one little thing. When looking at the bigger picture, suddenly you realize the project contains many relevant pieces that must be adjusted to reach the intended goals.

It's a hypothetical to communicate an entirely different point. The mechanic is't real or important.

It is a common misconception that the "expert" knows the best. Expert can be a trainee, or may be motivated to make more for its organisation or have yet to encounter your problem.

On the other hand, if you are using your car for a decade and feel it needs a new belt - then get a new belt. Worst case scenario- you will lose some money but learn a bit more about an item you use everyday.

Experts don't have your instincts as a user.

I am a qualified mechanic. I no longer work in the field but I did for many years. Typically, when people 'trust their instincts as a user' they are fantastically wrong. Off by a mile. They have little to no idea how a car works besides youtube videos and forum posts which are full of inaccuracies or outright nonsense and they don't want to pay for diagnosis.

So when they would come in asking for a specific part to be replaced with no context I used to tell them that we wouldn't do that until we did a diagnosis. This is because if we did do as they asked and, like in most cases, it turned out that they were wrong they would then become indignant and ask why we didn't do diagnosis for free to tell them that they were wrong.

Diagnosis takes time and, therefore, costs money. If the user was capable of it then they would also be capable enough to carry out the repair. If they're capable of carrying out the diagnosis and the repair then they wouldn't be coming to me. This has proved to be true over many years for everyone from kids with their first car to accountants and even electrical engineers working on complex systems for large corporations as their occupation. That last one is particularly surprising considering that an engineer should know the bounds of their knowledge and understand how maintenance, diagnosis and repair work on a conceptual level.

Don't trust your instincts in areas where you have no understanding. Either learn and gain the understanding or accept that paying an expert is part of owning something that requires maintenance and repair.

I think what you're driving at can be more generalized as users bringing solutions when it would be more productive for them to bring problems. This is something I focus on pretty seriously in IT. The tricky part is to get the message across without coming across as unhelpful, arrogant, or obstructive. It often helps to ask them to describe what they're trying to achieve, or what they need. But however you approach the discussion, it must come across as a sincere desire to help.

If you don't trust the expert then why are you asking them to fix your stuff? It's a weird idea that you'd want an idiot to do what you say because you know better.

In this case, it's at least partly because the expert has access to a lift...

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.

In general the advice I've heard it that users are absolutely going to be right about when there's a problem (which you ignore at your peril), they can usually identify where the problem is, but they are terrible at coming up with ways to fix it.

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.

If they're asking the mechanic to do X and they understand the mechanic is just doing X and NOT venturing to fix your problem. I guess that is fine.

I agree though it sets up a weird dynamic where folks might come back to the expert and complain a problem isn't fixed, but that's not what they asked for / they broke the typical expert and customer dynamic.

In my experience the best thing is to then convince the expert you are right, using your own expertise.

If your mechanic is too stupid to recognize the problem after you explain it then you don't have a mechanic, the set of hands you are directing is basically unskilled labor.

How do you know you're right if you haven't fixed it?

That seems like a way to just be a stuck in the mud and wrong the whole time.

exclude the impossible and what is left however improbable must be the truth

Unfortunately, still quite common. The ego is quite the tricky one.

If we're still talking about an amateur doing it, isn't their understanding of the possibilities petty limited?