Solving The X/Y Problem
Published 10/19/2015
Today, we discuss the X/Y problem. Don't know what the X/Y problem is? You definitely should. Be sure to listen in!
Other discussions about the X/Y problem:
- http://www.perlmonks.org/?node_id=542341
- http://xyproblem.info/
Today's episode is brought to you by OneMonth!
Head over to OneMonth.com/developertea to get started learning Ruby on Rails in just...one month, and receive a limited-time 25% discount!
Transcript (Generated by OpenAI Whisper)
Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell and today I'm going to be talking to you about the XY problem. What is the XY problem? I'm not talking about algebra. I'm actually talking about an issue that we as programmers face every single day, probably. But before we get into the show, I want to thank today's sponsor, OneMonth.com. If you are wanting to learn to program or even if you're not wanting to learn to program, you already know how to program and you want to learn something new, maybe iOS or perhaps you're starting a business and you want to do something like a growth hacking seminar, you can check out OneMonth.com. OneMonth provides incredible resources for people looking to learn these kinds of things. We'll talk more about OneMonth later on in the show. But first, I want to go ahead and jump into this discussion. The XY problem happens when you have an issue, some kind of problem you're trying to solve. My favorite one. One that I've seen so far is the example of trying to get the file extension off of a file and you can't seem to find the solution that pulls the file extension, whatever the code is in Ruby or something. You can't seem to find the thing that pulls out the file extension. So you ask the question, how can I get the last three letters from a file's name? This is a secondary way of approaching the problem because, you know, a lot of, file extensions are three letters long. And if I can just manage to get the last three letters of this, of this string, then I will, I will have the file extension. So this, this presents a few issues. The real problem that you're trying to solve the X in the X Y, the X problem that you're trying to solve is I need to get the file extension of a given file. Now the Y problem that you have decided to solve instead is entirely. Separate from the X problem. If you're trying to get the last three letters of a file name, that is not actually the spirit of the problem that you're trying to solve. And this becomes a real issue when you try to articulate your problem to another person so that they can help you solve it. This, this happens in IRC chats all the time. It happens over Slack at whiteboard sometimes. And it even happens in person. You ask a person how to do Y when you're asking them to do Y. And you're like, well, I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't actually trying to do X. As it turns out with our file extension problem, you wouldn't be getting the file extension with the last three characters every time. Anyway, some file extensions are four characters. Some file extensions are, you know, significantly longer than four characters and some are even less than three characters. So you're not adequately solving the problem anyway by solving Y. Now, beyond the fact that solving Y isn't directly solving X and sometimes is an inadequate approach, a lot of the time solving X is as easily or more easily done than solving Y. I'm going to take a quick sponsor break and then we're going to come back and talk about how to avoid the XY problem and how to deal with it when you see it coming up around you, how to deal with it, especially if you are in a management position and you are getting questions that seem to be on the Y side instead of the X side. We'll talk about how to avoid the XY problem and how to ask better questions and how to get to the root of what you are trying to do. I talk about learning all the time on this podcast and this episode is no different. Learning is an incredibly important part of a developer's career. And if you want to learn how to do something in one month, it's kind of hard to do that on your own. And that's exactly what onemonth.com helps you do. If you want to learn Swift for iOS in one month, you can build an iPhone app with Vimeo. With Swift on iOS in just a month. If you want to learn how to build a Pinterest style website with Rails, you can do that in a month. You can learn Python, web security, programming basics. And especially for those who have been waiting to learn jQuery for some reason, or you have not been exposed to it yet, one month just released their new course on jQuery. And you can get started right now and you get 25% off your first month. Normally it is $36.75, or $74.25 per month for the unlimited plan. But if you go to onemonth.com slash developer T, you can get 25% off of that price. Go and check it out, onemonth.com slash developer T. Thank you again to onemonth for being a sponsor of the show. So how do we solve this XY problem? Or rather, how do we avoid falling into this XY problem where we are trying to solve X, but we instead, we try to solve it. So I'm going to show you how to solve this XY problem. Do Y in order to solve X. Perhaps it won't surprise you that we should start by stating exactly what X is. In our file extension example, we should start by stating that our intention is to get the file extension from a given file name. But sometimes it's a little bit more difficult to describe exactly what X is. Sometimes it's a bit more elusive. So how do we describe X well? First of all, we need to know what the file extension is. So we need to know what the file extension is. We need to provide context. What is the actual problem we are trying to solve? And the way we do this is by escaping the jargon if possible. In other words, if we have, for example, a user class that has a first and a last name defined on that user class, we should start using the words first and last name instead of referring to it as the kind of the classical data structure name of string. Providing this context allows us to look at the problem rather than the proposed solution to the problem. Let's say, for example, that you are trying to create a method on the user class that returns the initials of a given person's name. When you state this problem, you should use the terms initials and person and name rather than saying that you want some arbitrary method that takes a number of strings as arguments and returns the first and last name. So we need to know what the first letter of each string is. And the reason for this is because sometimes people have a very simple way of understanding the intention of the problem that you are trying to solve. Now, in that particular example, describing that method in that way would get you to the solution that you need. But even in this example, it is far easier to explain your intention by saying you want a method that returns a person's initials rather than going through that entire long spiel about a method that concatenates all of the first initials of an arbitrary number of strings. The other part of this particular problem is that you may be ignoring the fact that the person has a middle name. Or you could be ignoring the fact that a lot of the time when you see a person's initials, if they also have a title like doctor or junior, that needs to be included as well. So actually stating the real semantics behind the issue is a lot easier than saying, okay, I'm going to go through this and I'm going to go through this and I'm going to go through this and I'm going to go through this and I'm going to go through this and I'm going to go through this. So the first step is to understand the issue that you're trying to solve is important to solving that issue holistically. So escape the jargon, escape the programming talk if you can, and talk about the problem as it exists in reality to some extent. Okay, so number one was unsurprisingly state X instead of trying to solve through Y. This is kind of the obvious solution. State X with all of the semantics and all of the meaning behind it. Number two is explain your process up to this point. So if you're trying to solve through Y, you're going to have to explain your process up to this point. So if you're trying to solve through Y, you're going to have to explain how you got to what you're trying to do up to this point. It is likely at some point in your career as a programmer, you will think that you are trying to describe the X problem. And in fact, you're describing the Y problem and explaining where you are coming from, the things that you have tried to do and explaining kind of your intention throughout the entire process that helps uncover where you are. That helps the person who's trying to help you determine exactly what you're trying to do. And that's the first step. So if you're trying to solve through Y, you're bringing your evolution from the evolution of evolution to evolution, bringing evolution from validate these emails? Well, that programmer should take a step back and look at what you're trying to solve. The reality of what you're trying to solve is that you don't want somebody signing up with a fake email. Now, you could solve this with regex, but you could probably more accurately solve this by taking a step back and saying, how can I make sure that this person is actually who they say they are and is actually behind this particular email address? And once you look at that problem from that perspective, then you can solve it in many different ways. Perhaps the most efficient way would be to send an email to that person and make them click a link in that email that validates that they received it. So in this scenario, you were convinced that the X problem was I need to validate the format of an email. But the reality was that you needed to validate that the email was real. And these are two different problems. So avoiding the XY problem, it really comes down to being more articulate and being more thorough with explaining the problem. We've brought this quote up before on the show. It has been attributed to many different people, but a well-defined problem is most of the way solved. And if you can define the problem well enough so that other people can understand the full context and your intentions, then you can avoid the XY problem. Thank you for watching. Thank you so much for listening to today's episode of Developer Tea. Thank you again to onemonth.com. If you are looking to learn how to code, or if you're trying to start a business, especially in the software industry, and particularly if you want to learn jQuery, go and check out onemonth.com slash developer tea. They just launched their new jQuery course. If you use that link in the show notes, you can get 25% off your first month on onemonth.com. Go and check it out. Thank you again for listening to the show. I have two things for you before I go. Number one, I want you to go to spec.fm. Of course, you will have to go there for the show notes anyway, but there are other podcasts that I want you to check out on spec. And there is a ton of content that we are constantly putting out on spec. So go and check it out, spec.fm. Number two, please go and leave a review for this show on iTunes. It is so important for the longevity of the show that you leave reviews because it helps other people just like you find developer tea. Thank you so much for listening to this episode of the show. I'll see you so much for listening to today's episode. And until next time, enjoy your tea.