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.