Why is it that you always find the cause of a problem in the last place you look? The correct answer, I think, is because when you find it, you stop looking. This post is a response to a conversation that I had with a manager I work with. We were talking about why people (software developers) take too long to correct software defects. My response was that often it is that they are lacking a problem solving framework that keeps them focused.
In my experience, there are two key behaviors that act to slow down problem solving:
1) Getting Stuck – not knowing what to do next or how to do it. This happens when I don’t know enough about the technical domain or the business domain of the product that I am working on.
2) Rabbit Holing – becoming focused on things that cannot lead to a solution of the problem at hand. This happens when I either don’t know that there are other possible causes for a problem, or I am unable to effectively evaluate the probability of a potential cause, or understand the cost of proving that something is the cause of the problem.
Every IT person needs a problem solving framework specifically to deal with these inhibitors. That framework will ultimately look like a list of questions and proofs that one does to prevent getting stuck or rabbit holing.
Questions are specifically to keep from getting stuck, they can be generic or domain specific, and they are designed as Open Questions – meaning that they generate multiple possible answers. Here are some examples:
They help you think of any possible sources of problems, or other impacts of the problem so that you can discern or observe more information.
Here are a couple of generic questions that I ask when I am truly stuck:
These questions are all completely open ended, and can have many answers. They lead us to potential rabbit holing – by chasing each possibility without prioritization. This requires the construction of proofs – the second part of the problem solving framework.
Here are some preliminary proofs that will start your thinking:
Constructing these proofs, is a simple way of costing the reduction of possibilities – so that I reduce the number of possibilities as quickly and cheaply as possible. It drives the prioritization of our attack. I am going in order of speed of elimination – doing the longest most expensive proofs last.
Why would I do this? I suppose that if I thought that the most expensive proof was actually the most likely cause of the problem, then I might do that first. Unless, as is often the case, then refuting all of the other possibilities is less expensive by far than the most expensive one, then the time required to disprove the less likely causes is time well spent. Again, if the problem is truly time critical, additional resources can be assigned to each possibility to further optimize the time line (at the expense of cost).
Problem solving is a search algorithm. As problem solvers we have to understand how to optimize our search. So many times, I have seen people thrash or enter the spin cycle, because they are doing what essentially a left-to-right depth-wise search. The problem with this approach is that it looks at the first possibility all the way to conclusion, before evaluating any others.
—-
Of course optimizing your search requires information. You need to understand the system you are troubleshooting. You need to understand the problem domain. Individuals who don’t try to remember or are unable to remember the details of the problem domain uncovered in prior problem solving forays will never become more efficient or effective at problem solving.
While today, we have Google, as the institutionalized memory of all publicly known systems and products – and that truly is of significant help, it cannot be of help finding domain knowledge for private or proprietary domains. That knowledge must be shared via collaboration in small co-located organizations, or institutionalized as documentation or knowledge base artifacts in larger distributed organizations.
—-
I have written a few articles about problem solving in the past, you may enjoy reading here.
No Comments