Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 153 Stack Exchange communities.

What is meta?
Here's how it works:
  1. Any Stack Exchange user can ask a question
  2. The community provides support, votes on ideas, and reports bugs
  3. Your voice helps shape the way Stack Exchange operates

What is the XY problem?

When asking questions, how do I recognize when I'm falling into it? How do I avoid it?

Return to FAQ index

share|improve this question
See a PerlMonks post on the same subject. – ikegami Jul 31 '13 at 19:34
sad example of the XY problem:… disclaimer I'm biased there, being the one claiming spotting X instead of solving Y – Tobias Kienzler Aug 16 '13 at 9:12
I have heard this problem called “premature closure” in a logic course. However, searching the internet for this phrase shows it more commonly means suturing a surgical incision too soon. – Dour High Arch Mar 23 '14 at 23:24
Folks who know the answer to a problem ask X, like teachers on a test. Mere mortals tend to ask Y. The XY problem is a dance between post-er and post-ee. – chux Nov 4 '14 at 16:04
It seems (only) a specialized case of the "wrong hypothesis behaviour" (described bellow). – Peter Krauss Mar 9 '15 at 13:12
wanted to sleep with X, married to Y – Bhojendra Nepal Jul 8 '15 at 8:53
Important counter-case: There are problems, that, would they be explained, would take forever, and always end in getting lost in there… never even getting to actually thinking about the problem. In that case, describing a sub-problem and using an analogy is the proper solution, and the “XY problem” (what a stupid name) is invalid. But the analogy has to be perfectly transparent. Otherwise one ends up in the XY problem again. – Evi1M4chine Aug 8 '15 at 12:44
I'll dub the opposite as the 'YX problem'. You post looking for a specific answer. World decides that since they don't know the answer to your question, it must be the wrong question. A herd of 'why are you doing this?' comments are birthed. World subsequently decides to instead help you fix your broken brain-logic and your clearly fragile emotional state. – Code Bling Aug 12 '15 at 18:38
@CodeBling You obviously left out the possible outcome: User is driven up the wall for getting deemed "weak-brained", shouting curses (worse: expletives), at the same time cursing "the awful support in this forum" and/or "the hostile forum regulars", ideally bellowing a warning their way like "I will warn all my friends to never register on this forum! I've had it!!111" eventually leaving the scene while loudly slamming the (virtual) door. – syntaxerror Jan 31 at 21:03
@syntaxerror you got it – Code Bling Jan 31 at 22:17
up vote 841 down vote

What is it?

The XY problem is asking about your attempted solution rather than your actual problem.

That is, you are trying to solve problem X, and you think solution Y would work, but instead of asking about X when you run into trouble, you ask about Y.

The Problem

This can lead to frustration by people who are trying to help you solve the problem because by the time you ask about it, the solution that you need help with might not have any obvious connections to the problem that you are trying to solve.

How to Avoid

To avoid falling into this trap, always include information about a broader picture along with any attempted solution. If someone asks for more information, or especially a more specific question, do provide details. If there are other solutions which you believe will be suggested and which you've already ruled out, then don't try to avoid going over them again – instead state why you've ruled them out, as this gives more information about your requirements and helps others provide better answers.

An Example

A recent IRC conversation for illustration:

<Q> Is there a function to return a string between two delimiters?

<B> i don't understand what you mean, but i doubt there's already a function

<C> split and slice

<D> partition too

<Q> I tried partition
<Q> I was trying to use built-ins to get the number between something like this in a string "attribute1: 50.223, attribute2: 442.1"

<D> why not just parse the string?

<Q> I thought there may have been some built in parsing stuff

<D> pairs = [x.strip() for x in s.split(",")]; attribs = {k: v for x in pairs for k, v in x.split(": ")}
<D> there's a few libraries, but simplistic formats are easy enough -- if you don't care about error handling
<D> changing the source to use a well known format, e.g. json or yaml, is preferred when possible

<Q> This code actually comes from HTML
<Q> but I don't know how to parse Javascript with HTMLParser or whatever it's called

<D> is it merely embedded in html, or some mangled version of html?

<Q> It's embedded in the HTML

<D> if it's javascript (and that is, except for missing outer braces), json can probably parse it

<Q> thanks

