The XY Problem (or X-Y Problem) often comes up in software development or customer support, where someone asks for help to achieve a solution (X) that they have chosen as a way to solve a different problem (Y). Helping with their solution may not help them solve their actual problem if it's not a good approach in the first place.

An example from software development is a person asking how to extract the last three characters of a filename (solution X), because they want to know the file type (problem Y). After helping them do solution X, it still wouldn't solve problem Y as some files have extensions of more than three characters.

Another example is a customer asking for help accessing their online account without realising that what they really want to do has to be done over the phone anyway.

There's art and skill in respectfully answering questions and helping with what's asked while seeking to understand the real goal. And if you're asking questions, providing more context may help others provide better answers.

In development, it saves time and effort. In customer support, it leads to happy customers. In design, it may be uncovering unmet needs.

The name is indirectly from Eric Raymond in How to Ask Questions the Smart Way:

A: If what you want is to do Y, you should ask that question without pre-supposing the use of a method that may not be appropriate. Questions of this form often indicate a person who is not merely ignorant about X, but confused about what problem Y they are solving and too fixated on the details of their particular situation."

Also see a better hierarchy of needs, the metrics onion, challenge and clarification questions, prefer open-ended questions, ask the question at talks, don't fill the silence.

The XY Problem

The bus factor is how exposed you are if key people, perhaps with critical knowledge or skills, were hit by a bus.

Examples might include the only people able to keep a company running, restore a server from a backup, or someone who held the only key to unlock crypto assets of its customers. As a result, many places are set up with, or required to have by investors or insurers, some redundancy — say two experienced developers with knowledge of how a service works — to minimise the risk of a tragic accident also being a severe problem for a company or its customers.

As a metaphor, the bus factor may be helpful to consider without the need for people to actually be hit by a bus. It may be worth thinking through how you might operate if someone was late, missed their flight, was ill on the day, or simply quit. In operational roles, this will often lead to a minimum of two people for each key position if nothing else to allow one to take a break from time to time.

An alternative framing, with fewer fatalities, is 'what if we all won the lottery?' and so decided to go do something else.

Bus factor

Just as mistakes and the unexpected are part of life, bugs are part of software development. In general, the longer the time between when a bug was first introduced and when the bug is identified and fixed the more expensive it is in both time and money.

If you spot a bug as you're writing a new feature everything is fresh in your mind and it can sometimes take just a moment to fix.

If a bug turns up later or perhaps soon after it's deployed you might have an idea of where it might be and track it down fairly quickly.

If a lot of time has passed since a feature was worked on and a bug is spotted or tackled then it might take a fair bit of time to figure out how everything works again before you can fix it.

And if a really long time has passed then, aside from the cost of interrupting what you are otherwise working on, it may not even be clear what was intended by the original code, probably written by others, and there's a fair chance more has been built on top of the buggy code making it more complex and a bigger task to tackle. The only way to solve it may be stepping through and figuring out behaviour slowly and steadily line-by-line.

You could probably replace 'bugs' with 'code' 'problems' or 'mistakes' in most scenarios.

Aside from it matching my experience, Joel Spolsky gives a nice explanation in his classic article The Joel Test.

The cost of fixing bugs

Yak shaving describes how when setting out to do something, you found you had to first do something else, which needed you to finish this other thing, and so on until you found yourself shaving a yak, or equally unrelated activity, to do the first thing you set out to do.

It's pretty frequent in life — tidying your room? — and particularly resonates in software development, where when tackling one thing, you often find yourself fixing something else, which needs you to fix something else, and so on. Here's the ever brilliant xkcd on fixing problems.

Yak shaving features, lovingly polished, in my book Big Ideas Little Pictures.

Here's a brilliant 40s clip of Hal changing a lightbulb from Malcolm in the Middle, classic yak shaving

Early yak shaving features in the song There's a Hole in My Bucket in which fixing a bucket requires straw, which requires a knife to cut it, but the knife needs sharpening, which needs a stone, which is too dry and needs wetting with water, which needs fetching...with a bucket

The first I found of yak shaving was a short article on productivity in the first issue of Make magazine by Danny O'Brien and Merlin Mann.

Yak in the style of Alison Green and Adam Stower's excellent children's book, What can you Stack on the Back of a Yak?

Yak shaving

Rubberducking is the simple technique of explaining your code, or whatever you’re working on, to a rubber duck and, in the process of explaining it, finding the answer yourself. 

Have you ever been called over to someone’s desk to help them solve a problem, and as they explain the problem to you or demonstrate it, they figure out the answer themselves? It happens all the time to me, particularly when someone's showing me how something doesn't work, and it magically works just by having me watch over their shoulder. The rubber duck technique is as simple as that, except that instead of calling someone over, you can simply replace the person with a rubber duck, teddy bear or heck, even your stapler.

Rubberduck debugging is a term from software development where this sort of scenario happens a lot. Rubberducking is surprisingly effective and way cheaper than hiring a contractor for the day.

There is also the related empty chair technique for psychotherapy.

Rubberducking is not to be confused with "rubbernecking", which is slowing down to look at an accident as you drive past—a common cause of traffic jams.

Rubberducking

Smaller software releases generally means fewer bugs, and bugs that are easier to fix. The number of bugs created typically increases with the complexity of interactions of code, which in turn increases with the size of release. This means that a number of smaller releases can hopefully get you to a large change in a safer way with less bugs, and less problematic bugs, created along the way than a single release with the whole lot. There’s probably a somewhat more general relationship with amount of unexpected problems created and the size of any change.

Bugs and releases

I love this diagram by Henrik Kniberg for determining what to release to your customers and when.

The idea is that a standard approach of having your grand plan of what you think people want at the start and then working on each bit at a time until finally, after months of work, you have something that works is not so smart. Each piece, in the car example, doesn’t help the customer at all until it’s all put together.

Instead, you can focus on providing the next piece of functionality that helps someone get their job done a little better than before. In the beginning, they’ll probably have to put up with a lot if they want to use it, but with each successive release, they find they can get their job done a little better than before and get value out of what you’re building. A side-effect is the feedback you get along the way will likely help you learn and build something that is better than what you had in mind at the beginning, and all along the way, the customer had some value instead of waiting for months.

Providing usable functionality at every step is not always easy, and it requires rework as you move from one step to the other. But it’s generally a price worth paying to give your customers value sooner and start learning as soon as you can.

This diagram is explained in the brilliant product management book User Story Mapping by Jeff Patton.

A release strategy for happier customers, sooner

Idempotence is essentially an operation that, no matter how many times you do it, you’ll still get the same result, at least without doing other operations in between. A classic example would be view_your_bank_balance being idempotent, and withdraw_1000 not being idempotent. It’s a property that’s often handy as you can retry the operation without worrying about unintended effects.

Idempotence is a concept from mathematics and computer science but can be applied more generally. For example, simple on and off buttons are idempotent, a property that can be very useful in emergencies.

Idempotence

I learned about this nice principle from agile software development. Basically, that when thinking about how much you’ll get done next week, what you got done this week is a good proxy. Sure this week was different because you had that external presentation and an offsite, a bug to fix on live and Amy was sick. But the reality is things will interrupt you next week too. Just like the weather, what happened before is a good first guess at what will happen next.

Coding sketches