Steps to solve or approach towards a solution

Question

Please share your experience about how do you approach towards a solution or solve a problem. Include description about what ever tools you use,sources you follow,algorithms you choose etc.

It would be great help in moving further and works as a guidance too.

Answer 1

Well, I don't think I'm going to be able to get into all of the steps, but step 1 is pretty much always the same for me - Figure out the problem I am trying to solve in as much detail as I can. Once I have that, I can start breaking it down into parts that are relatively easy to think about/solve and then apply the tools and algorithms that make sense for each of those parts.

Sorry, but this question would be similar to asking an auto mechanic how he fixes cars. There are so many books, tools, diagnostic methods, etc, that he isn't going to be able to give you an answer in anything that will fit an answer textbox.

I think the best method for learning this process would be to simply try - that is the biggest benefit of schooling and such, you have your project assignments where you slowly start building up experience with being given problems that gradually increase their scope/complexity.

Answer 2

Read How to Solve it.

How to Solve It suggests the following steps when solving a mathematical problem:

1. First, you have to understand the problem.
2. After understanding, then make a plan.
3. Carry out the plan.
4. Look back on your work. How could it be better?

The books by Edward de Bono also cover approaches to problem solving in general.

For solving algorithmic problems, The Algorithm Design Manual provides a great reference to classes of algorithms and the reasons for using them.

Answer 3

Here's my general approach to solving any problem:

1. Identify what does a solution look like here. Is it just knowing a number, building a system, or something else? In high school algebra the example here would be, "Let x be the value of..." type of statement at the beginning of the solution to the word problem.

2. What do I know that may be useful in getting from where I am to where I want to be? To continue the algebra example, getting an equation from the problem description is this step.

3. Taking what I have in the first two steps, how can I combine these to get an answer? Work through the problem here and get solutions.

4. Do I need to provide additional evidence to this answer? Are there trade-offs for using various approaches that should be noted? Do I want to be making the decision of which solution to use here or should I defer to another authority?

5. How do I state the answer properly given the context?

This is of course very high level since the problem could be as simple as, "What do I want to eat for dinner?" or "Which route do I want to take to go home?" to trying to solve those grander challenges like "Why am I here?" or "How do we fix modern health care?" that aren't so easy to solve to my mind.

Answer 4

Although it is meant specifically and very concretely for programming, I'm tempted to mention the steps involved in test driven development (TDD) here. Basically three steps, repeated over and over until the problem is solved:

1) Define the first (or next) minimum requirement needed before your problem is solved, and find some way to measure or check that this requirement has been met.

2) Do the minimum amount of work needed to meed this newest requirement. Don't worry about it if each step seems insignificant or totally obvious - just do what needs to be done, whether it is actual problem-solving, or just removal of an obstacle in preparation for it.

3) Evaluate and verify that you've come one step further. Now start over.

Although simple, I find this to be an interesting way to attack problems, and it can (depending on the problem, of course) be quite effective. I suppose it forces us to do one of those great things most of us all learned as children, but soon forgot: Redefine the problem into smaller parts, and solve those individually (aka. "Divide and conquer").

Answer 5

Divide and conquer. For any task that will take more than X units of time it is possible to divide it into smaller tasks. Identify them. Rinse, lather, repeat.

Obviously, X units of times varies depending on the overall size of the problem and the experience of the developer.

edit: Sample problem taught after some programming 101 lessons: Count the number of 'a' letters in any given word.

At first all newbies get stuck on that new problem. They probably have done some problems involving loops, maybe even traversing a word. Or probably not. But they need to figure out some things:

• that they will need a counter variable to store the final number of 'a's
• and to increment that variable when they found an 'a'
• so they need to check letter by letter if it's an 'a' or not
• beginning at the beginning of the word
• and checking every letter until the end of it (or maybe the traverse the word backwards, but that would be odd for a newbie)

Of course, they won't find all of the subtasks at first, but they should be able to found a few. They may start working on them ("hmmm I think I need an int counter = 0;..."), and continue thinking and eventually they get closer to the end and finally complete their task.

If someone can't find any subtask to begin working on, they will not ever be a programmer (or at least a successful one).

And with more experience, you are more used to that way of thinking and can solve bigger things easily. At the end, it's just a matter of learning gradually and gaining experience.

Answer 6

I divide problem solving into two general categories of problems: problems where you already know in your head what the solution is and you have to implement that solution, and problems where you have little to no idea what the solution is.

An example of the first sort of problem would be "We need a web application to keep track of our various projects. Solve our problem." An example of the second sort of problem would be "We found a bug that causes the program to crash. Fix it."

In both cases my problem solving technique would be to take a series of small steps. In the first case I would know in advance which direction to move in, so solving the problem will be more straightforward. I might not know (in fact I almost assuredly won't know) exactly what steps need to be taken, but I'll know what direction to take and so I can plan out the project.

In the second case however my problem solving approach would be much less straightforward, investigating starting from known generalities and gradually getting more specific in order to zero in on the solution. Basically take one step and hopefully that step reveals the next step to take; if not, try a different approach and see if that turns into a path. Experience and familiarity with the problem space will allow you to take better guesses about what steps are likely to lead you to a next step, but overall it's a trial-and-error process that you can't really plan out.