One problem uncovers another

I would hate to try to estimate how may times I have been in a problem solving situation where the resolution of one problem only lead to the discovery of another.

Today has been one of those days – two problems leading to another two different problems.

This happens so regularly that I wonder why I can’t change my mind to expect multiple problems. Whenever I launch into problem resolution mode I always expect there to be a single thing to change to get me to a resolution.

Does that make me an optimist or just naive?

The way we normally launch into problem resolution is to undertake an audit of everything within the sphere of the problem, trying to find anomalies. I call this the Sherlock Holmes approach:

“Eliminate all other factors, and the one which remains must be the truth.”

“It is an old maxim of mine that when you have excluded the impossible, whatever remains, however improbable, must be the truth.”

Holmes was a great one for logic.

The way we normally apply this logic to IT systems is to parallel. We take system that is working fine and parallel it with the one that isn’t. It’s then a game of spot and correct the differences. The challenge here is understanding where a difference is trivial and where it is really contributing to a problem.

The skill in problem solving is knowing which are the important things that need to be changed. There are normally too many differences to change all of them.

I used to work with someone who’s approach to identifying the most important problem was to work on the most difficult to change. If it’s easy it can’t be important was his logic. His theory was, of course, completely illogical but he swore by it.

Back to our friend Sherlock Holmes:

Crime is common. Logic is rare. Therefore it is upon the logic rather than upon the crime that you should dwell.

So how do I decide what difference are important and which are not?

I have a method which I have built up over time. I’d like it to have some fancy name and be able to reference some fancy professor but I can’t. It’s simply the Graham Chastney method:

1. Identify all of the elements in the system.
2. More importantly identify all of the connections between the elements in the system.
3. Do a quick health-check on each of the elements.
4. Resolve obvious health issues.
5. Identify the element where the problem is evident in a measurable way.
6. Identify ‘anomalies’ on elements that are directly connected to the element that is exhibiting the problem.
7. Resolve these ‘anomalies’ first, testing the impact on the problem measures as you go.
8. Go next to the second tier of elements.
9. And so on.

On the way through this process you may resolve many problems but not actually get to the problem which is causing the issue you are trying to resolve.

The true skill is understanding how the element are connected together. Quite often you find the answer to the problem their and then because you discover that two elements that are supposed to be connected aren’t.

Remembers: the connection is more important than the element. To rephrase Holmes:

Problems are common. Logic is rare. Therefore it is upon the logic rather than upon the problem that you should dwell.

tags: problem+solving, logic