Month: November 2005

The Problem Solving ability. Some people are born with it. Others, like myself, learn it over time. For me, it’s a never-ending quest.

When faced with a problem, which might be big or small, it is the ability to break this problem down to the base elements, and then address them.

One of the disciplines needed when solving problems, is that of ‘Test Everything’. Don’t believe what people tell you. Listen, then work it out for yourself. Just because people say it, doesn’t mean that’s the case.

I’m prone to just believing. It’s easier, and you "get along" better when you just nod your head. I do it WAY too much. Sometimes it’s appropriate, when it’s better to actually forge a relationship than the other. BUT … when solving a problem, and I’m specifically thinking about this in terms of a group of people sitting around a table trying to nut out an issue, the Test Before Belief approach is far better for actually getting to the heart of the problem.

Imagine a company who’s IT department has gone through a number of management phases, each of which add their own little unique segments to whatever hardware/software runs the company. Most of the time, these aren’t actually documented. Nothing is ever done about planning the architecture, and if any planning occurs, it’s usually short-sighted.

Then everything goes down … because there is no disparate architecture, the diagnostics are up the creek. How do we tell what element is screwing up when everything is lumped together? It’s a common problem no doubt, and to a greater or smaller extent, everyone in IT will come across in their lifetime.

So how do you approach the problem? Jump in, lightsaber flashing, beating down any and every-thing in an attempt to fix the issue … this might have a certain attraction, especially considering that you will get a reaction. But it doesn’t actually solve the problem. If you restart the servers, the problem might go away for ten minutes, only to regroup and return with greater force than before (excuse the war analogy :)).

The best approach I’ve seen, working with some great minds, is that of the Listen,Test Before Belief, and Break Down To Basics.

1. Listen to what the people who deal with the problem are saying. If it’s yourself, clean up your thoughts, write down something, get it ordered.

   While you’re listening, think about what is being said (or not said) behind their words. And think about the problem … are they actually addressing it? Maybe … maybe not.

   If they’re missing the point, guide them towards it. Ask another question, more pointed towards the actual reason. The questions you ask can be as important as finding the problem. With well-formed questions, you can diagnose the problem with much greater efficiency, and others learn in the process.

2. Don’t believe something just because someone says it.

   It doesn’t matter if the person talking has the smartest brain in the history of humanity, test before belief. It’s not a personal affront to someone’s ego, although it will be taken that way. It’s the ability to see beyond. That if you make assumptions based on people’s words, then you miss the point. The most efficient way is straight.

   There are a lot of things happening when people talk. A lot of different emphases placed on their words. Different aspects directing their talk. If I’m worried about my job, then that will become part of the conversation. I’ll be defensive and make sure what I say covers my behind. I’ve fallen into this many times. You’re worried because you feel that you haven’t been accomplishing as much as you could, and so it’s the first thing that jumps into your mind when someone is talking to you.

   It could be any other reason. Bias is just a part of life … we have to deal with it.

   It took me a long time to deal with, and I still haven’t got it right. On the receiving and the dealing sides.

   So … the third.

3. Breaking down to basics.

   This is where we end up. Instead of getting caught up in the small issues, instead of jumping in without thought, instead of starting a row by treading on someone’s feet while telling them it doesn’t hurt … you get to the heart of the issue. Which can be a few things.

   Break the problem down. How? By asking the right questions, by thinking as they talk, by listening to the answers, the said and unsaid. Don’t get offended if you are the person giving the answer and you get shot down a little … turn your mind to the problem, and break it down yourself.

   Why is it happening? How can I verify that it’s happening. Which part of the system is giving the problem? Hardware/Software/Both? Can I replicate on demand the issue.

   This last is important. If you get into a corner, where nothing seems to work, then create a clean testbed and make the problem happen.

   It all leads to being able to break the problem down into basics, and then deal with them each.

   Much easier.

And there are great side-effects from tackling problems this way. You actually gain direction. Working through a problem also works other things out in your mind. You might come out with the next 6 months planned, and with future ideas. You will want to put into place methods/systems to ensure this doesn’t happen again, and if it does, your diagnostics will be equal to the task.

It’s such an important part of Development (and every other facet of life).

Listen, Test Before Belief, and Break Down To Basics.

Thaks for the time.