The XY problem in civil engineering
The XY Problem is a term that’s pretty common in the software development world that I would love to import into the civil engineering field. I think it’s a helpful framework to ask better questions and solve problems more effectively, especially since civil engineering is a field that uses a lot of complicated, purpose-driven software.
What is the XY problem
I should back up a bit and explain what I mean by the XY problem, since it’s a term a lot of folks probably haven’t heard of.
The XY problem is when someone asks a question about their attempted solution “Y” to a problem and doesn’t include information about the underlying problem “X”. I really like how the problem is summed up on this Stack Exchange post:
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.
I’m pretty adept at software and computers, so I’ve often served as unofficial tech support at work. Sometimes, it’s pretty obvious when someone is having an XY Problem issue, but sometimes it’s not obvious. This is a trap that’s pretty easy to fall into, and I’ve seen it trip up both junior and senior engineers.
An example
Here are an examples of the XY problem that I’ve run across lately (all names are changed to protect the innocent)
Person A: How do I make something transparent in MicroStation. (This is the “Y”.)
Person B: You can set the transparency with the button on the toolbar or in the object properties.
Person A: I set the transparency, but it didn’t make a difference. (This is a second “Y”.)
Person B: Make sure you have transparency turned on in your view settings.
Person A: It’s still not printing right, now I can see what’s underneath the transparent items. (This is a third “Y”!)
Person B: —Hold up. That’s what transparency means. Why are you even using transparency? It shouldn’t be used except in rare circumstances.
Person A: I got a markup on plans to make all the drainage structures print gray. (This is the “X”, the actual problem trying to be solved.)
Person B: Oh no, I hope you didn’t edit the drainage structures reference; that will make it print transparent for everyone, not just you. To print in gray, you just have to change the logical name of your reference…
In this example, the original problem was making the drainage print gray (“X). The question asker had three other questions that were red herrings and caused Person B to give incorrect advice that didn’t actually solve the problem (and in fact caused some other problems, editing other people’s reference files can really mess up an entire plan set).
Here’s the alternative universe version of the above dialog:
Person A: I got a markup on plans to make all the drainage structures print gray. I want to change the transparency on the items, but I can’t find where to set that.
Person B: Oh, you probably want to change the logical name on the reference instead. If you set the transparency, you’ll affect all the plan sheets and not just your own, The pen tables are set up so that the logical name sets all the print styles.
Some things to notice:
-
The question includes the context and underlying problem “X”
-
The question also includes the “Y”. Sometimes “Y” is actually correct. Even if it’s not, it still gives helpful information for the person answering the question.
-
The answer helps the question asker know why “Y” was the wrong track, and the reasons that the other solution is better. That way the next time Person A has this issue, they’ll be able to get farther themselves.
The XYZ problem
A more insidious version of the XY problem is when someone doesn’t ask for help, uses a ‘Y’ well enough that it fixes the problem but causes Z issues down the road.
One place I see this is when multiple people are using Microsoft Word. Word is pretty intuitive at first glance, but has a ton of features that make editing documents less error-prone.
A simple example is pressing enter a bunch of times to make a heading appear at the start of the next page. This is pretty fragile since if you edit any of the text above that point, you’ll either have to add or remove the line breaks to move things back where they belong. Instead, Word has tools such as page break before and hard page breaks that make it a line of text appears at the top of the page.
Avoiding the kludge
There definitely is a balance that needs to be struck between two competing goals: problem solving and learning how to find answers yourself, and learning how to do things optimally. In my experience, it comes down to paying attention. If there’s something that causes issues over an over again, or if you ever find you’re saying to yourself, “I just need to find a way that works,” you may have stumbled on a kludge.
A lot of engineers are really good at solving design problems but aren’t super experienced with software. You don’t know what you don’t know, so if you haven’t spent a lot of time with a program, it can be difficult to realize when there should be a better way to do things.
A lot of times, the XY problem leads to a kludge. Merriam-Webster defines one as:
kludge (noun): a haphazard or makeshift solution to a problem and especially to a computer or programming problem
Engineers are used to putting together makeshift solutions to things, but eventually the technical debt starts to creep in.
Takeaways, and how to ask a good question
Here are some of the tips to avoiding running into XY problems.
1: Stop and think about the actual problem you are trying to solve.
Whenever you run into an issue with computers or a program, it’s always a good idea to stop, back up, and try and identify the actual problem you are trying to solve.
2: Give context when asking questions.
When getting help, make sure to identify all the bae problems you’re trying to solve and how you are trying to solve the problem. That’ll make it easier to get the answer that you’re really looking for. Just make sure not to go into too much detail and lose the plot!
3: Ask if there are better ways to do things.
If the process you’re using seems inefficient or error-prone, it may be worth checking with others to see if they know a better way to do things.
Pay attention to things that annoy you and those moments where you think to yourself “there’s gotta be a better way to do this.” Maybe there is and you just need to find it!
5: Keep an eye out for XY problems when answering a question too.
When someone’s coming to you for help, keep an eye out for the XY Problem too! If you’re more familiar with a tool, you may be better equipped to know if someone seems on the wrong path.
For example, in the MicroStation scenario I outlined above, the very first question should have set off some alarm bells since transparency is rarely used in MicroStation. At that point, Person B could have asked some more questions about the underlying problem instead of just giving a simple answer, and it would have led to finding the right solution quicker.
Go forth and avoid the XY Problem
Hopefully, you found this post helpful. Avoiding the XY problem can save a lot of heartache, so keep an eye out for it!