Can you share your secrets or best practices for Problem Solving?

Question

I heard that Kent Beck who leads XP used so many color pencils to stimulate his brain when he needed to solve the problem. I tried Kent's method and it really worked for me. I don't know why. Do you have any special method to attack hard problem? I really want to learn about your great secret.

---

Summary: People recommends following things:

• Do something else: go fishing, take a walk,
• Talk to the other people: Break problem into pieces Code review
• TDD
• Experience
• Repeat & Repeat
• Focus on understanding what the problem is

Thanks a lot

Answer 1

1. Write a unit test
2. Watch it fail, then make it pass
3. Repeat until the problem is solved

Seriously though, just keep adding layers of abstraction until things 'just work'. If I'm in over my head I just ask someone smarter than me how they would solve the problem.

Answer 2

Well I can tell you what not to do:

Coming up with solutions with your non-IT manager in the board room 5 seconds after the problem is recognized while talking with the client in a conference call :)

Answer 3

Experience.

---

Seriously, what kind of answer do you expect to your question?

There is no kind of algorithm which will allow you to solve all kinds of problems.

Be exhaustive, explore every option, remember what you learned, re-use what you know, consider other options, ask people you know, google for it, remember what you've learned, re-use what you know, be creative, be chaotic, remember what you've learned, re-use what you know, think outside the box, prod the problem in an odd direction, remember what you've learned, re-use what you know.

Answer 4

I redefine over and over again. And again. Then I break it into the smallest chunks that I can.

When coding I use many variables and don't do more than one step on a line. If I have to add five numbers and multiply then get a percentage I'll do each step on it's own line.

Later on, after I know I've got it I will combine lines together, but not until I'm SURE that the problem is solved.

This helps when debugging, too, since I can inspect each step to know it did what I wanted it to do.

Answer 5

I generally don't start coding right away. I break down the problem, and take notes on it until I get to a spot where I know what I need to do in terms of code. I use emacs org-mode files and occasionally pen-and-paper depending on the type of problem.

Spending a bit thinking about the problem before I put any actual code down generally leads to me writing a much more elegant solution than I would have otherwise.

Answer 6

I switch the computer off, get the rods out and spend a few hours fishing.

It's an amazing activity for clearing your mind and worrying at those niggling problems. The best thing is, the fewer fish you catch the more problems you can work out!

Answer 7

maybe these are things to consider too:

1. do the annoying tasks first
2. do not repeat yourself
3. know when to stop
4. review your code with a co-worker

Answer 8

Often it's best just to describe the issue to somebody. Half the times I ask an expert the answer comes to me in mid-question. If there's something I only half-understand and I try to explain it to somebody else I end up understanding it fully.

Just go ahead and talk about it.

Answer 9

My best trick is to stop working behind the computer. Make a cup of tea, walk around a bit, perhaps take a stroll. If it's a tough problem, explaining it to someone else and discussing the issue helps me a lot. If it's really hard: stop working on it, and focus on something else for a bit.

I think the most important thing is to get your brain to relax and allow yourself to be creative. Those colored pencils are a way to stimulate your creativity (should try that myself, sounds great!); the cup of tea (or @Martin: fishing) is a way to relax. Some of the best ideas in history were discovered while taking a shower, btw :)

Answer 10

Before:

1. Read everything you can find about the problem domain.
2. Don't skip topics that you think won't be relevant.
3. Repeat step 1 and 2.

During:

1. Split large problems into the smaller tasks.
2. Define your fitness criteria (write the tests).

Ater:

1. Do a post-mortem of the solution/project.
2. Try new languages, learn new techniques.
3. Practise, practise, practise.

Answer 11

To me your question can be taken two ways. One is how do I create the solution to a programming problem and the other is how do I solve a problem that exists (ie debugging).

Programming:

1. Don't think about implementation, yet.
2. Make sure you have all the information that you need.
3. Start breaking the problem down into pieces. I use an outliner for this. Currently using My Life Organized.
4. Don't worry about solving the whole problem. Start with what you know and keep it simple to begin with. I use PDL to describe the solution.
5. After you have completed a pass, keep going back to 2 and repeat. Using an outliner I can keep increasing the level of detail and easily move these details around as the solution becomes clearer.
6. If there are pieces of the puzzle that you don't have the answer for, add that to your outline and describe what the next step would be to solve that piece. It may be more research, talking with someone, or getting more details from the users.
7. Go back to step 2 and repeat until you have your solution described.
8. Implement your solution in your language of choice. You can probably use the outline as comments.

Debugging:

1. You need to do your best to understand what is really happening.
2. Compile a list of what you know to be true (facts).
3. Do your best to make it repeatable as easily as possible.
4. Come up with your best approach to attacking the problem (consult with others, google, etc.)
5. Try your approach to fix the problem.
6. If it fixes it, then see if you can break it again, and then fix it for real. Helps you prove you really understood and fixed the problem.
7. If it doesn't fix it, undo your changes, and go back to step 1 and repeat

After a few iterations you should completely understand the problem and know the best solution for your situation. There are times when you just can't get it. It's good to step away, sleep on it, and be prepared to attack it fresh. Definitely talking it through and showing your issues to others can help you better understand the problem and get fresh ideas.

Answer 12

Obligatory references:

Conceptual Blockbusting, by James L. Adams

How to Solve It, by G. Polya

and maybe even

Mind Performance Hacks, by Ron Hale-Evans

Answer 13

Three words: Test Driven Development

Answer 14

For me it depends upon what the problem is - if I am working on trying to solve a new problem, odds are the first thing I'm going to do is either find a white-board and start sketching out some concepts, or find a notepad and start sketching out some concepts. Usually, to solve a problem I first have to understand what the problem is and why it is a problem, once that is out of the way things move on to coding and the usual processes associated with coding.

Debugging on the other hand, is an entirely different issue. When debugging I usually try and figure out what is going on in the code (i.e. step through it and watch variables), figure out what it is intended to be doing, and try to fix it. Usually, there is a "step out of the room and get something to drink" between each of those steps as well. One trick I have found with debugging is to try and stay calm, and if that doesn't work, ignore the problem for awhile and work on something else. Most of the time it takes longer to solve the problem though dedicated - stressed - work then it does by taking a break.

Answer 15

For problem solving I've got the following steps ingrained in my head.

• Question - Find out what the real problem/question is. Alot of times it is pretty vague or obfuscated.

• Facts - Get everything you know to be a fact straight and figure out what the unknowns will be.

• Picture - Draw pictures I use my whiteboard all the time.

• Strategy - Figure out the different ways you can solve it and decide on the best choice.

• Answer - Get an actual solution via the chosen strategy.

• Check - Verify that your solution is solving the problem with the given facts.

Answer 16

so many answers ....

try looking up meta-cognition! There are loads of techiques to aid problem solving.

the simplest that I have found is called the "problem solving wheel" look that up on google.

there are also psychology based stuff to try gestalt psychology the main popular one from them is understanding the "ah ha" moment when a problem becomes a solution

Answer 17

Based purely upon experience and when I get my best revelations/eureka moments:

• Take a shower
• Lie in bed, trying to fall asleep

Answer 18

I tried Kent's method and it really worked for me.

I'm guessing it's because you could see the problem from two different perspectives at the same time, at least subconsciously.

As a general approach, I tend to think about what the eventual solution would have to do.

MSN

Answer 19

I have found that often times it seems difficult because I didn't really fully understand the problem. By going back to the real user/customer and listening to him describing what he really needs rather than reading a requirements document I'm often able to reduce the problem to something trivial.