<D> I didn't say it explicitly: json only parses data structures, not js code

<Q> That's all I need parsed is a data structure

The problem is really about how to parse JavaScript data structures, not find "a string between two delimiters", yet it takes quite a bit of time and intuition to get to the real issue.

This is easier to do in a fully interactive chat (regardless of what mode), but on a SE site, where you polish a post a bit, post it, and then have 5-30 mins, or longer, before feedback, it really helps to head in the right direction from the start.

share|improve this answer
IMO XY problems are sometimes useful because the answers could help the questioner understand why their solution wouldn't work, and better understand the original problem in the process. – Thomas Jul 17 '12 at 16:26
The easiest way to get to the real problem is usually asking Why five times. – Gordon Oct 21 '12 at 17:25
Although, if you start off with Y instead of X, you may have to ask why 10 times (or more, apply the 5 whys to every level?). :-) – Brian Knoblauch Nov 30 '12 at 15:10
Why Y - that's the question to ask – user93353 Apr 23 '13 at 14:49
Your example is perfect. – Evan Teitelman Apr 29 '13 at 20:15
To be fair, many times questioners ask about X, and the response is "that's too much, break it down to a small example" and so the poster isolates their attempted solution Y and everybody loses sight of the original problem. – Paul McGuire Jun 23 '13 at 23:48
Sometmes you are stuck with Y. In my first job I had to modify a webshop. The codebase was a rotten mixof html PHP and js. There were 2 ways to fix problems: Redo the whole thing (declined by boss) add more tape. SO did not really help me there. "How to y?" "Why would you do that?" "Because I have to" "What is Y / Do not do this/ why are are you using {antipattern}?" "Because I have to" – Oliver A. Jul 9 '13 at 8:46
@OliverA. Then part of the question becomes an explanation of why you need to do Y. "I need to do Y because legacy/boss/old framework" then the question becomes easier to answer, and more valuable to all. – Lego Stormtroopr Sep 4 '13 at 5:59
@LegoStormtroopr Except many people don't understand that. They don't understand that sometimes you don't have the luxury of choosing the right approach and just have to band-aid existing code, and the question is closed as too narrow or something... – Thomas Sep 4 '13 at 23:19
@Gordon Why 93 up votes? Why? Why? Why? Why? – Kris Oct 1 '13 at 6:42
Oliver A. is totally right. One cannot expect to have an perfectly isolated question, because there is a lot of conditioned situations. Ussualy when you dominate the topic, the answerer raises immediately and got the solution. Sometimes, the problem is in X format. Sometimes, in Y format (the inverse approach). Both, if well formulated, are appropiately made to offer a solution. Obviously is it totally easy for the answerer to have the problem formulated in X format, but, as obviously you also can figure, not always a questioner will find an ussualy answer from the X format. Good topic though. – hypfco Oct 14 '13 at 21:50
I made solid attempts to boil all of my questions down to as much of a "Y" as possible. I have no interest in spelling out the entire scope of my issue (especially when working on closed-source proprietary software at my job), and I feel like (excluding dealing with those who insist on traversing up the chain with "why? why? why?") I can get an answer faster by encapsulating my questions off from all context. – n00neimp0rtant Feb 14 '14 at 17:07
It depends on the asker's overall knowledge of the problem space. I agree with n00n, for those more experienced with the alternatives, they may have already ruled out all the possible X's, and now X is a constant, and they just want to solve for Y. It detracts from the question to have to go over all the possible X's that you've already ruled out, and delve into office politics or existing system architecture. Someone less experienced might benefit from having other's review alternative X's and suggest they reconsider that precondition. – AaronLS Mar 20 '14 at 13:48
The counter-example: Me: Is there any way to change the current directory in Java? Other: In java you don't need to do that. What do you want to do? Me: (sigh) OK, I have an executable jar for a program that listens to a port and exchanges messages. The jar normally sits in x/bin and the configuration sits in x/conf. So, the program reads its configuration from ../conf. Now I want to run that within a tomcat server by calling the program's main method myself. But I have no control on the server's home directory and "../conf" is not an acceptable place. – Florian F Oct 27 '14 at 22:34
(cont) So I wonder if there is any way to change the home directory for one thread. Other: Oh, I see. Well, you can't do that in Java. Me: Why couldn't you tell me that earlier? -- In that case, I asked question X and I was answered question Y (how to use files in Java). – Florian F Oct 27 '14 at 22:35

