The author says this is going much further than the XY problem, but I rather think it's describing in good detail and with interesting insights how to deal with the XY problem
I don't think it's really about the XY problem. It seems to apply to a lot more than the XY problem, and it's not as dangerous as assuming that you (the answer-giver) are dealing with an XY problem. Like, I get what you're saying, but I think that framing it as being about XY problems is going to turn back into the same counterproductive heuristics that people use when responding to questions that look like XY problem questions.
I can't count on my hands and toes how many times I've been trying to get advice but had to argue my way past the peanut gallery to someone who had the energy to Really read the words I was writing because the peanut gallery kept assuming I was having an XY problem. And like it's not just annoying when it happens to me it really makes it harder to solve the original problem. I'm not immune to XY problems by any stretch of the imagination, but I've been redirected by people hallucinating the Y behind my X so many times that I'm convinced that programming culture's handling of XY problems is miscalibrated, and I saw this post as a bit of pushback against that miscalibration.
I think it's really important for programming culture to change how it thinks about things that look like XY problems, and I think that the point the post is making is about that: slow down and don't pattern match, even if you know way more than the person asking the question. It's probably not an XY problem (not OVERWHELMINGLY probably, just generally probably) in the first place, and even if it is, maybe you should treat it like it isn't.
Great read! I liked this post - and it took me back to something I heard many years ago; I think I am going to call it the flipped side of the same coin; which being careful to not replace the question you are being asked with a simpler question and answer that instead. So not answering the first question, you would be also helping yourself to not make this unconscious question switch.
An intuitive example of the problem is this:
Person 1: What's the distance between Amsterdam and San Francisco?
Person 2: That's a 12 hour long flight.
The question was about the distance, but because the knowing the distance is a hard question (in this case you would have to have memorized the distance between the cities), person 2 replaces it with an easier question (how long does it take to get between those cities through air - which is a more common transportation mode for long distance traveling across oceans) and then they answered the replacement question instead.
I see this happen very often - and it seems more common when there is power distance between the person asking and the person answering.
@lalitm, you'll be pleased to know the problem predates the internet and has a name: requirements analysis.
Ed Yourdon among others distinguished between a process, a result the user wants to obtain, and a procedure, a way to obtain it. A process might notify the customer their order has shipped. A procedure would send them that information by email.
Users of a system tend to think of solutions as features of that system. (Programmers aren't immune. That's why there are so many solve for Y in X permutations.) Your job as an analyst is to distill the requirements from any particular manifestation. Then, as engineer, you implement a solution.
Not very long ago I was involved in a discussion about how to make logging faster, because sometimes syslog(3) fell behind and events went missing from the log. That wasn't really the problem, though. No user wants faster logging. The user wants to solve problems. The process is getting him the information he needs. Writing absolutely everything to the log is only one way to do that.
Yourdon was among those who advocated for CASE tools. They might have succeeded if management could measure quality and productivity. But that's a rant for another day.
For a variety of reasons I recently added 404 pages to our ingress router as we modernise a bunch of stuff. This caused problems. A developer came to me and wanted the old 404 behaviour back, because it used to include a navigation bar and a menu.
This made my evil-detector twitch.
Pressed further, it turns out that some customers have a configuration that always results in a 404 when they log in, and they used the old 404 page to go where they actually needed to go.
I invented the lolcry for moments like this 🤣ðŸ˜
codekobold | 8 hours ago
The author says this is going much further than the XY problem, but I rather think it's describing in good detail and with interesting insights how to deal with the XY problem
wareya | 5 hours ago
I don't think it's really about the XY problem. It seems to apply to a lot more than the XY problem, and it's not as dangerous as assuming that you (the answer-giver) are dealing with an XY problem. Like, I get what you're saying, but I think that framing it as being about XY problems is going to turn back into the same counterproductive heuristics that people use when responding to questions that look like XY problem questions.
I can't count on my hands and toes how many times I've been trying to get advice but had to argue my way past the peanut gallery to someone who had the energy to Really read the words I was writing because the peanut gallery kept assuming I was having an XY problem. And like it's not just annoying when it happens to me it really makes it harder to solve the original problem. I'm not immune to XY problems by any stretch of the imagination, but I've been redirected by people hallucinating the Y behind my X so many times that I'm convinced that programming culture's handling of XY problems is miscalibrated, and I saw this post as a bit of pushback against that miscalibration.
I think it's really important for programming culture to change how it thinks about things that look like XY problems, and I think that the point the post is making is about that: slow down and don't pattern match, even if you know way more than the person asking the question. It's probably not an XY problem (not OVERWHELMINGLY probably, just generally probably) in the first place, and even if it is, maybe you should treat it like it isn't.
ucirello | 8 hours ago
Great read! I liked this post - and it took me back to something I heard many years ago; I think I am going to call it the flipped side of the same coin; which being careful to not replace the question you are being asked with a simpler question and answer that instead. So not answering the first question, you would be also helping yourself to not make this unconscious question switch.
An intuitive example of the problem is this:
Person 1: What's the distance between Amsterdam and San Francisco? Person 2: That's a 12 hour long flight.
The question was about the distance, but because the knowing the distance is a hard question (in this case you would have to have memorized the distance between the cities), person 2 replaces it with an easier question (how long does it take to get between those cities through air - which is a more common transportation mode for long distance traveling across oceans) and then they answered the replacement question instead.
I see this happen very often - and it seems more common when there is power distance between the person asking and the person answering.
jklowden | 6 hours ago
@lalitm, you'll be pleased to know the problem predates the internet and has a name: requirements analysis.
Ed Yourdon among others distinguished between a process, a result the user wants to obtain, and a procedure, a way to obtain it. A process might notify the customer their order has shipped. A procedure would send them that information by email.
Users of a system tend to think of solutions as features of that system. (Programmers aren't immune. That's why there are so many solve for Y in X permutations.) Your job as an analyst is to distill the requirements from any particular manifestation. Then, as engineer, you implement a solution.
Not very long ago I was involved in a discussion about how to make logging faster, because sometimes syslog(3) fell behind and events went missing from the log. That wasn't really the problem, though. No user wants faster logging. The user wants to solve problems. The process is getting him the information he needs. Writing absolutely everything to the log is only one way to do that.
Yourdon was among those who advocated for CASE tools. They might have succeeded if management could measure quality and productivity. But that's a rant for another day.
adampetrovic | 4 hours ago
Unless you're the foremost expert on a topic, it can be quite difficult to come to an initial conclusion of a question as being 'wrong'
doctor_eval | an hour ago
For a variety of reasons I recently added 404 pages to our ingress router as we modernise a bunch of stuff. This caused problems. A developer came to me and wanted the old 404 behaviour back, because it used to include a navigation bar and a menu.
This made my evil-detector twitch.
Pressed further, it turns out that some customers have a configuration that always results in a 404 when they log in, and they used the old 404 page to go where they actually needed to go.
I invented the lolcry for moments like this 🤣ðŸ˜
icefox | 5 hours ago