Problem Solving Strategies: Understand the ProblemNovember 21, 2016

Welcome to Rithm's series on problem solving strategies. Here's a list of the articles we've written so far:

Understand the Problem

Explore Concrete Examples

Break It Down

Solve a Simpler Problem

Use Tools Strategically

Look Back and Refactor

One of the biggest challenges for the aspiring web developer has little to do with the details of programming. As an engineer, you'll be tasked with understanding and solving problems on a regular basis; regardless of the specific technologies you use, then, strong problem-solving ability is critical.

And while your problem-solving skills will certainly develop naturally as you write code, it's worth being a bit more intentional, and think about problem-solving strategies in general. In this series, we'll take a look at some common problem-solving strategies, and adapt them to the life of a web developer. (Note: many of these strategies are adapted from George Polya, whose book How To Solve It is a great resource for anyone who wants to become a better problem solver.)

Since this is the first post in the series, we'll start with the beginning of the problem-solving process: understanding the problem.

laptop with postit note

Strategy #1: Understand the Problem

When someone presents you with a problem, it can be tempting to dive right in and start solving. This is especially true in programming, since a fast typer can churn out a decent amount of code in a short amount of time.

But before you start typing away, it's better to take a step back and make sure you understand the task ahead of you. This is especially true during technical interviews: asking questions before you start to solve the problem demonstrates that you are taking a thoughtful approach.

In How To Solve It, Polya describes this phase of the problem-solving process as follows:

First of all, the verbal statement of the problem must be understood. The teacher can check this, up to a certain extent; he asks the student to repeat the statement, and the student should be able to state the problem fluently. The student should also be able to point out the principal parts of the problem, the unknown, the data, the condition. (pp 6-7)

This gives us a few helpful benchmarks when approaching a problem. Here are some questions you should ask yourself before trying to embark on a solution:

Can I restate the problem in my own words?

What are the inputs that go into the problem?

What are the outputs that should come from the solution to the problem?

Can the outputs be determined from the inputs? In other words, do I have enough information to solve the problem? (You may not be able to answer this question until you set about solving the problem. That's okay; it's still worth considering the question at this early stage.)

How should I label the important pieces of data that are a part of the problem?

Asking all these questions of yourself may seem like a lot. But like any other skill, problem-solving requires practice to develop. Over time, if you ask these questions of yourself repeatedly, you'll begin to internalize them. Eventually, they'll just become a natural checklist that you go through almost without thinking about it.

chalkboard and sponge

An Example

Imagine you're in an interview and are asked to do the following:

Write a function which takes two numbers and returns their sum.

Even for a problem that's as straightforward as this, it's worth asking yourself the questions listed above. Let's take a look at each one in turn:

Can I restate the problem in my own words? Maybe something like "Write a function that adds two numbers," or "Implement addition."

What are the inputs that go into the problem? Two numbers. This might seem like an open and shut case, but even here it's worth thinking about the structure of the inputs. For instance, are the numbers integers, or are floats allowed too? Should the inputs even be numbers at all, or strings representing numbers? If the latter, the problem suddenly becomes much harder, because you can represent arbitrarily large numbers with strings. For example,

100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

+ 100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

is a perfectly valid mathematical sum, but if you try to add those numbers directly in JavaScript you'll get an output of Infinity, since JavaScript can't deal with numbers of this size.

It's also worth asking whether the input always consists of just two numbers, or whether it's possible there could be more inputs (or fewer).

What are the outputs that should come from the solution to the problem? One number, representing the sum of the inputs. Here too, it's worth thinking about type: should the output be a number, a string, or something else?

Can the outputs be determined from the inputs? It seems that way, though the answer depends a bit on the answer to 2. For instance, if it's possible that there could be fewer than two inputs, it's not necessarily clear what the output should be if the user doesn't pass in any arguments at all. (Note how we're already finding examples of edge cases, before we've started writing any code!)

How should I label the important pieces of data that are a part of the problem? This is a matter of personal preference, but it seems like there are four things that could use labels: the function, the two inputs, and the output. Names like add, num1, num2, and sum seem suitably descriptive.

Once you feel like you have a good understanding of the problem, it's time to move on to the next problem-solving strategy. We'll discuss this one next time.

A Basic Business Problem Analysis Technique

by Angela & Tom Hathaway | Jul 30, 2012 | Requirements Gathering, Tactical Business Analysis | 0 comments

How does your organization decide which projects to fund? When a project is done, how do you know if it was successful? Business problem analysis is a set of techniques that identify and evaluate areas in which stakeholders are unhappy with an existing situation. These techniques help you understand the business problems and their context sufficiently to isolate the real pain points, manage a problem backlog, establish a basis for measuring success, and initiate basic cost-benefit analysis to help you make the right decision.

Business Problem Analysis:

• defines the scope for projects

• ensures common understanding of purpose of projects

• establishes foundation for funding of projects

• creates basis for development of test strategy and plan

• sells a project to all stakehoders

• facilitates cross-project risk-based management decisions

• avoids marginal-value add-ons

When Should You Analyze Problems:

Ideally, business problem analysis should precede the development of the solution. However, any time decision makers can not communicate what problems the project will solve (regardless how advanced the project is) is the best time for business problem analysis.

Who Should Analyze Problems?

Business analysts, product owners, project leaders, managers, and virtually anyone working on the project need to understand the business and technical problems that the project will solve.

https://businessanalysisexperts.com/basic-business-problem-analysis/

CONFIDENTIALITY / COPYRIGHT NOTICE: This site and my information and any attachments contains the PRIVILEGED AND CONFIDENTIAL INFORMATION of Fred Finkelstein & Irondesigner DBA / LLC mutually, Inc., its affiliated corporations or legal entities, and is intended only for the use of the individual(s) named above. If you are not the intended recipient of this e-mail or invited to this site, or the employee or agent responsible for delivering this to the intended recipient, you are hereby notified that any unlawful interception, dissemination, disclosure, printing or copying of this e-mail or site or any attachments is strictly prohibited under the Electronics Communication Privacy Act (ECPA), 18 USCA 2510, 18 USCA 2511, and any applicable laws. If you have received this e-mail or viewing this site in error, please delete or destroy it & close down, including all attachments or copies, and immediately notify us by e-mail at mechanicalengrg@gmail.com