The Problem With Solving Problems

As engineers we pride ourselves on problem solving. That’s what we do. However I find the use of the word problem to be somewhat problematic (pun intended).

When we use the word problem, typically we are referring to something that is not working. Often it was working, but for some reason, it stopped. Our job is to come in, figure out what went wrong and fix the problem so that the system works again. Think troubleshooting a loose connection or a software bug or something similar. The issue is that when we solve a problem we simply return to the previous state where everything is working. It doesn’t really advance the system, improve our process, or move things forward and typically doesn’t prevent the same problem from occurring again.

So when you are in problem-solving mode it seems like you are constantly playing whack a mole. You are obsessed with putting out the latest fire. You are way too focused on the immediate problem at hand. If your house is on fire you should drop everything and put it out immediately. But if it keeps happening, perhaps you should examine why and resolve that instead. Instead of viewing the issue as a problem, we need to view it as an obstacle to be overcome.

Problems versus Obstacle

Whereas the word problem has a short term, more immediate, implication, the word obstacle is different. Obstacles aren’t solved. They are overcome. An obstacle implies that there is some path you are trying to follow. Overcoming the obstacle puts you further along that path. It leaves you in a better state at the end: a step closer to your goal, whatever it may be. if you need some inspiration about overcoming obstacles, check out this book.

Turning a Problem into an Obstacle

Turning a problem into an obstacle is really simple. You only have to ask yourself one question: How do I not just fix the immediate issue but prevent this from happening again? When you find the answer to that question and overcome the obstacle, it puts you in a much better place than simply right back where you started.

An Example

Let’s look at an example as it applies to coding. Let’s say you are in charge of maintaining some software that you have already shipped to your customer. They call up and report a bug. What do you do?

If you are simply in problem solving mode, you dive right in. You troubleshoot and debug to find the bug and then immediately fix it. You do a quick test and then ship them off the new build. Other than fixing that specific bug the software is in no better state. There is nothing in place to keep that bug from coming back. The person fixing the next bug might not understand why you made the change you did and simply undo them causing the problem to reappear.

How would you approach this bug as an obstacle? The simplest way is to ask: How do I prevent this specific occurrence of this bug from coming back? If we are working methodically, we should probably write a unit test on the existing code that catches the bug. Then when we fix the bug we’ll know it’s fixed. Also, now when someone else works on the code, they’ll notice if they reintroduce the bug because the unit test will fail. Obstacle overcome. Now our code is in a better state because that particular bug will no longer be an issue.

We can add layers to this by asking better questions, like: How do I prevent similar bugs from occurring in my code in the future? If we’re trying to solve that obstacle, we would look at the code that produced the bug and figure out a way to write a VI Analyzer test that would catch it. Now our codebase is in an even better state because similar bugs will get caught before we ship them.

We can take this even a step further and ask how do I prevent bugs from ending up in my shipping code, period? While that is an obstacle that can never be completely overcome, we can greatly improve the state of our codebase by trying. In addition to all the other steps we have mentioned, we can measure and improve our code coverage for our unit tests. We can also automatically run all our tests using continuous integration, so that developers never forget. These steps leave our codebase in a much better place than simply solving the problem by simply fixing the bug.

Got a problem that keeps recurring? Need help turning it into an obstacle that you can overcome to move your business forward? Let’s talk about it.

I didn’t come up with this idea on my own. I got it from a business group that I am a part of called 3to5 club. If this article resonated with you, be sure to go check them out.