in reply to Re^7: XY Problem
in thread XY Problem

I am primarily appealing in this ... debate ... to history. Until you/someone decided that the ol' "Now I Have Two Problems" (NYHTP) scenario should be classified as The XY Problem, no one ever called it that.

I think you're getting confused by the fact that both scenarios (XY Problem as defined here, and your NYHTP) could be described using X's and Y's. It's true that the same pair of (X,Y) could occur in either scenario, but that doesn't mean the two scenarios are equivalent. For example, someone might ask for help with "parsing nested matching delimiters using regexes", when what they really want to do is parse XML. This would be an example of the XY Problem, even though it involved the inappropriate choice of regexes as a tool.

I shall define both in the simplest, plainest way I can, and then it should be clear how they are not the same at all.

XY Problem:
An engineer has a problem (X), and wants to get help with it. She decides to ask for help with a different problem (Y), because she believes that obtaining a solution for Y will somehow aid her in developing her own solution for X. She has (perhaps unintentionally) hidden her real problem behind a proxy problem.
NYHTP:
An engineer has a problem (X), and decides that a certain tool* (Y) will be useful in developing a solution for X. But Y comes with its own "problems" -- difficulty of learning, using, etc., whatever that might entail. She has compounded her engineering problem through the choice of a certain tool.

Do you see the differences? I can count three or four without even trying.

* "tool" in the broadest sense, of course.

I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.

Replies are listed 'Best First'.
Re^9: XY Problem
by GotToBTru (Prior) on Jan 12, 2015 at 18:02 UTC

    In your description of an XY problem, it seems as if Y may be an unrelated problem to X. I wonder if I can do any better?

    An engineer has a problem X, and (mistakenly or out of inexperience) hits upon Method B as the means to a solution. Applying this method to X results in problem Y, for which she seeks help. Answers that fix Problem Y will continue to conceal the poor choice made earlier. If the questions had been about X, time-tested Method A would have been suggested.

    Dum Spiro Spero

      In asking for help, the engineer is hiding X behind Y, by whatever circuitous chain of reasoning may have gotten her there.

Re^9: XY Problem
by wrog (Friar) on Jan 12, 2015 at 20:10 UTC

    I have, btw, never claimed that your (hyperspecific) XY and NYHTP scenarios aren't different. The question at hand is whether the differences are ones that actually matter, whether there's a point to reserving the term "XY Problem" for the more narrowly defined situations, and right now I'm not seeing it.

    My understanding, and there seems to be at least some agreement on this, is that the essential feature that makes an XY Problem what it is is that of being excessively focused on the use of tool Y to solve problem X, to the point where you might be missing more obvious solutions of X that are right under your nose.

    The question of exactly how you're going about asking for help, that you might be forgetting to mention X at all, is, I would say, simply a symptom, not an essential feature.

    Note, btw, that if one is not actually asking for help, then we're simply not observing the problem. That doesn't make it any less real.

Re^9: XY Problem
by wrog (Friar) on Jan 12, 2015 at 10:23 UTC

    if you're going to appeal to history, then you should just cite one or more sources and be done with it. I.e., who actually coined the term and how did they use it?

    (... it being not entirely unusual to find the original usage turning out to be something quite different from what you might have expected..)

      FWIW, I agree with jdporter’s interpretation completely. And while twisting original usage/meaning is common, it muddies clarity and without a certain level of pedanticism in communications we risk developing things like lawyers.

        Just for fun, a webcomic: http://www.smbc-comics.com/?id=3470 - "Welcome to Technicality Club. The first rule of Technicality Club is..."