What's the best problem solving technique you've learned?

I have a pretty different approach that works quite well for me that I learned from my computer design class and it works amazingly well in all manners of discipline. He called his approach design design. As in, we don’t just design solutions to problems, we need to actually design how we design. So the first step in solving a problem isn’t taking an approach like divide and conquer but to actually take the time to really understand why we think there’s even a problem and design the problem. The more time you spend understanding that aspect, the much easier the rest follows.

He gave a real life example of a university that had continually rising enrollment and was running into parking issues, so they hired a firm to build a parking garage. The firm easily could have designed and built the parking garage, gotten paid, and everyone would have been happy, but they first went and analyzed the parking issues. What they realized is that thought they thought they had a problem of insufficient parking spaces, they actually had plenty of parking but were running into issues because of when the classes were scheduled so lots of popular classes were clumped together and running out of spaces then, and other less popular classes were clumped together resulting in tons of extra spaces. So, instead, he suggested a few minor changes to their scheduling and it saved them a huge amount of money on what was ultimately an unneeded parking garage.

So that’s always the very first thing thing I do. I work as a developer and whenever I get assignments, my first thought isn’t “how do I implement this request?” it’s “why do I need to do this?” Often times I’ve found simpler, cheaper, better solutions because the problem wasn’t well understood before a direction was chosen and I was tasked to “solve” it from there.

A lot of good answers here so I shan’t repeat, but two things to add.

If you have a theory about what is going wrong then don’t protect that theory. Someone said something along the lines of…

Also, walk the problem with the people who experience it. Get to where it happens and drink it all in. It may not seem immediately useful but you may spot something crucial that you don’t see at your desk. Also (and more subtly) it lets people see that the problem matters, that you are taking it seriously and you are more likely to get honest and useful input from people.

Here’s something I always try to follow:

  1. Know exactly what problem you are trying to solve.
  2. It is usually easier to solve several small problems rather than one huge one.
  3. KISS (Keep it simple, Stupid).

Sometimes, just making a clear definition of the problem helps to get you thinking in the right direction. My wife is a self-proclaimed technical idiot, and yet she has helped me solve many computer programming issues without actually touching a keyboard or mouse. All I have to do is define the issue in absolutely crystal clear language and just describe it to her. Somewhere along the way, she might ask a question or two for clarification, but by breaking the problem down into its simplest form, the answer typically jumps out.

Breaking a huge problem into a series of smaller problems makes it easier for the work to be spread out and accomplished by teams. Consider the International Space Station. The whole thing couldn’t be launched into space, but breaking it down by modules allowed it to be built and transported with relative ease.

If you arrive at a hugely complex solution, you probably haven’t done a very good job on Step #1. The more complexity and moving parts you have, the more chance you have of things breaking.

Listen carefully to the people that know the problem. Some of my worst moments managing a small factory came when the foreman came in my office and started describing something that clearly couldn’t happen. I quickly learned that more preposterous, the more likely it was that I would go out and find it exactly as described. Somehow, I had to figure what was going on and how to fix it. It was a small enough place I was responsible for both keeping things running and calling people to tell them the delivery time I told them was a crock. I became very adept at solving problems.

I was in one Saturday when we were doing maintenance. I spotted a bunch of crud in the magnetic grate protecting a machine. I gathered some up. Monday I called everybody together, announced we had a problem, showed them the stuff, and asked if anybody knew where it came from. John quickly piped up ‘‘It looks like da color concentrate we were usin last week.’’ I caught myself just in time. Apparently the junk we were working off had magnetic iron oxide as the pigment and actually was magnetic.

Interesting - when did he say this? (I think it did come out fairly well, though you have to mull it over briefly.)

My problems tend to fall into two categories, involving my real life and my creative life.

  1. Real Life:

This is how I pretty much handle my real life problems. I have a tendency to feel overwhelmed, and being an all-or-nothing pseudo-perfectionist means that if I can’t do everything at once, I decide to do nothing.

So one day I remembered one of my favorite childhood novels-based-on-real-life, Cheaper by the Dozen, written by Frank (jr.) and Ernestine Gilbreth about their family and particularly their parents, Frank Gilbreth and Lillian Moller Gilbreth. The parents, particularly the dad (at least prior to his death), were professional time and motion study experts, and Gilbreth Sr. devised a system he called “Therbligs.” It basically involves breaking a task down into nearly microscopic parts, identifying each mini-step along the way individually to figure out the most efficient way of performing these steps. And when I say “microscopic” I mean it; I believe he came up with 17separate “therbligs” involved in, say, shaving. First you search for the razor; then your eye spots it; then your hand reaches out to attain it; then you grab it; then you lift it to your face; then you… well, you get the picture. Therbligs, btw, are named after himself – it’s (roughly) Gilbreth’s name backwards.

