The Problem With Solving Problems

Uhhh. What Are You Talking About?

Too often as developers, we think the best and perhaps only way to solve an issue is to, well, solve the issue: to tackle it head on and determinedly diagnose and fix it. But this is entirely the wrong way to approach a problem.

When Solving Isn’t an Option, Make Progress Instead

Most problems can be solved with enough time and effort—but since both are usually limited, we often need to make compromises. That means we have to think creatively. Some problems are opaque and can’t be tackled directly, so instead of focusing on solving them, we should focus on making progress. This opens up more possible solutions.

How to Progress a Problem

The most obvious question to ask when you’re faced with a problem is: “How can I solve this?” That’s a natural instinct—but it can be a misleading first step. A better place to start is by asking: “Why is this a problem? Specifically, how did we come to be aware of it?”. In answering this question, you may find that you exchange a hard problem for an easy one.

We ran into an issue where users were uploading empty (zero byte) files, which caused a service that depended on the upload result to fail. How did we become aware of it? Our alert channel was getting flooded with these errors. While users were somewhat shielded from the problem thanks to retry logic and the chance to fix things on their end, the real issue was on our side—the constant alerts were making it harder to notice real problems. It was messing with our signal-to-noise ratio and desensitizing us to alerts. So even though the uploads were a user issue, the alert noise was a bigger operational problem for us.

The first option for progressing a problem is a little hard to define because it feels quite coupled to the specific scenario we were having. But, I think it can best be summarised as:

1. Ask why this is a problem. Specifically, how did you come to be aware of it?

• This counts as progressing the problem because asking that question might show the problem you think you’re meant to solve isn’t the right one—or not the one you’re best placed to solve.

What is next? Well, we can start with the most obvious, most preferred way of dealing with the problem:

2. Diagnose and solve the problem directly.

Voila. But, of course! I wish I had thought of that. But, we have constraints that make this impossible. Determining the possibility of this can involve more than just a gut check and instead might involve a time boxed investigation to determine if solving the problem outright fits within our available resources.

When direct solutions don’t work, we look for other options and focus on finding ways to move forward.

3. Increase visibility with additional logging

• More data means we can better understand the problem.

3. Improve the user experience around the error state

• How can we make it easier for users to recover from the error on their own?

Great. We have three ways to handle the problem. Anything else? Well, yeah, there is one notable option that is always worth considering. And as much as it seems a non-serious option, it really isn’t. It’s the option to do nothing. We do nothing when any pursuit of other available options is a wasted exercise.

5. We do nothing