The X-Y Problem, as it is sometimes called, is a mental block which leads to enormous amounts of wasted time and energy, both on the part of people asking for help, and on the part of those providing help. It often goes something like this

  • User wants to do X.
  • User doesn't know how to do X, but thinks they can fumble their way to a solution if they can just manage to do Y.
  • User doesn't know how to do Y either.
  • User asks for help with Y.
  • Others try to help user with Y, but are confused because Y seems like a strange problem to want to solve.
  • After much interaction and wasted time, it finally becomes clear that the user really wants help with X, and that Y wasn't even a suitable solution for X.

The problem occurs when people get their train of thought stuck on one approach and become unable to take a step back. Remaining open to having a new look at the bigger picture, these people might find their way back to X and continue searching for alternative solutions.


share|improve this answer
@Emrakul I think this answer does a better job of explaining the problem. – cimmanon Jun 13 '14 at 12:07
I also think this answer is a needed addition to the explanation. I read the above, tried to think about my current problem (whether it is an X or Y question), and when I read on to this comment, I got the "aha" moment of understanding that if I would have posted my question, I would have inquired about the Y not the X. The reiteration of my situation could be a mental block focused on how I am solving the problem rather than clearly stating the problem I want to solve is very helpful. – user2421308 Feb 4 '15 at 20:17
I think it is the users' responsibility. I've meet many times the problem, that I wanted to solve the problem X, and everybody suggested Y and Z. But if I had wanted a solution for Y or Z, this is what I had asked. I find this a little bit embarrassing, not only because the answers I get don't belong to my question, but also because I feel myself underestimated. Since that I intentionally miss any details which could mislead my answerers into this bad way. – peterh Sep 8 '15 at 2:02

I'm adding an extra answer as a complement to the excellent answers already present.

An XY problem seems to be a subset of the Einstellung effect, where a problem-solver gets stuck on a particular solution and is unable to backtrack mentally to see potentially superior solutions. This psychological phenomenon affects everyone, novices and experts alike.

An example from Chess would be a person winning with a 5-move smothered mate in one game. The next game, the same player fails to see a faster 3-move mate because they are stuck on the idea of a 5-move mate.

Specific to Q&A, the perniciousness of an XY problem comes from the fact that it is frustrating for everyone involved:

  1. The person asking the question asks the wrong question (which is related to their attempted solution rather than the original problem), and then finds it difficult to clarify the question because they are stuck on their own solution. The proposed answers are unsatisfactory because they don't address how to implement the author's solution.
  2. People answering the question find it frustrating because the proposed solution doesn't make sense to them since they are approaching the problem from a fresh angle and are (presumably) not being affected by the Einstellung effect, and they find it difficult to get the original poster to clarify their question.
share|improve this answer
Hello @JonathanBenn, can you check/comment this opinion below? I think we can also suggest/discuss solutions in this page... – Peter Krauss Mar 9 '15 at 13:19

The Missing square puzzle problem is a good illustration. It illustrates a simple and universal problem/question/solution process, where "some illusion" causes complications.

There are a self-evident problem — the 1×1 hole in that arises on the second figure —, but the solution is evident only after we know (like an Egg of Columbus)... All people, experts and non-experts, agree that there is a problem.

enter image description here

  • normal user: thinks that "there are two equivalent figures, the 'total triangles' in a perfect 13×5 grid...", following with the question:

    • problem Y: "Why the second equivalent triangle have a hole in it?".
  • expert user: think something like "oops, they are similar, but not 'perfectly equivalent' figures", following with the question:

    • problem X: "How to show that they are not perfect equivalents?".

The clever geometry-expert thinks in terms of "similar geometries that aren't perfect equivalents".

The normal user thinks, mistakenly, in terms of exact congruence. So, the use of wrong hypothesis, produce ill Y questions.

The "XY problem" as a specialization of the "wrong hypothesis behaviour"

You want to solve the real question-X, and you think in terms of an Y-context, and try to use question-Y. Instead of asking about context X, you ask about context Y.
(as @Gnome noticed above, but using other words)

