Anatomy of a Scientific Research Paper (Part 3): What’s YOUR Problem?

It’s the first question every reviewer will ask when reading your paper: what problem are you solving?

If you do not answer it, your paper will be rejected.  If you answer it in a way that is too complicated, your paper will be rejected.  And if you can not answer it, your advisor will probably not let you submit the paper in the first place.  In fact, I would say this is probably the number one reason that papers are rejected.  Papers usually start talking about the solution before talking about the problem.

The good news is that you can make it easy for reviewers to find out what problem you address.  You do this with a section titled The Problem.  This is the section we’ll look at today.

The Problem will typically have three parts.  The first part is a simple description of the problem.  The second part explains the main reason why the problem is difficult to solve.  The third part is a motivating example that demonstrates the problem.  Let’s look at these.  Take a look at the first paragraph of this The Problem section:

The long-term problem we target in this paper is that much software documentation is incomplete [28], which costs programmers time and effort when trying to understand the software [11].  In Java programs, a typical form of this documentation is a list of inputs, outputs, and text summaries for every method in the software (e.g., JavaDocs).  Only if these summaries are incomplete, do the programmers resort to reading the software’s source code [37].  What they must look for are clues in the source code’s “structure” about how the methods interact [16, 22, 48].  The term “structure” refers to both the control flow relationships and the data dependencies in source code.  The structure is important because it defines the behavior of the program: methods invoke other methods, and the chain of these invocations defines how the program acts.  In this paper, we aim to generate documentation that is more-complete than previous approaches, in that our generated documentation contains structural information in each method’s summary.

Now, you have probably never read this paper before.  I’m dropping you at the beginning of Section 2, so you haven’t even read the introduction or abstract.  But you still know what the problem is.  This is possible because the paragraph uses simple language such as “The long-term problem we target in this paper is…”.  You also know why the problem should be solved: it costs programmers time and effort.  And notice that even though these statements may seem like common sense, they are cited — leave no question that your problem is real.

Moving on.  Sentence two, the first of several definitions here.  Many readers may have different ideas about common terms like “documentation.”  So we set up here that we’re talking about JavaDoc-like documentation.  I.e., documentation for programmers, not end users.

Sentence three and four describe what programmers get out of this documentation.  They are looking for some kind of “structural” information.  We know what this is, but readers may not, so we define it in sentence five, and say why this “structure” is important in sentence six.  Let me point out again to use simple language.  “The structure is important because…”.

Sentence seven hints at what we do.  Notice, there is no discussion of our solution.  The Problem section should not talk about the solution.  The most it should do is clarify what problem is being solved in the paper.  Look at the next paragraph:

We include this structural information from the “context” surrounding each method in the program.  A method’s “context” is the environment in which the method is invoked [24].  It includes the statement which called the method, the statements which supplied the method’s inputs, and the statements which use the method’s output.  Context-sensitive program slicing has emerged as one effective technique for extracting context [24].  Given a method, these techniques will return all statements in its context.  However, some statements in the context are more-relevant to the method than other statements.  This issue of relevance is important for this paper because we must limit the size of the text summaries, and therefore select only a small number of statements for use in generating the summaries.

Sentence eight and nine give more definitions.  All these definitions are important for understanding our solution.  Do not obsess about citations here, but do cite the definitions whenever possible, and definitely when you use a non-standard definition.

In addition to these definitions, the point of this paragraph is to let your readers know what is so hard about your problem.  You do not want your readers to react by thinking “this problem been solved already” or “the trivial solution is the best one for this problem”.  These reactions are unfortunately common for scientific readers, and you should be sure to make the difficulty clear.  Or, if you prefer, to make your “niche” clear.

Next is a good time to reinforce the difficulty.  A motivating example usually does the trick:

Consider the manually-written examples of method summaries from NanoXML, a Java program for parsing XML, below.  Item 1 is an example method we selected.  It demonstrates how the default summary from documentation can be incomplete.  In isolation, the method summary leaves a programmer to guess: What is the purpose of reading the character? For what is the character used? Why does the method even exist? …

I’ve snipped the rest of the example for the sake of space, but you can look it up in the paper.  Just remember: the point is to communicate what problem you are solving.  Show the inputs and typical outputs.  Contrast these to the outputs from your solution.

Now, another item you may want to discuss in The Problem is the benefit to a solution to the problem.  You may wish to do this if your problem is somewhat obscure.  In the case of the example I used above, we take it for granted that better documentation generators would reduce programmer time and effort.  But that may not be the best strategy depending on your problem or venue.

There is another time you will want to explicitly describe the benefits of a solution.  That is when the problem you solve is a “knowledge problem.”  It is a topic for another post, but basically a knowledge problem is a hole in current literature.  For example, your paper may discuss an empirical study where you compared different tools/chemicals/specimens/etc.  In this case, you will probably not have a motivating example, and instead explain exactly how other papers do not quite cover the problem you discuss.  I’ll write a different post about this, but for now some information is in Write the Introduction FIRST.

Leave a Reply

Your email address will not be published. Required fields are marked *