Every project requires effort and resources, which means it needs to be justified. Justification requires clearly and convincingly communicating why the project is worthwhile, how it will be done, and how to declare success.
This post presents a mental model to help strategically plan what to do and focus on. Understanding this mental model also simplifies the writing process and will help you identify gaps in your arguments. This is presented in the context of writing the introduction to a research paper, but its principles apply broadly to planning, understanding, and communicating any project, research or otherwise.
The above figure summarizes a project as a dependency graph between concepts that must be clearly anticulated, and dependencies between these concepts. An arrow A → B means that resolving or understanding B requires resolving or understanding A clearly.
I have numbered the nodes in the typical order that they are presented in a research paper, and colored them according to their role. Let us examine them roughly in numeric order.
Every project is centered around an unsolved problem. The problem is only important because of the use cases that encounter this problem. These may be use cases today (applied research), in 5 years (forward-looking research), or perhaps never (speculative research). The bigger, more relevant, more pressing, more broad reaching, the better. But you need to make sure that the problem is the most important issue for the use case - “the high pole in the tent” as Turing laureate Stonebraker likes to say.
Now, the problem only exists because of a set of causes (in the causal sense). Can you identify what they are? The closer to the root cause of the problem, the better. You can tell because the presence of the cause leads to the problem, and fixing the cause fixes the problem. Naturally, identifying the cause motivates a strategy to fix the cause. This strategy makes use of an insight that no one else has thought of before, which then motivates the technical solution(s). If the insight is not new, then you would expect to arrive at a pre-existing solution.
How do we know fixing the cause solved the problem? Well, we need some metric to measure success. In an established problem, there are usually agreed upon metrics (whether you agree with them or not), but in new problems you may need to justify a metric based on logical reasoning. These, along with the solutions, motivate an evaluation design that can attribute better outcomes to the solution, and ideally to the root cause. This is why getting a higher metric is not enough. To claim that your solution is better, you need to establish that the higher metric is due to the cause, insight, and solution.
Writing academic papers is hard, and writing introductions is very hard. While there are many tips and articles for how to improve writing, they are typically tactical in nature. They explain how to present citations, or connect sentences, or use “While” instead of “But”. But they do not explain how to plan a project for success, nor what writing an introduction really means.
The fundamental constraint of writing is that it is linear. Your goal is to write a linear sequence of words and sentences to convey that your project is novel and better (than prior work). Yet, the preceding section has illustrated that a project is not linear but actually a complex dependency graph between necessary concepts (nodes) and their motivation (edges). Once your graph has been fleshed out, writing is simply a linear ordering of the nodes and edges. In fact, just follow my numbering.
I know this model works because my accepted papers follow the model, and when a paper is rejected, it is because some node or edge is missing or unclear. For instance, suppose you have devised a solution SP for problem P that requires careful assumptions about P. But you have not written P and its assumptions clearly. The reader interprets your writing as describing a different problem P’, and SP is no longer the best solution or perhaps is not applicable at all!
This section is an example of linearly ordering a dependency graph. Here is each concept in numbered order:
You have recieved a rejection or revision notification for your paper submission. Once you have taken a few days to scream into the void and calm down, the process is now simple. Assuming your work was correct, simply map each reviewer response to a node or edge in the graph, try to intuit whether the reviewer’s interpretation of the graph is consistent with your own, and clarify any inconsistent points so that the reader’s mental model coincides with your own. This process of intuiting what the reviewer thinks is tricky, and deserves a future post.
Remember that this is a dependency graph. What this means is that changing one node may require adjusting all of the other nodes in response. Say you change your solution. It may not be solving your original cause anymore, but instead a slightly different cause, which solves a slightly different problem, which is no longer important for the use cases and does not justify the metric of success, which means you need to re-design your experiments.
As you can see, there are two “source nodes” in the graph, the use case and the cause, that represent the main degrees of freedom that you as a researcher have: to choose the problem and to pick the cause(s) to fix. In a sense, everything else is simply a logical consequence (which may require creativity). The solution is an ancillary degree of freedom, because you are free to choose between the many imperfect or perfect ways to fix the root cause.
People usually think of novelty as a different solution to the same problem. From the graph, it is clear that this is a shallow form of novelty. It is really characterized by novelty upstream of the solution: a novel insight that leads to this new solution, or even better, a cause that is even more of a “root cause”.
Related work is based on a partial matching problem between all existing papers (which each have their own dependency graphs) and your paper. It is partial because you may match on any subset of nodes, but typically some combination of Problem, Cause, Insight, and/or Solution. Since related work is of finite length, this is a top-k partial matching. Once you have aligned on a subset of nodes, your job is to explain the alignment and the difference between the unaligned nodes. Lazy related work sections usually ignore the latter.
I hope this mental model is helpful as a checklist when planning a project or writing a paper about it. If it is helpful, please let me know! For more tactical advice on how to write clearly, you may see a previous post How to Syntactically Structure Your Writing.