Trying to Solve the Wrong Problem

Some time back, while pulling into a local coffee shop, I spotted a stranded motorist in the parking lot. Per the Texan code of ethics, I was duty bound to walk over and offer my assistance, and in doing so I discovered that someone else had already stopped to help. The motorist was in the driver’s seat turning the key to try to start the car, while the good Samaritan was under the hood in an attempt to diagnose the problem. I could hear that the engine was rotating rapidly when the driver turned the key, which meant that the battery wasn’t the problem. It was at that point that the other gentleman who had stopped to help said to the motorist, “Let me get my jumper cables.”

It was obvious that this car didn’t need a jump start; the gentleman, as well-meaning as he was, was trying to solve the wrong problem. Jumper cables are useful when the battery is dead or the car is otherwise without electrical power, but this clearly wasn’t the case here. I gently suggested as much, but the gentleman replied confidently that he had done this in the past and it always worked. The stranded motorist agreed that jumper cables would solve the problem, so the two of them got to work setting up for a completely unnecessary jump start. Knowing that I had done all I could do to help, I went on about my business, heading into the coffee shop for some morning fuel.

Several minutes later I walked out of the coffee shop with fresh cup-o-joe in hand, and I saw the same car still anchored in place. The jump start, unsurprisingly, hadn’t worked. The motorist was on the phone with someone (hopefully a mechanic or tow truck operator), while the good Samaritan continued peering under the hood looking for answers. Trying to solve the problem of a dead battery – which clearly wasn’t the real problem – didn’t get the car started, and delayed the path to the real solution.

Trying to Solve the Wrong Problem

In my time in this industry, and especially during the past 7 years as a consultant, I’ve seen a lot of cases where jumper cables were used for problems that didn’t require a jump start. In that time I’ve also done my share of this as well.

Solving technical problems, whether that involves building a solution from scratch or troubleshooting or modifying an existing process, is often complicated. There are some recurring simple problems that are almost always solved in the same way – for example, there aren’t a lot of different ways to reset a user’s password – but most problems aren’t that clear cut. When trying to apply a generic solution to a broad group of technical needs, you’ll end up wasting time trying to solve a problem that doesn’t exist. In much the same way that a jump start won’t fix all “car won’t start” situations, you won’t be able to apply the same solution to every “database is slow” report.

Using a solution that doesn’t fit the problem isn’t something that only inexperienced folks do. Becoming overconfident in a fix that usually works in a given domain also leads to this problem-solution mismatch. Don’t let years of experience work against you!

Using the Right Solution

To avoid using the wrong solution, there are a few things to focus on:

• Avoid assumptions. Before assuming something is true, test and verify. This may avoid hours of fumbling around just to find that the problem was a simple and easy-to-find thing (trust me, I’ve been on the losing end of that one).
• Break down the problem into small parts. A problem description such as “the ETL won’t run” is too broad. Logically dissect the parts that contribute to a successful operation, test/verify each one, and you’ll find a more easily solvable (and simpler) problem.
• Read the fine print. Whether it’s a high-priority helpdesk ticket or a lengthy statement of work, be sure to familiarize yourself with the details of the need. Don’t stop reading after two sentences to tell yourself, “I know how to fix this.” Ask questions to get more information if necessary.
• Don’t be afraid to say, “I don’t know”. I once worked with a database developer whose solution to every performance problem was to add indexes. He was a very smart guy, but was terrified to admit that creating new indexes was the only solution he knew. Had he asked for help, those around him could have easily shown him a few troubleshooting tips and potential fixes.
• Document your findings. Help yourself and fellow professionals by documenting the particulars of the problem and the solution. This won’t eliminate the need for future troubleshooting, but it does build a library of knowledge for when things go wrong next time.

Conclusion

To extend the automotive metaphor a bit further, trying to solve the wrong problem is like spinning your wheels on slick pavement: you’re doing a lot of work but not making any progress. Doing your due diligence to make sure you’re applying the right solution to the problem will reduce wasted effort and lead to a faster resolution.