faq-database.de

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Pre-Words ======

Someone told you, that you might not telling the orignial Issue, so please read this carefully.

===== Wikipedia =====

 (([[https://en.wikipedia.org/wiki/XY_problem|Wikipedia About X and Y Problem]]))
<WRAP center round info 100%>
The XY problem is a communication problem encountered in help desk and similar situations in which the person asking for help obscures the real issue, X, because instead of asking directly about issue X, they ask how to solve a secondary issue, Y, which they believe will allow them to resolve issue X. However, resolving issue Y often does not resolve issue X, or is a poor way to resolve it, and the obscuring of the real issue and the introduction of the potentially strange secondary issue can lead to the person trying to help having unnecessary difficulties in communication and/or offering poor solutions.

The XY problem is commonly encountered in technical support or customer service environments where the end user has attempted to solve the problem on their own, and misunderstands the real nature of the problem, believing that their real problem X has already been solved, except for some small detail Y in their solution. The inability of the support personnel to resolve their real problem or to understand the nature of their inquiry may cause the end user to become frustrated. The situation can make itself clear if the end user asks about some seemingly inane detail which is disconnected from any useful end goal. The solution for the support personnel is to ask probing questions as to why the information is needed, in order to identify the root problem and redirect the end user away from an unproductive path of inquiry.
</WRAP>

----

==== Stack Exchange ====
 (([[https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem|StackExchange about the X and Y Problem]]))

<WRAP center round info 100%>

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 it
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: \\

<WRAP center round help 90%>

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 \\
</WRAP>

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.
</WRAP>

----

==== XYProblem.info ====
 (([[https://xyproblem.info/|xyproblem.info about the X and Y Problem]]))


The XY problem is asking about your attempted solution rather than your actual problem. This 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.
\\
<WRAP center round info 90%> \\
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 stuck on what they believe is the solution and are unable to step back and explain the issue in full. \\
</WRAP> \\

== What to do about it? ==

<WRAP center round important 90%>
Always include information about a broader picture along with any attempted solution. \\
If someone asks for more information, do provide details. \\
If there are other solutions you've already ruled out, share why you've ruled them out. This gives more information about your requirements. \\
Remember that if your diagnostic theories were accurate, you wouldn't be asking for help, right? \\

</WRAP>


---

# Examples
Example 1
n00b doesn't actually want the last 3 chracters in a filename, he wants the file extensions, so why ask for the last 3 characters? \\
\\
<WRAP center round help 90%> \\
<n00b> How can I echo the last three characters in a filename?  \\
<feline> If they're in a variable: echo ${foo: -3}  \\
<feline> Why 3 characters? What do you REALLY want?  \\
<feline> Do you want the extension?  \\
<n00b> Yes.  \\
<feline> There's no guarantee that every filename will have a three-letter extension, \\
<feline> so blindly grabbing three characters does not solve the problem. \\
<feline> echo ${foo##*.} \\
</WRAP>

== Example 2 ==

If Angela had just started by explaining she wants to prevent others from detecting her OS, this could have been a much shorter and more productive discussion.

<WRAP center round help 90%> \\
Angela: 'nmap -O -A 127.0.0.1' returns some lines starting with 'OS:'. How to change it? \\
Obama: Look in the sourcecode for nmap, find how it figures out the Linux part, then rewrite your TCP/IP stack to not operate in a way nmap can detect. \\
Angela: Yeah, but I don't know about linux system api at all. \\
Obama: Well, nmap's fingerprint is based on the way the TCP/IP stack works, there's no real way except to rewrite the appropriate parts of said stack. \\
Angela: I really need to avoid these messages. Can iptables do this work? \\
Obama: Well, don't use OS detection or version scanning \\
Angela: I want to prevent others from knowing the type of my OS \\
</WRAP>

----

====== Conclusions ======

The X and Y Problem can be fixed, in that way, that you completly tell what you want to do and what you have tried.