How to Write a Research Paper in Computer Systems For Butler Lampson

(If Butler Reads it and likes it, others will follow)

David R. Cheriton

The Challenge

Most research papers are garbage. Your challenge is to convince Butler Lampson that you as an author are not a turkey, nincompoop, or handwaver.

Turkeys work on non-problems and miss the real problems.

Nincompoops come up with bogus solutions.

Handwavers do not have a convincing story to back up their proposed solution, usually because it has not been implemented, never mind measured.

Every word counts, because Butler is looking for a reason to stop reading your paper. Life is short, papers are long and (too) many.

Overall Structure of Paper

Use the following overall paper structure: Now let's consider this portions in more detail.

Introduction

You have to convince Butler that you have identified a real problem. Let me emphasize: a "real" problem. Someone has to be in real pain. It can't be just trying to save few cycles, a few bytes, a few BPS when we are drowning in resources.

Just give hint of the solution.

"Solution"

Describe the "solution" as concisely as possible so that someone just reading this section knows what it is and ideally could implement or realize it.

Avoid any discussion of related work, pro's and con's, etc. in this section. Butler may need to refer back to this section to review your solution if and when he reads the rest of the paper. However, if he can't divine the solution precisely from this description, he is not in a position to understand its advantages, disadvantages and comparisons to other work.

Why Wonderful

State the advantages in order of importance.

Make a point to identify disadvantages and issues. Even the best solution has disadvantages.

Related Work

Start with the most relevant work.

Be sure to get adequate and proper credit where credit is due.

Try to demonstrate with few words and references that you understand the current state of the art.

Focus on the positive - how your solution improves on previous, rather than how the previous work is deficient. (Partly to be political but also to recognize: all reasonable work does advance the field, even if only by providing some examination of a wrong direction.)

Conclusions

Have at most 3 major conclusions and state them to make them EXTREMELY obvious and clear as conclusions. That is, Bulter should not have a single doubt or miss any statement of a conclusion. The content of the conclusion may be (and ideally is) less obvious.

Make sure the introduction clearly states the problem and focus of the paper which these conclusions address.

Read the intro and conclusions consecutively like you are Butler when he is just considering whether to waste precious minutes in his life reading your paper, given the statistically high probability that it is crap, i.e. just ego-marking on another tree that should not have had to die. Ask yourself if you would then really honestly want to read the rest of the paper. Now, fix it so you and Butler would.

Random Do's

Do structure each section or subsection as much as possible as: Do put the most important point first in a list or sequence.

Do put the "what" before the "why". I.e. say "foo is true because of blat", not "Because of blat, foo is true."

Do put your solution first and then contrast it with the alternatives both at the section level and paragraph level. I.e. provides X, Y and Z. In contrast, does not provide any of it.

Do put the positive first, and then follow with the negative. Like, in the above point --- say what is good about your approach and then what is bad about others in a comparison.

Do follow every general statement with an example (and an example that is illustrious of the point of the general statement). For example (get it!), 

Too small a cache can significantly degrade application performance.
For example, MP3D was measured to run 50 percent slower with a
256 kilobyte second-level cache than with a 1 megabyte cache.

Random Don'ts

Don't use the plural form in exposition unless you really need to. Single is simpler and clearer. Example: 
Wrong: The packets are then forwarded to their destinations.
Here it is unclear whether each packet has one destination or several. 
Right: The packet is then forwarded to its destination(s).

Don't use the future tense in exposition. When you are explaining a design, the design is, not will be. Present tense is simpler and clearer and avoids the funny notion that what you are describing will happen sometime in the future, but not clear when.

Don't use "since" to express a reason for something. "Since" is far weaker than "because" and should be only used when you mean "since" some time or event. (In fact, this confusion about "since" is arguably part of the whole confusion in using temporal ordering to imply (potential) causality in causally and totally ordered communication systems.)

Don't use vague statements. Example: 

Wrong: a cache can significantly affect performance.
Here, the reader is left to figure out what the effect is. Moreover, you still have to elaborate, typically using extra words compared to being more definite in the above sentence. 
Right: A processor cache of 64 megabytes improves
the performance of several database applications by 25 percent or more.

Don't use "very" in technical writing. It suggests some emotional judgmental notion rather than scientific/technical assessment. E.g. who are you to say something is "very complex" rather than just "more complex" than some alternative. When is something "complex" versus "very complex".

Finally, finally, keep the writing simple and focused on a small number of the most important points, at each stage: introduction, solution, advantages, conclusions, etc.