Writing PapersOn writing papersPaper structureSlide 4Paper titleAbstractIntroductionRelated workExperiments and graphsDescriptionWriting style hintsQuestions to askCommon “mechanical” problemsWriting PapersHenning SchulzrinneDept. of Computer ScienceColumbia UniversityOn 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?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-ratedPaper 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 storyPaper 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, howAbstract•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”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.”)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”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 approximationDescription•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 territoryWriting 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)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