What most engineers don’t realize about problem solving

Why read this article? Your solutions are only good as your understanding of the problem. Improve your problem understanding.

Prologue

I am adil rafique. A software engineer with interests in infrastructure and reliability engineer. And personal definition for my work is , If I am doing my job well, nobody should notice that I exist.
The one thing that’s common between you and me is, we have a set of complex problems that we’d like to solve to be productive at our work. Or in other words increase our productivity from mediocre to good by looking at the place we are least likely to i.e the problem statement

A Problem Well Stated is Half Solved.
Charles Kettering

Here are three techniques that I have helped me to qualify and scope the problem statement and its affectees. I would begin with a base problem statement, apply one of the technique and end up modifying, completely rewriting or the leaving the base statement intact until all of techniques are exhausted.

Techniques

1. Rephrasing Goal.
2. Phrasing/Rephrasing Non-Goals.
3. Bird’s Eye View.
4. Reverse the problem.

Rephrasing Goal

Simply put, Find alternative ways to arrive at the goal.
For example, If you are tasked to find the most recurring record in a collection. You can try alternatives like what is the most likely record to recur in the context of that database, is the recurrence function of some other variable like specific time period or how does a database behave when it gets recurring records.

Phrasing / Rephrasing Non-Goals

Defining Non-Goals can significantly narrow down the scope of the problem. For that same example find the most recurring record in a collection. You can challenge and find out non-goals within context or with stake holders. Example of non-goals can be we are not concerned with the fastest search, we don’t need to count the recurrence.

Bird’s Eye View

Identifying the right stakeholder can let you understand the problem and its scale better or will at least give you chance to inquire more from direct affectee.
Ask question like Who is the most likely to be affected by this problem or Who will be remain affected if this problem is’nt solved.

Reversing the problem

In addition to finding the success factor, ask what is most likely to cause failure. For example, If we want to reduce the load time for request, we can ask What is most likely to contribute to load time.

If our best solutions are a function of our understanding of problem, using better problem defining techniques is the way to effectiveness.

“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” — Abraham Lincoln

I will give credit to Lucioano at Litemind for writing this article that introduced some of these techniques. Go read it further for more problem defining techniques that could help in your context.