So, "XY Problem" is only another (more specialized) term to say "Use of wrong working hypothesis".

share|improve this answer
Please review your downvote, I edited to separate personal opinion from this more generic and perhaps interesting form to explain "what is". – Peter Krauss Mar 9 '15 at 13:00
I get your meaning from your answer and you're the one who answer the question with animated illustration. If my reputation (in this meta community) allows me to vote up, I will vote this up. – user292598 May 17 '15 at 12:50
This answer illustrates a typical use case, when "thinking-imperative programmer" ask a question about functional language... The suggested solution: ask in top level. – Peter Krauss Jul 26 '15 at 11:24

Avoiding the XY problem

I argue that you can't avoid it. Not without simply throwing your program requirements at SO and asking them to do your design for you (not recommended).

I argue this because the design process for all software is based on a starting set of requirements "A". From there you say "I can achieve A if I do B and C". From there you say "I can achieve B if I do D and E and I can achieve C if I do F and G". And that continues to the point we say that "I can achieve X if I do Y". We usually do this so fast we don't even think about the process.

So the major problem with the XY problem is that Y is not possible, but you don't know how much of your design to unwind to get back to the X which is possible. You usually don't even know that Y is impossible without actually asking. You don't know what you don't know. Therefore it is unavoidable

Asking Questions where you risk falling into XY

The best thing you can do about the XY problem is to guard against it when asking questions. Still ask the same question but give as much pertinent information as possible:

  • State your problem
  • State what you are trying to achieve
  • State how it fits into your wider design

This will help people identify that its XY and help you much more quickly.

IMPORTANT: Giving Answers to XY problems

In my opinion the biggest problem with XY questions is the (frequently) unhelpful answers they provoke. We will never stop people asking these questions so the best thing is to understand how we can answer them quickly and effectively.

Ironically a lot of these bad answers and responses are given by those wanting to be the most helpful and can be given by some of the most reputable people on the forum / SO.

I've discovered a method of answering these questions which appears to help get round the psychology associated with XY problems and lead the OP of a question to a working solution. The method takes a little longer to answer in the first instance but closes the Q/A loop much more quickly.

I suggest that you answer the question in three parts and give them in the following order.

  1. Answer the OP's question. Even though the OP probably needs something else, never neglect to answer the question they have actually asked first and not the question you think they want answered. In some cases that answer may be "Y is not possible". Too often I see responses (comments) asking "why do you need that?". This gives the OP nothing. If you say "That's going to be really hard. Explain why you need it we may be able to help" then in a lot of cases an OP will simply take the "Y is really hard" and go back to the drawing board... That's fine because you've answered their question and they may well come back with question X themselves.

  2. Discuss the OP's attempted solution. This bit's tricky and takes some thought. But I can't stress how important it is. If the OP has asked for Y and you think they want X then after answering their question (1) carry on to talking about Y (NOT X). What is Y supposed to be used for? How is it not applicable to X? The crucial thing is to carry on talking about the question but move from answering it to providing helpful information. Because after all that's what you think the OP needs. Helpful information and not the answer to their question.

  3. Solve X This is what you've been itching to do and is the whole point of your response after all. You've met the OP on their terms and answered their question. You've helped them to understand the failings of their question and why solving Y is not the thing to do... so now you're completely justified in explaining a solution to X.

Most people are here to learn so parts 1 and 2 of this answer are as important as part 3. But too often part 3 is given on it's own and it is extremely frustrating and patronising to the OP not to mention a lot of OPs will not accept the answer.

Giving this answer also avoids embarrassment when you think the OP has an XY problem when in fact they don't. All you've done is give a little extra information. Simply giving part 3 risks appearing to have not read the question.

Incidentally. Read the question again and read this answer... notice the three parts?

share|improve this answer
As "XY Problem" is a kind of "Use of wrong hypothesis", the Stackoverflow community must to help in show the right hypothesis... This is the focus in your "Giving Answers to XY problems"? – Peter Krauss Nov 12 '15 at 7:51
@PeterKrauss In a sense. That is more of an assumption (I agree the community should). I assume that someone answering the question wants to give part 3 - the right hypothesis. The trouble of XY problem lies in the wasted time. So focus of this answer is to highlight that spending time giving parts 1 and 2 up front is not wasted time but actually saves time in the long run. You are right that this answer is generalisable to the Use of wrong hypothesis. – couling Nov 12 '15 at 9:05

