Geeks With Blogs
L. Charles Andersen

The first day of the first semester programming class, I introduced the students to the concept that the most important part of building a system, whether it is something physical like a bridge to cross a river or a computer system, is to understand the problem.

Many novice programmers believe that if they are writing code, they are making progress, and if they are not writing code, they are wasting time.

The problem with that mindset is that, to be making progress, they must be writing the correct code correctly. They cannot possibly know if they are writing the correct code, or if they are writing it correctly if they do not fully understand the problem.

Every problem has two sides: the requirement and the solution set.

We speak of a solution set because there are potentially multiple solutions to any given problem. However, we cannot begin to discuss a solution when we do not fully understand the requirement (the problem). We solidify our understanding by asking questions.

A problem typically has constraints. You hope that the customer told you the constraints up front, but perhaps he does not even know them all. You have to discuss the problem and ask questions.

If you instead jump into proposing solutions, you waste time and might end up like this contrived example:

Get me across the river

1. Take off your shoes and wade

a. The water is too cold

2. Jump

a. The river is 15 feet wide

3. Use a canoe

a. The river is running too fast

4. Use a ferry

a. The river is at the bottom of a 100-meter deep canyon

5. Cut a tree and use it as a bridge

a. I have a car

6. Construct a bridge from steel and concrete

Now, if the contractor had instead asked questions, it might go more like this:

Get me across the river

1. What are the river’s dimensions?

a. 15 feet wide at the bottom of a 100-meter deep canyon

2. Are you walking?

a. No, I have a car

3. Construct a bridge from steel and concrete

By thinking about the problem and asking appropriate questions, the engineer was able to expose constraints and provide a workable solution in half the time as otherwise. In both examples, however, the customer thought he gave a reasonably simple explanation of a simple problem.

Sometimes a simple requirement is complex in more subtle ways. For example, the simple problem of importing data from text files into a database. That sounds like a simple problem until you start asking questions and learn that there are multiple kinds of text files.

We can have comma delimited files, string delimited files, column delimited files, some use ASCII encoding, others use EBCDIC encoding, some use UTF-8, others, UTF-16. Microsoft versions use a different line ending than UNIX and the same is true for file endings.

As you ask questions about this, you might decide that it is not a single requirement with multiple constraints. Perhaps it is actually multiple requirements, with on high-level requirement that generalizes them. However, you can only learn that by asking effective questions. Additionally, analyzing the problem above shows that once we have determined the specific differences in the input files, mapping the fields to the database is probably common between he different file types. That means that the beginning and the end of the process probably uses common code, but the details in the middle will have some differences.

So, by asking questions and thinking about the problem, you have identified several requirements that had been masked as one, but also commonalities in the sub-requirements that are probably areas for hidden code duplication. You probably noticed that there are potential areas that you can remove duplication by applying polymorphism, so when you have written code to import two file versions, you start looking at ways to refactor and take advantage of that.

These are things that, if you are not actively asking questions and discussing the problem with the customer and the other programmers, you are not as likely to realize and the system suffers as a result.

Remember, the customer wants the system badly enough to pay for it. He will appreciate these questions because that helps to assure that he gets the system that he wants. Well-reasoned questions are likely to remind the customer of details that he had forgotten to include, or perhaps has not even thought of himself.

When you are preparing for, and sitting in the planning meeting, ask questions relentlessly until you fully understand the problem. Then, ask more questions.

Posted on Tuesday, April 2, 2013 11:56 AM agile , Pair Programming , software engineering , software design , programming | Back to top

Comments on this post: Understanding the Problem

# re: Understanding the Problem
Requesting Gravatar...
I use a similar story to explain ball park estimates.

What kind of ball park, little league, minor league, major league, olympic, etc. Where will it go, empty lot, wooded lot, replace an older ball park, demolish historic buildings first, drain a swamp first.

Its amazing the details you can uncover when you stop to ask a few questions first.
Left by Nick Harrison on Apr 04, 2013 8:18 AM

Your comment:
 (will show your gravatar)

Copyright © L. Charles Andersen | Powered by: