(Fantastic) XY Problems and How to Avoid Them

Have you ever come across a question that makes you wonder what was the purpose behind it? Maybe something like this:

Do you know the regex to achieve this? https://dev.to/new => /new

(To be honest, I don't know the answer of this question off the top of my head, anyone?)

Due to my weak regex game my curiosity, I would instead ask, "What's the context?". Without a proper context, it would be hard to define the solution. Does the regex have to include query parameters? How about URL hashes? What's the level of the depth of the URL? Is it the current page URL or simply just any URL? And so on.

If the context is about the current page URL, URL.pathname can be used instead:

// When the URL is "https://dev.to/new"
window.location.pathname // Returns "/new"

If this was indeed the context, we all learned that the regex was never needed in the first place. Who knows if the context was never provided, a wrong solution would have been presented instead. And time might have been already wasted.

From what I understand, the aforementioned example a simplified case of an XY problem. In summary, it is when a problem is trying to be solved with a fixed solution at hand, nullifying the rest of the possible (maybe better) solutions, while ignoring the context of the problem in the first place. I used to think that this was a classic problem that only happened in the past, where in fact this is pretty much common nowadays, even outside of the programming use cases.

Take some more (extreme, hypothetical, maybe fantastic?) examples:

• An office will be providing winter coats for their employees due to the freezing air coming from the air conditioners; shouldn't they be asking why the air conditioners have to be that cold in the first place?
• All pull requests without any tests will be closed automatically by a bot due to the alarming decrease of the test coverage percentage; shouldn't the devs be asked as to why they didn't write the test in the first place? Or isn't there a better way to do this, maybe block the PR from merging instead?
• Developers will be required to write their initials as a code comment right above the code they modify, due to bugs happening in production and no one to attribute the bugs to; I mean, sure, but don't we have git blame for that? Or maybe services to track errors in deployments and point out the breaking version? Shouldn't the QA/code review process be improved instead?

I hope none of these are relatable. If we look at it this way, the flaws of these solutions are so obvious that it is impossible to miss them. And the fact that no other solutions are presented should throw you off from the very beginning. But when it happens inside a meeting room, filled with people that have the same level of context (or the lack thereof), it might not be that obvious, and a not-so-well-thought-out solution might come out as the result.

If you (or anyone) are about to solve a problem and you would like to avoid XY problem, regardless of whether it's a programming problem or any problem in general, I would suggest to try these steps before solving them:

1. Take a step back and observe the problem once more.
   Regardless of whether you already have a solution or not, get as much context from the problem as you can. Consider all cases that are required to solve the problem. One way to see if you've done enough due diligence for the problem is that if anyone asks any questions about the problem, you have the strong answer to it already. If not, note that down and continue observing the problem.
   If you have no solutions at the moment, present these contexts right away. At this point, they should have all that is needed to formulate a solution. Maybe you could already try StackOverflow or StackExchange. If this is about decision making and you have some ideas on the solution already...

2. Think of not just one, but multiple solutions.
   It's okay to have a favorite solution, maybe it's something that you are already an expert of, or something that you prefer in terms of the implementation. However, it is important to be fair to the rest of the people that are involved in the process (also, to the rest of the solutions). Come up with more than one solution so that there is something to compare with. If you can't think of anything, that is fine, as long as you're being up front about it. With enough context, you could initiate a brainstorming session instead, to explore the rest of the solutions.

3. Weigh in all the pros/cons.
   Ranking all the solutions by pros and cons would make the decision making process a whole lot more efficient. This would put the good ones in the spotlight and eliminate the bad ones, instead of having to randomly check each solutions one by one. And also, pros and cons have to be validated on all aspects: resources, effects on performance, maintainability, long-term support, I think you get the idea.
   Sometimes, this process could tell if the solution candidates are truly legit, instead of one favorite solution and an intentional mix of bad ones. If what happens is the latter, this is a sign of a bad brainstorming session and repeat step 2.

4. Be open ended as much as possible.
   Last but not least, it is important to remember that you are not telling people to agree with you and solve the problem using your favorite solution. The whole process is to find a solution to the problem. It is never about about who is right or whose solution is the best. So, keeping it open ended is essential; the only aspect that is fixed is the problem anyway, not the solutions.

I know that this topic may have been brought up quite often, and I was actually inspired by this jolly good article (you should check it out if you haven't), and this concept is nothing new. I'm jotting it down as a reminder to myself, and also to share with others that aren't too familiar with the topic.

If you've seen XY problems in the wild and would like to share yours, do let me know. And if there's any feedback about the article, let me know as well. Thanks for reading my article.

Cover image by Pierrick VAN-TROOST on Unsplash.