How to Write a Bad Paper

1. How to Write a Bad Paper Tom Anderson (credits to John Ousterhout, Dave Patterson, and many others) http://www.cs.utexas.edu/users/dahlin/advice.html

2. Outline • How to write a bad paper • How to give a bad talk • How to do bad research • How to have a bad career Keys: confuse your audience, solve the wrong problem, fudge results

3. 1. Thou Shalt Provide No Context • You’ve been working on the problem for months (years?), so of course its important! • It’s the reader’s responsibility to know • The problem • Why it’s important • The obvious solutions and why they don’t work • Other solutions that have been tried in the past • Your key assumptions • How your solution is different Instead: its your opportunity to define the terms of the debate; often the solution is obvious once the problem has been defined.

4. 2. Thou Shalt Not Define Terms • Readability is for wimps • “[5] provides a FEC+ARQ-based CLVL for QoS” • Advanced version: define terms, but define them differently from standard practice to confuse the reader • Examples: process, soft state, … Instead: think tutorial; the audience is literate but needs to be reminded of key details

5. 3. Thou Shalt Not Covet Clarity • Best compliment: “It’s so complicated, I can’t understand a thing you’ve said” • Easier to claim credit for subsequent good ideas • If no one understands your work, how can they contradict your claims? • Its easier to be complicated • To publish it must be different; add N+1st incremental feature • “If it were not unsimple then how could distinguished colleagues in departments around the world be positively appreciative of both your extraordinary intellectual grasp of the nuances of the issues as well as the depth of your contribution?”

6. 4. Thou Shalt Slam Related Work • You’ll look better in contrast! • The readers won’t know the truth • There’s no chance the authors of the related work will be reviewing your paper • The shoe will never be on the other foot • Advanced version #1: completely ignore related work! • Advanced version #2: make bogus appeals to authority, ideally citing each member of the program committee • “Following the end to end principle [1], we use soft state [2] virtual circuits [3] to provide hard QoS guarantees [4] …”

7. 5. Thou Shalt Not Mention Any Drawbacks to Your Approach • Maybe the reader won’t notice! • Hide • Key assumptions • Limitations in experimental methodology • Obviously relevant related work • Advanced version: Overgeneralize from limited data • “As our [trace-based] study shows, deploying a web proxy cache reduces user latency by 40.31%” Instead: readers (like everyone else) give the benefit of the doubt to those they trust

8. 6. Thou Shalt Replace “will do” with “have done” • The law of best intentions: “After all, it will have been done by the time the conference occurs” • Interpolate data points if the experiments haven’t finished in time (or if the results aren’t what you predicted) Instead: data (esp. unexpected data) is the raw material of innovation

9. Obsolete Scientific Method Hypothesis Sequence of experiments Vary one parameter/exp Prove/disprove the hypothesis Document so others can reproduce results Computer Scientific Method Hunch Do only one exp. and vary all the parameters at once Discard/ignore any data that disproves hunch Documentation just makes it easier for rivals to compete 7. Thou Shalt Use the Computer Scientific Method

10. 8. Thou Shalt Not Label Thy Graphs Advanced versions: graphs that don’t begin at zero, rescaling between adjacent graphs, using log/linear scale to make results look better …