(separated from my other answer because this one has more opinion than explanation)

If you agree that the "XY Problem" is only another (more specialized) term for "Use of wrong working hypothesis", as illustrated and explained here, and similar to the "Einstellung effect" explained here by @Jonathan Benn

We can think in terms of some main situations:

  • Rush situation: the wrong hypothesis is only a language or over-simplification side-effect, that can be corrected by the user with a little more attention, and investing more time editing the question.

  • Normal situation: as in the illustrated Missing Square puzzle, you do not know that your hypothesis is wrong. This is the main situation to discuss here (!).

So let's put focus on the normal situation.


The "XY problem" is a valid problem!

The Stack Exchange question is to show a problem. If my question helps to show that the real problem is my wrong hypothesis, it is OK! It is a first step, and perhaps I will not need any other questions after obtaining the correct hypothesis (and trying to solve by myself).

Example. See my rushed question about "self axis that fails"; the real problem is that @attribute::self does not exist, so it was a wrong hypothesis on the title of the question.

The help/mcve solution has limitations

Stack Overflow's help/mcve rationale: "How to create a Minimal, Complete, and Verifiable Example", can be used to avoid the XY problem.

But the cost of edit (time and attention expensive), and the perception that it is a kind of pollution in your text (a "bad marketing" for the question), are downsides.

It's correct also to simplify the problem and explain with more focus on the point.

Best practice

Train users of Stack Overflow to check if the simplification makes sense. Algorithm for a good question:

  1. Try to create an MCVE.

  2. If an MCVE is not practical, try at least to simplify.

    2.1. Test, check for inconsistencies, simulate the reader… and review. Does your simplification produce something strange, change the context? Review to avoid errors.

  3. Listen to the comments about your question, and try to clarify, try to work editing the question if necessary: if there are people commenting, it is a notice that you can invest more time in your question.

The wrong hypothesis is not self-evident, but when we simplify, we amplify the wrong effects, and it becomes more evident.

PS: On the other hand, when we explain and show all the details, all the context, and check the real point, the assembly of the problem (like when using mcve), the inconsistencies also show with more evidence.

share|improve this answer
It's my experience that the the MCVE creates more XY problems not less. It makes a more pure abstraction by stripping away the context of the original question. That is the X might be contained within the context of the original question but the MCVE will be constructed solely to express Y. – couling Nov 11 '15 at 23:57
Thanks @couling (!). Yes, as methodology MCVE perhaps is not a "best practice", but is a way to enforce "... explain and show all the details...". Our brain works better after that kind of self-review... You can edit and correct the text, it is a Wiki. – Peter Krauss Nov 12 '15 at 7:39

Negotiating a union contract...

The XY problem is relevant to the difference between "interest" based bargaining (X) and "position" based bargaining (Y).

X = the employee's overall take-home pay has been stagnant for the last several years, while their cost of living continually increases; the employee needs more take-home pay.

Y = picking "you will not raise parking fees" as a hill to die on / the only "solution" to X that the employee is willing to accept.

Aiming for Y (taking a position) is aiming for a very specific and limited solution to the problem (X). It cuts the employee off from from the universe of solutions to the problem (X) by insisting that it only be solved in one very specific and limited way. If that way (Y) is, for whatever reason, objectionable to the employer, then there will be a stalemate -- a period of time where there is no solution to X, where a solution has to be acceptable to both sides.

If the employee can aim for X instead of Y, then the universe of solutions remains open / unrestricted, and the employer can be recruited to help find possible solutions to X. (Maybe it will turn out to be OK with the employee to raise parking rates, in exchange for a cost of living raise...)

This interest/position paradigm seems relevant to asking questions on SO, when OP asks for help making their position work. Sometimes you can cut to X by simply asking: "Why are you trying to do this?"; But I wonder if sometimes, aiming for Y isn't just as valuable. How many of us have ever tried to do something, just to see if we could? Anyone here running their own DNS server with some specific type of software for that very reason? :-) Might not be your best solution to X, but it's still interesting...

share|improve this answer

You must log in to answer this question.