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 a problem-solving technique where you explain your code or task to a rubber duck—or any inanimate object—and discover the solution yourself through the act of explaining. It's brilliant because it works and is effectively free.

Rubberducking, or rubber ducking, is most commonly associated with debugging in software development but can be applied to any problem-solving process.

The name comes from the book The Pragmatic Programmer by Andrew Hunt and David Thomas. In it, the authors suggest using a rubber duck as a conversation partner to clarify one’s thoughts. This is an accessible and effective way to troubleshoot problems without requiring someone else’s time.

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.

The psychology behind rubberducking relies on how explaining a problem forces you to process your thoughts more clearly, often revealing gaps or errors in your understanding. Here’s how you can try it yourself:

1. Set up your “duck”: Place a rubber duck, teddy bear, or any object on your desk.

2. Explain your problem: Describe your code, logic, or issue to the duck, step by step, as if you’re teaching it.

3. Watch for insights: In explaining it aloud, you’ll often uncover what’s wrong or identify a new approach to solving it.

For example, a developer struggling with a bug might explain every line of code to the duck. Verbalising their logic can highlight an overlooked detail that resolves the problem.

Rubberducking works because it forces you to articulate your thoughts clearly, moving them from abstract notions in your head to concrete statements. This shift can:

• Help you identify assumptions you didn’t realise you were making.

• Mimic the process of pair programming without needing another person.

Rubberducking a problem also reduces dependency on others for problem-solving, making it a cost-effective—basically free!—and time-efficient tool for debugging.

Here are some situations where it’s particularly useful:

• Debugging code: Talk through an error or bug in your program.

• Explaining logic: Test the clarity of your solution by explaining it step by step.

• Learning new concepts: Summarise a concept to the duck to check your understanding (see the Feynman Learning Technique)

• Decision-making: Walk through the pros and cons of a decision.

In software development, rubber duck debugging has become a recognised term for this process. It’s so common that some developers keep an actual rubber duck on their desks to symbolise this practice. Teams might 'joke' about needing “a duck” for the simplest bugs.

Debugging is an integral part of coding, and the rubber duck technique makes it less daunting. By verbalising your thought process, you streamline problem-solving without needing external help.

Frequently Asked Questions about Rubberducking

Nope. While a rubber duck is the classic choice, you can use anything nearby—your coffee cup, a stapler, or even a photo on your desk.

Q: What if talking out loud isn’t possible?

Writing out your explanation or saying it in your head can work just as well. The key is clarifying and articulating your thought process.

Q: How is this different from pair programming?

Pair programming involves working alongside another person on the same task. Some people swear by pair programming, and to be honest, I've always found it effective whenever I try it. However, rubberducking is a solo activity where the act of explanation itself is the solution.

Next time you're stuck on something, grab a rubber duck and give it a try.

Rubberducking is similar to the empty chair technique for psychotherapy, which involves speaking to an empty chair as if addressing a person.

It's also easily confused with "rubbernecking," which is slowing down to look at an accident as you drive past—a common cause of traffic jams.

What is Rubberducking? An Explanation of the Rubber Duck Debugging Technique

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