The XY Problem (2014)
xyproblem.info
xyproblem.info
Of course, the "XY problem" usually presumes a naive person ("user")who falsely imagines the more complicated-sounding solution Y would solve their simple problem. And that's a pretty common situation.
The general approach for all this stuff is whenever someone is asking for the solution to a complicated or weird question, just verify they have some reason to approach it that way. There's no reason to automatically assume either they do or they don't and not assuming anything lets you approach them more respectfully.
So I went to home depot and asked for exterior paint. It was winter, and I instantly got a lecture about how you can't paint outside because it's too cold (before the guy showed me where the paint was).
It's minor obviously, but it stands out because it's just like all these internet discussions where someone would rather tell you you're doing it wrong then try and help you. To me it's a cultural problem along the lines of lots of "we better not give people information because they are not enlightened enough to use it the way we want them too" ways of thinking. Personally I think it's a bad approach everywhere.
Happens all the time in Stack Overflow.
Just answer the fucking question, and then give the lecture on why you think it should be done that way, or why it shouldn't be done at all...
If you do tech support of any kind with random people, it's pretty clear that a majority simply don't know what's available, or why Y may not be a good idea. They need to do a thing, heard that Y can do it, and now they're asking how to use Y - reasonable, but frequently misguided. When Y is dramatically more complex (either harder to set up, or more error-prone to use), recommending X before sinking a ton of effort into explaining Y solves a lot of cases quickly, for both parties.
I just couldn't bring myself to give that jerk credit, so I deleted the question and never logged in again. There are a lot of smart people there, but it's just not worth dealing with them.
Maybe this isn't an XY problem, but I suspect it's just as common (at least on most of the Stack Exchange sites).
[0] Anyone who thinks they know all of C++ doesn't even know what they don't know.
User asks I want to do Y.
The responding party should in my opinion:
- Provide a solution to Y first. This is OP's point.
- Then as a corollary, provide some of their guesswork of what X might be and if it is true, then this is how to solve X without having to do Y.
So, it is still beneficial to n00bs and the uninformed, just puts the direct answer to Y first. That's all OP is asking and I agree with that.
Most of the time, smartass responses go into the guesswork regime by assuming the User wanted to do X. More than often User actually wanted to do Z, it's not always true and it is polluting SO against the spirit of "Direct question ---> Direct answer" because discovery and searching of answers happen through Y, not X. Most people came to SO because of Y, that's how they landed there in the first place.
The bad approach is when the entire thread is full of guesses of what X might be without knowing the full context. Y is nowhere to be found. It breaks the UX of SO.
They could ask their own questions.
I'd rather have a database of specific questions with specific answers than "X-Ys" all over the place.
Again, they should be expected to ask their own questions on the site, so they could get the answers they're looking for. Come on, that's not hard to grasp.
A question like "How to delete a project from Google Cloud Console" [1], should have a clear, definite answer. I wouldn't expect to see something like "this is how you register an account on AWS", just in case "the user is changing providers".
1: https://stackoverflow.com/questions/16621921/how-to-delete-a...
Might also point out that a lot of people finding the question later on Google because they the same question are just trying to do the same assignment, so Stack Overflow is undermining its own stated purpose here.
This isn't something you do by discussing how unfair other people are. It's something you do by communicating the constraints you're working inside, your knowledge of more typical solutions, and why they don't work for you.
If you aren't providing that information, you're wasting the time of everyone who is voluntarily helping others. It's not their fault that you're not providing critical information for answering your question effectively.
When you're the special case, you have to communicate that fact. It's just wasting everyone's time when you expect others to know it without communication.
There are two failure modes though:
1) You really want to do Y, not X. You are not asking the question, just searching for the answer, and find that "how do you do Y?" question, and the answer is "do X instead". Because you're a special case, these answers will likely dominate your search results.
2) You decide to ask the question. You make it very clear that you want to do Y, not X. Your question is closed as a duplicate of the one whose answer was "do X".
Typical situation: I get called in as a consultant/freelance/whatever, I inherited X. I can make a small patch if I can do Y. Even when I preface it with "I would normally rewrite X correctly, but that touches on all systems, how can I do Y?" It turns straight into an argument about doing X right.
It's like I'm driving, make a left turn and end up lost. They are telling me to make the right turn at Albuquerque instead of the left.
Other scenario is that I'm trying to glean some insight on the language and I'll reduce a problem to bare basics and ask something like, "what's going on here?" They will answer "don't use that, use X library instead." That wasn't the question, the question was what's going on with the programming language -- why is it acting weird. I know that nobody would write the code that way, I isolated the problem to specifically inspect a single element.
But that's not what the XY problem is about. There is no case where "you should have bought a Toyota" is a valid response to "how do I change the spark plugs on my Lotus?". That's just internet jerks being... Jerks.
People hit that XY button more than needed, and I have seen this even in the earliest days of Linux. I remember, pre-Google, when asking some questions on IRC about recompiling the kernel for my distro, I would get smart-ass responses like "What you should have done is selected this other distro."
It's led to me rarely asking questions if I think the issue could be construed as XY.
I ask a quæstion about a specific, unusual grammatical form in a language I find hard to understand, and I am met with “You should instead phrase it in this more basic way that you already understand.”.
I am obviously not asking how to translate the specific example sentence I conjured up, I am asking about how to use the specific grammatical form I inquired about.
and the question was marked as a duplicate of a "how to do X?" question and closed.
I've also had plenty of good experiences on StackOverflow, so YMMV, but in general I've found other forums better.
Well, that's strange, because what they do is still divining. They try to divine "what you actually wanted", even though you asked another thing.
Even worse, a lot of the time the one doing the asking has explicitly said "I know this is unorthodox" or "just answer how to do Y please, don't give me your 'better' options".
It's especially annoying when what you what to do is hack something (and not do it the official way), bypass some restriction that absolutely prevents X, try an alternative style, push the envelope, or generally think Y is better even though the "conventional" sheep-like answer is "do X".
An example of the latter would be trying to use Java with simple POJOs and lite patterns in ~2005, and everybody suggesting you go through some monstrous J2EE setup with half the GoF book thrown in instead because that's "idiomatic".
Or e.g. trying to ask about trying to use a regex to quickly parse some known-quantity HTML where regex will work just fine (say, extract all href out of all a elements), and everybody insisting they lecture you on proper html parsing instead, not caring about your use case.
Regex doesn’t work fine even on that. You still need to tell apart actual tags from contents of attributes, comments, uninterpreted contents of <script>, and so on. A regex alone doesn’t give you the ability to do that. If you want to parse HTML, you need a parser. Simple as that.
Like, I know "<div.+>.+foo\s+([a-z]+)" will work, because I've crafted it for a specific site whose sources I've seen.
Most of the time it works just fine for my purposes.
And it's not like I don't know alternatives. And I've written a toy compiler in the past (C with classes subset), done heavy XSLT work, know how to write a parser (manually, with flex/yacc, with PEG), have parsed XML with SAX, DOM, XOM, have used xpath expressions, css and jquery selectors, and used libs like BeautifulSoup.
Most of the time a quick regex will do just fine for that purpose.
See, I don't intend to send the href's to the ISS or to some medical equipment that will blow up if, god forbid, I accidentally found an A tag in a comment or inside a script or attribute.
And I'll probably run another regex or simple editor or awk filter to get rid of some false positives and I'll be fine.
>If you want to parse HTML, you need a parser.
That's a tautology, so it's always true.
If on the other hand you just need to extract some information from an HTML file, and you can just open the bloddy file and see its structure and it is perfectly servicable with a regex, you might not need a parser at all. Simple as that.
What possible question could you have for an online forum?
After being burnt by a person who never wanted to do anything in a conventional, well-supported way* and kept making that explicit request, I have given up volunteering my time to appease them.
At work I get paid to say "I know a couple of ways of doing that, but if you could tell me more about your problem and the constraints, I can give a better answer."
*Problem: router and three laptops need to be networked. Conventional solution: ethernet cables or wifi. Requested solution: IP over serial (SLIP or PPP) over USB-serial connectors. Had not purchased USB-serial adapters.
That's fine and completely fair. Just don't provide unasked for answers as an alternative.
Then don't make them devine, outline your X in a short sentence.
Ignore those who still divine.
Listen to those who tell you that Y is really hard, but to solve X, you can try Y' instead.
Nobody is making them devine, they do it themselves and pat themselves on the back for reading that XY problem article and spamming XY "answers" everywhere.
I've never asked a question on Stack Overflow, but many, many times I have entered a question into a search engine, received a Stack Overflow link with my question at the top, and been greeted with several screens full of text none of which is an attempt to answer the question.
In other contexts Stack Overflow's conventions are set up on the understanding that they're trying to produce a curated database of questions with their answers, rather than acting as a technical support forum for individuals. It's a real shame that culture doesn't extend to dealing with this case properly.
(The most common case is where the question is something like "does A provide a function for doing B?" and the correct answer is simply "No".)
I strongly disagree. The base assumption is to take it at face value, and therefore should be to answer it that way. The recommendation that comes after is always the optional part. You're wasting everyone's time if you give the Y only, and optionally the X.
The irony here is that the only divining happening is assuming that I should be doing Y when I specifically asked for a solution to X.
What you're proposing also requires me to divine all the ways that people will say "Don't do X, do Y." and explicitly state how I don't wish to do Y but really just want to accomplish X.
"I'd like to accomplish X. No I can't do Y1 since E1, no I can't do Y2 since E2, ..., Y_N since E_N. Please just stick to X."
It would be better if people just stuck to X in the first place, instead of doing all this divining. It also makes it really frustrating for others who share problem X and search for solutions to problem X, only to get people solving problem Y.
IMO both Y should be answered as well as X should be discussed. Why can't an answer have both? The frustrating part is when Y is never to be found on the answer thread.
+ 1 on your username :)
A. You can't ask "what's the best way to do X" because, for whatever reason, these kind of questions are not aligned with "the site's scope".
but
B. When you ask something specific, you get a lot of "it's better if you do X" answers. I even have had some really nice questions closed because some mods thought I was "asking the wrong thing".
Both behaviors are allowed and encouraged ¯\_(ツ)_/¯.
them: how can I do Y?
me: you can do A, but you're probably going to run into B, I'd recommend doing C instead because D
them: ok, well, I'm already too committed to Y, so I'm going w/ A. Thanks!
them, later: hey, I ran into B. Can you help me?
me: ...
At that point, I just accept that sometimes people need to get burned to learn their lesson.
There are also cases where people ask how to do Y, but explain that it's not an XY problem because such and such reasons. These often actually turn into stimulating conversations because now you're in brainstorming territory and it's clear that the conversation is about procuring novel solutions.
Don't take the actual problem and pretend it is an easier one you know how to solve just to look smart and/or helpful.
However, at least in the case of stackoverflow, you're getting advice for free, even if it's occasionally unhelpful. You aren't entitled to an answer.
Beep Boop. Insufficient funds. Insert card to continue.
Or perhaps treat other people like humans instead of an answer vending machine?
If you came to learn something you failed if you respond like that to someone trying to help. Hope it was worth it.
I don’t interpret this to mean: I’m entitled to your answer.
That being said, I appreciate answers of the form: “here’s how you do Y. If you really just wanted X, you can do this instead”
for example, a question treating other people like humans: "hi. I need to get the last two letters of a string in Javascript. can anyone help? thanks" is likely to attract a bunch of curious types of 'why do you need to get the last two letters of a string?' type answers, versus posting something deliberately robotic seeming: "javascript: get last 2 letters of string" immediately gets replied with no-nonsense answers from people wanting to drop their knowledge and get stack overflow green checkmark points for being the fastest answerer etc.
Whose time was wasted? For the asker, the exploration of Y and the eventual realization that it is not a good way to pursue X is a learning experience with value. For the answerer, they may feel their time is wasted if the goal is to answer questions. But if the goal is to help the asker deepen their understanding then the discussion of Y isn't wasted time at all.
This presupposes two things: 1. The asker must have the curiosity and humility to interrogate Y as their chosen method to reach X. 2. The answerer must set aside their ego in order to provide genuine help instead of patronizing advice.
The question/answer format of Stack Overflow does not lend itself to curious exploration of questions and I think the gamification aspect rewards egotistical answerers. I say this despite deriving a lot of value from SO over the years.
Is that how "TFA" is used now?
The time spent on the interaction between asker and those who answered to actually get the asker to provide context and outline his X.
If the asker had done this right from the start, instead of making the answerers guess, then the goal to help the asker deepen their understanding can be reached much more quickly.
From the perspective of someone asking for Y, I've often been a victim of this because I'm met with a slew of imagined X's -- X0, X1, X2, ... an unending list of problems, often more complicated than Y -- due to their narrow preconceptions, making the whole exercise of asking someone not worth the time.
From the perspective of someone being asked for Y, yes, often I can suspect that there might be some mis-matched X there, but in order to be helpful, I try to answer Y directly and honestly, and then point out my concerns, describing my presumptions. If, indeed, the one posing the question has jumped to some invalid conclusion Y from X, then I've given them all I can. Trying to pre-empt it by telling them "don't do that!" is pointless -- if they knew where they had made an unwarranted conclusion, they wouldn't be asking the wrong question to begin with.
I may have confused this with the "Source 2" linked from the article:
http://mywiki.wooledge.org/XyProblem
In its examples, responses include an immediate "Why?" non-answer, an angry "ASK FOR WHAT YOU WANT!", and the observation "Literal answers to bad questions can be dangerous" from one presumed non-noob to another.
I have ben asked countless times to explain the problem, and in practice problems are harder to explain than attempted solutions. I once spent a long time explain the architecture of a multiserver supervisor dæmon manager because they insisted when I was looking for a rather simple answer regarding unix domain sockets.
The actual problem often requires an explanation of the entire design strategy of the software at hand, which is often much.
This works fine as long as Y actually does have a simple solution. Often it does not, and already the question for Y is really weird, but once you hear about the X you can give a quick and simple answer.
That said, sometimes X is really really complicated. But even in that case it'll help anyone you are asking if you quickly outline X in a short sentence, just so the one you are asking has enough context.
(I have been on both sides, but more often then not the simple X was missing from questions was really strange Ys. Though I also have asked for Ys (and even outlined the X) and have been annoyed by people who insist that I should do something else, and describe my X in more detail, but when I do, they can't answer either, because the X really complicated and Y actually was a valid attempt at solving it).
At work, I have to go from team to team for some issues, and we're special (yay) because we're an acquisition, so we're doing some very odd things by corporate standards. Even the fact that we have a customer facing application is unusual, and I've essentially renamed our API to be "BackendForFrontend" entirely because each new team assumes our API must be entirely developer facing.
What I've found is it's tremendously helpful to always link back to (and quote from) Jira issues so the necessary context is present whenever I'm asking questions. Whether it's Jira or Confluence, you want to treat problem resolution the way you do development: it's a permanent thing you're building. And I mean permanent, if you solve a problem, you do a write-up for future you.
Because the method really does depend on what you want to do. Can I destroy the mountain? Do I have to recreate the geological structure, or is it the biosphere you're interested in, or perhaps there is a holy place on that mountain that is important? And so on. If you want me to think outside the box (and presumably the question is posed to test that skill), then you have to be willing to provide more details on what you ultimately want.
And if this is "just interview question", the literal answer is "I don't want the fricken mountain moved to France, I just want to this exercise in hypothetical done with and you're not making it easy on me"
An interview works both ways. If you can suss out the interviewer's nature and help you determine it's not a place you'd want to work, then trust that impulse.
What I find very frustrating is when I ask a question, and get an "answer" that doesn't actually answer my question.
The suggestions here are fine. Still, I think it's more important that the responder have some empathy and be willing to go back and forth a bit to understand someone's problem instead of expecting the asker to guess what information the responder is going to want.
Also, what's with the name "XY problem"? If "asking about Y when you want to do X" makes it an "XY problem", couldn't any problem involving any two things also be called an "XY problem"?
Yes, it is often the case that the person has the wrong idea of how to solve X, but this does not always say something about the validity of problem Y. Often times knowing how to do Y is valuable for other contexts besides X. We should try to be friendly and make it clear that Y is not a good way to achieve X without downplaying Y, necessarily.
The XY Problem (2014) - https://news.ycombinator.com/item?id=20068686 - June 2019 (158 comments)
Ask HN: What's your favorite technical formulation (i.e., the XY problem)? - https://news.ycombinator.com/item?id=17344147 - June 2018 (1 comment)
The XY problem - https://news.ycombinator.com/item?id=13578522 - Feb 2017 (1 comment)
The XY Problem - https://news.ycombinator.com/item?id=10023882 - Aug 2015 (70 comments)
The X-Y Problem - https://news.ycombinator.com/item?id=52486 - Sept 2007 (1 comment)
In my experience, people who have proven fairly to themselves that they're in an odd situation can prove it to others pretty easily. "I'm not doing $Z because..."
In those async situations it's best to provide bits of information for both directions every time, in person it's usually best to collaborate.
Conversational environments certainly make it easier to root cause them, but it's often still painful.
Here is one real question I got in an interview: How do you efficiently sort a table containing a million record in JavaScript?
My question was "in the front end?"
And my answer was it's probably not a good idea to sort that much data in the front end since the user will most likely not be able to consume that much data. Since it was an interview, I explained how to sort the table anyway.
Sorting in the backend makes sense, but even then using a database is more efficient then doing it in JavaScript.
If this question was on SO, I'd probably answer: You shouldn't do that in the front end, explain why. And of course they will get pissed for not answering how.
For instance, if I was making heavy use of local storage where I have no back end, it is nice if that question is already answered. At that point I don't really care if the previous user got a better method, that's what I need to do now.
They ask you about building Y, maybe even Z but they don't want to give X away in case someone steals their 'disruptive product'.
There is too little information to go forward, too little trust. Project doesn't take off.
"the world wasn't ready for X, anyway", they say. Whatever that was.
- What’s the root cause of the problem?
- Is this a solution looking for a problem?
As software engineers, part of our job is naming things well and the “XY Problem” isn’t a great name IMO.
That duplicity makes "XY" useless as an analytic tool to improve inquiries. But as a political cudgel to stop inquiries, I think "XY" can be effective. When outsiders are forced to constantly justify and explain themselves in detail, in triplicate, then the price of Q&A will eventually increase to the point where no one wants to ask.
I think a CTO who is uncomfortable with inquiries will find the "XY problem" a much needed mental gymnastic.
Client states they need something like Y, consultants assess the situation, understand they should do X but keeps it to themselves, the parties come to an agreement to solve Y and do so. Client states they need something like X..
By now I know to ask her what the actual problem is right up front.
1. https://stackoverflow.com/questions/1732348/regex-match-open...
Patrons engaged in research show the same pattern and it's important for a librarian to accurately assess what the patron is truly looking for.
"Asking to ask"
(Often coupled with diverting the conversation from a public forum, where it can be useful to others, into a private one-on-one conversation where you suddenly become on-the-hook for solving all of their issues.)
That said, I enjoy giving literal answers to things. Sometimes it's a fun challenge, others I'm just being a smartass, and occasionally it's a teaching opportunity. A few times I've done this to younger team members, then set myself a reminder to check on them to see if they figured out why that's not the best way.