This process came to me as I was in a deep trough of depression and unable to contemplate doing almost anything other than sleeping. Just washing and getting dressed before going to work felt like too much. So after coming up with copying the therblig idea, I thought to myself: what do I need to do to make each step in the morning as easy as possible? First, instead of getting up and staring at the closet deciding what to wear, then inevitably have to iron said clothing, I’d put my clothes out the night before. (Like, duh!) I made sure I had nice slippers so it was a pleasure to stand up and scuffle over to the bathroom. (I had a parquet wooden floor at the time and the blocks of wood were uneven, so it was always annoying as hell to bang my foot on one uneven piece of wood. Yes, things were this difficult for me.) I’d put my breakfast out (dry cereal in a bowl, covered with saran wrap, and a banana) the night before too. And so on. It really did make a difference.

The Therblig scheme has helped me during rough patches, though sometimes I don’t practice it as often as I should. In fact one of my cats is named Therblig. (Which I think is the best name for a cat ever.)

  1. Creative Problems (primarily writer’s block):

I’m a fiction writer. The hardest part of this for me has always plotting a novel (or a storyline for my online serial) from start to finish. I’d know where I wanted to start, and where I wanted to end up, but had difficulty with the “in-betweeen” parts. I was planning my first novel (a gothic romance) and was stuck as hell.

Then about ten years ago I read a book on mystery plotting, I think it was one of the Writers Digest books but unfortunately I can’t remember its name or the author. Anyway, it gave me the epiphany I needed:

I had to plot backwards.

Since I knew what the end of the novel would be – the revelation of the mystery of the heroine’s family skeletons – I jotted that down in bullet-point form on at the end of a spiral notebook. Then I turned to a previous page and thought: What would need to happen immediately prior to this final revelation? Well, the bad guy who’d duped the heroine and put her and her love interest in danger would need to get all his victims in one place together. Great! I wrote that down. Then turned to the previous blank page. Okay, so the villain’s about to get everyone together to murder them. What would happen right before that? In order for him to change his plans so abruptly (the original plans being that he would marry the heroine and kill the hero), the baddie needed to discover that his plans were about to unravel, and (since this was a gothic romance to be written in the heroine’s first person POV), this info would most likely come from the heroine herself, unwittingly revealing something that made the baddie realize his schemes were about to unravel. Wrote that down, turned to the previous blank page. How on earth would the heroine find out the damning information, and why wouldn’t she realize just how damning it was? Figured that out, wrote it down. Etcetera, etcetera, etcetera.

Plotting backwards has completely changed the way I plan my stories. Of course it’s especially useful since my books are very genre-bound (romantic suspense or mystery), rather than literary, and they almost all tend to involve mysteries that need to be solved. Mysteries are relatively easy to plot if you write them backwards. You start with the dead body and figure out how it got there, who killed it, how they did it, what steps they took prior to the killing in order to hide their plans, and so on. Then you add all the red herrings to surround the truth and throw everyone off the track.

So… well, I don’t know if this is what the OP wanted, but these are two problem solving methods that have helped me.

Google it. Most human problems have been solved (or at least tackled) by somebody else, somewhere.

Begin by finding out what the problem actually is.

Too often I’ve seen people try to solve a problem by basically throwing solutions at it, rather than start by analyzing it. One extreme case I know of was an accounting problem my Dad had in his reválida (think CPA certification exam), which had more than 20 numbers in the explanation… but in the end amounted to “add two of those numbers”. Students who tried to use every available piece of data had a 0, those who actually read the question got 100%.

Another trick I like is: follow the flow. I used this to leak-chase vacuum systems: is the pump working? Prove it. OK, pump’s working, what about the next connector? Prove it. etc. A computer example: Is the computer running the web site up? Is the web server program running? Is the web server sending data? Is the web server’s network connection working? Is the network connection between the server building andd the rest of the Internet working? Etc., down to your computer. You can work that example backwards as well.

Here again you need to know how your system is supposed to work, how the flow of (air, water, data) is supposed to happen, how to test each point, and so on. But this gives you a logical approach to chasing down where the problem(s) lie.

Or as Deep Trhoat sai “Follow the money”.

I’m assuming you know what the problem is.

Breaking the problem down works very well except when it doesn’t. Doing this assumes you know how to solve the problem, but just don’t know the details of how to solve it. Wirth called it stepwise refinement, and is an excellent way of solving programming problems.

But getting the top level right is often the hard part. I just implemented something which struck me as very complicated - until I came up with a high level technique which let me do the whole thing in about five lines of code thanks to a good data structure. I’m really glad I didn’t proceed dividing up that problem, since my initial solution would have had a lot of pieces.

However the real way I do this is not going to help in AI. It is trusting my subconscious. Damon Knight’s recommendation for dealing with writing problems was exactly this - get all the pieces lined up and then wait for your subconscious to provide the answer. People come up with ideas in the shower since you can’t do anything else. I can’t do that at work - no showers - so I have two better methods. One is reading the Dope. For some reason if I pause, read and post, I’ll have the answer to a small section when I stop. The second is that I keep a journal - in a file - of everything I do, very stream of consciousness. The act of typing a description of a problem and my initial solution leads me both to the right solution and to discovering traps and bugs in my logic before I code. Then I read the Dope, and when I emerge I type a section of code which usually works perfectly the first time.
I don’t know what I’d do if my subconscious was dumb.