Writing Papers

1. Writing Papers Henning Schulzrinne Dept. of Computer Science Columbia University

2. On writing papers • Good writing is necessary, but not sufficient • In competitive conferences, all accepted papers are well-written • during the review process, not afterwards! • Bamboozle reader with obfuscation rarely works • “Must be a great paper since I don’t understand it” • If you didn’t have time or patience to get the writing right, why should I trust the measurements or proof? • If you don’t care about the reader, why should I waste my time with your paper?

3. Paper structure • A paper tells a story – like a short novel • introduce the characters • describe setting (but not “It was a dark and stormy night”) • make readers care about the setting and characters • has plot: problem, conflict, resolution • wrap up with “moral” • but • it’s not a detective story – readers will not search for clues to find the perp • it’s not magic realism • unlike (German) novels, it mostly has happy ending • PG-rated

4. Paper structure • Fairly typical, but variations possible • keep template • Abstract = quick overview, indexing • Introduction = one-page extended abstract • why, how, how come, how good, what’s coming up • Related work = how is this different? • can be at end, but uncommon • Protocol, algorithm • Experimental setup • Experiments • Evaluation and discussion of results • Future work = things I want to do next • Summary = what did we learn? • Appendix • details that detract from the main story

5. Paper title • Important for classification and first impression • Should give key idea or motivation if systems paper • Often used to assign paper to reviewers • Avoid empty words that apply to 90% of papers • “performance evaluation” • “implementation” • Ask: how many other papers would this title apply to? • Sometimes useful to give project title: • “7DS: Extending the Internet to mobile ad-hoc networks” • Other standard patterns: • “Reducing hand-off delays in 802.11 networks by hypnosis” •  what, where, how

6. Abstract • Used to assign reviews and to index final paper • thus, important to include appropriate buzz words and abbreviations • What is this about? • area, measurement, theory, … • Why should I care? • key result • How did I prove the result? • experiment, analysis, simulation • Use present tense (“we show that”) except for measurements and implementations (“we measured”) • Avoid fluff at all cost • if this could apply to hundreds of papers, omit it • “TCP throughput is important”

7. Introduction • The most important part of the paper • some reviewers won’t read more than that… • like first impressions: accept/reject opinion is often formed after reading introduction • ideally, should be able to stand alone and be an extended abstract • No longer than a page • Never, ever start with “Recent advances in X”! • Don’t repeat abstract verbatim (although it contains some of the same information) • Describe problem, approach, solution, key result • describe larger context if sub-problem • where is this relevant? are there other places, too? • Concludes with brief overview of paper (“We first summarize related work in Section 2. Section 3 describes our the algorithm.”)

8. Related work • What makes our work different from others? • better in some measurable way (faster, more secure, cheaper, …) • more general or different applicability • simpler to implement or understand or secure • more robust (fewer critical parameters) • Important for review and reader • reviewers: “yet another paper on X” • particularly if only vaguely familiar with area • reviewers get mad if their work isn’t cited • readers use it to do a breadth-first search on area • Honesty counts • don’t dismiss some related work because of superficial difference • “uses uppercase message labels”

9. Experiments and graphs • Did you pick the right graph type? • pie charts and multi-bar charts often wrong • don’t connect points that aren’t a function (e.g., different experiments)  scatter plot • Scale: should the graph be log-scaled? • Graph legends should be largely self-describing, without reference to text body • explain both axes (“speed of robotic mouse as function of time, with cat”) • Must be intelligible in black & white • Avoid dozens of lines that all look the same • Label lines rather than forcing reader to map “square-with-medium thick dot-dash line” to legend • Axes must contain units • Avoid simple straight lines – can just describe • Include margins of error (confidence intervals) • Text should explain all interesting features • e.g., dips, spikes, peaks, non-smoothness, … • avoid just stating the obvious or repeating data points • answer “why?” question -- theory that explains behavior • e.g., via approximation

10. Description • Avoid conflating levels of details • “The Internet consists of routers (some of which use blue LEDs)” • Avoid sounding like a lawyer • “We implemented a router (using the word implement in the sense of building, but not necessarily testing to ISO 9001. Your mileage may vary; past performance is no indication of future results. No animals were harmed in the making of this paper.)” • Make sure to indicate which results, measurements, implementations are yours • Getting into plagiarism and falsification territory

11. Writing style hints • Limit use of parentheses (since they distract the reader and indicate that you didn’t want to think about how this text relates to the previous part) • also avoid hyphens • Paper should remain meaningful when reading only the first sentence of each paragraph – “topic sentence” • Transitions – don’t just collate paragraphs and sections • e.g., “The result is then processed by the sniffle engine, [which we describe next.]” • Avoid passive voice and weak verbs (is, has)

12. Questions to ask • Why should somebody else care about the results? • Can somebody not familiar with the research understand the paper? • Why is this not yet another minor tweak on problem X? • Is this an anecdote or a theory? • Is the improvement meaningful and does it come at a cost? • 5% rarely matters unless the system is static • e.g., no additional bandwidth or CPU can ever be added • Does it require tweaking and only happens if the parameters are just right?

13. Common “mechanical” problems • Incomplete sentences • Spelling and grammar • Use of abbreviations without explanation • Figures that can’t be read except with a microscope • incomplete legends • work only in color • use GIF or (worse) JPEG • Incomplete and inconsistent references • use BibTeX! • no year, no conference, no institution (for tech reports), …