Writing: Progress and Style

1. Writing: Progress and Style CMSC 601 Spring 2007

2. Sources • Robert L. Peters, Getting What You Came For: The Smart Student’s Guide to Earning a Master’s or Ph.D. (Revised Edition). NY: Farrar, Straus, and Giroux, 1997. • Justin Zobel, Writing for Computer Science: The Art of Effective Communication, 2/e. London: Springer-Verlag, 2004. • Also useful: Lyn Dupré, BUGS in Writing. Addison Wesley, 1995. • Prof. Marie desJardins’ lecture notes from Spring 2006 • Writing Technical Articles (with emphasis on paper in systems and networks), by Henning Schulzrinne • How (and How Not) to Write a Good Systems Paper, by Roy Levin and David D. Redell, originally appeared in ACM SIGOPS Operating Systems Review, Vol. 17, No. 3 (July, 1983), pages 35-40. • The structure of paper/report in Systems, by Michalis Faloutsos. • For specific links to papers, visit: http://www.csee.umbc.edu/~krishna/cs601/schedule.html

3. Questions • How many of youlike to write [in English]? • How many of you think you’re goodat writing [in English]? • How many of you are worriedabout writing [for this class, for your thesis/dissertation]?

4. Overview • Progress: • Organizing yourself and your thoughts • Writing: • General stylistic guidelines • Specific (but important) suggestions

5. Progress

6. The Writing Process • Writing should be part of the research process • It’s really hard to “Do The Work” and then “Write It Up” • For one thing, The Work is never done, and It is constantly changing • Writing on a regular basis helps to pin down the details, and helps to focus your ongoing research

7. Publishing Papers • You should publish papers along the way to getting your degree (definitely true for Ph.D. students; ideally true for M.S. students) • Peters says (p. 217): • “When deciding whether to use the paper publication strategy, be aware that you may have to put in more total work than if you do not publish.” • BUT: • In CS, you are expected to have publications when you graduate • Publications are part of the ongoing department evaluation process • The “extra work” more than repays itself in the long term, by focusing your research, and by helping you learn how to write (and how to do publishable research)

8. Write as You Work • Writing about papers you read: • ... makes writing the related-work part of your dissertation that much easier • ...creates a record of your understanding of the paper (because you will forget the details) • ...helps you to organize and synthesize the threads of the related work • ...encourages you to analyze and think about previous work and its limitations

9. Procrastination • Procrastination-busters: • Write something every day, even if scribbles, an outline, a paper summary, or a trivial bit of commentary • Reward yourself  • Write soon after you think and fix it later. (But organize well. Bad organization is much harder to fix later.) • Write (with pen/pencil) on paper first, then type it onto computer • For some it works better than others

10. Technical Paper Structure

11. Abstract • 150 – 200 words • 1-2 sentences about the problem considered in this paper (and the specific area/topic) • 1-2 sentences as to why the problem is interesting to study • 1-2 sentences describing your proposed methodology and why it is better/suitable than other schemes • 1-2 sentences on the evaluation methodology and take-away results • Avoid citations in abstract (except by names: Abraham et. al, 1997) • Keywords at end of Abstract (Optional): 3-5 keywords that capture essence of paper (used for indexing purposes; for assigning reviewers, etc.)

12. Section 1: Introduction (& Motivation) • This section is an expanded version of the Abstract • Should clearly bring out the WHAT, the WHY and the HOW • One logical way to organize it is to: expand the abstract and replace each grouped set of sentences with a paragraph. • You might add a brief 1-2 paragraph on critiquing CLOSELY related work on this problem and WHY your paper is attempting to solve and HOW it is solving the problem • A short paragraph on key contributions and key performance results from the paper • If space allows, a short paragraph on organization of the rest of the paper • Recommend NOT to talk too much about related work in this section • It is YOUR job to sell this paper and this Section is critical in setting the reviewer’s mindset; you must make them want to read the rest of the paper • Note: It is sometimes easier to write the Intro and Abstract AFTER the majority of the rest of the paper is written!

13. Section 2: Background; Related Work • A brief background (perhaps a subsection) of the topic that is needed for someone who knows the area, but not this specific topic • Use figures/diagrams to illustrate the main concepts • To avoid citing too many references when space-constrained, you can cite survey paper(s) that already summarize key work done on this problem • Summarize KEY papers related to the PROBLEM that you are trying to solve; identify main approaches/weaknesses of these papers • Finish with a paragraph on WHAT is missing from past work (for e.g., they make unrealistic assumptions, they work only for restricted cases) and how your paper is different from all those.

14. Section 3: Proposed Algorithm/System/Mechanism • Clear presentation (formal if possible) of problem statement; constraints considered, design goals/objectives • Present all formal notations/definitions and acronyms • Proposed Mechanism(s) • This might be split into several sub-sections • Build up your work in a manner easy to understand for the reader • Use of figures AND examples to illustrate concepts is important • At times, you might have another Section or 2 for the Proposed Work part • Use Algorithmic Style (algorithm.sty, etc) /flowcharts • Number Important Theorems, Definitions, Equations

15. Performance Evaluation/Property proofs • Theoretical Analysis • Empirical (Experimental Analysis) • (Discrete Event) Simulation or Programming package based Analysis • Clearly state: • Methodologies used • System Assumptions used in the evaluation • System parameters that are varied • Performance metrics that are studied

16. Perf./results section Different Scenarios? • Explain each scenario clearly, explain the metrics gathered • If you are using graphs/tables to present results, the explanations of these are really critical • Do not think that the user can figure out everything just by looking at the graph or table • Clearly state the key conclusion(s) for each graph; WHY is that so? If there are abnormalities in a graph (eg. Alg A performs well for light traffic, but fails for high traffic – EXPLAIN WHY!) • Here is where you get a chance to really sell your scheme to the reader • Be objective in this section – if your algorithm fails for some cases, state so – do not gloss over that fact!

17. Perf./results section • When presenting graphs: • Are x-axis, y-axis clearly labeled in the figure and explained in text? • Are font sizes readable (by middle-aged people in the least!) • Are legends legible in the figure – it is easy to visually differentiate the different plots in a graph? • Rule of thumb: around 5 plots per graph is good (for line plots) • Use bar graphs, line graphs effectively - try different means and see which one conveys results better • Do not Microsoft Excel (my recommendation!) – Use gnuplot, matlab, or other packages • Summarize the key findings from the performance studies in a paragraph at the end of the Section

18. Other sections • Discussions and Future Work (Optional) • Sometimes, it may be worth discussing the architecture, algorithm, practicality, how it can complement other work, etc. • You might try to stay ahead of the reviewers by stating your mechanism’s known weaknesses and where improvements are possible • Conclusions/Summary Section • This is similar to the abstract – but do not cut-and-paste • Acknowledgments (Be specific, Be honest, and be generous) • Bibliography • Appendices • Detailed proofs that are not needed in main section; Detailed tables • Conference papers (non-theory) usually do not have app.

19. More comments, contd. • Begin every section with a summary paragraph about what was in this section • Without being repetitive, reiterate at the end of long sections, what was presented. • At the beginning of long subsections with several sub-parts, it is good to summarize the subsection and the organization • Use footnotes very sparingly • Use statements in parenthesis very sparingly • Do not write long, winding sentences: Short, Simple Sentences are better • Avoid writing using “I did etc” unless it is a PhD research proposal or if it is clearly necessary to do so • Do not make statements that: “It is obvious that …” when it is not readily obvious to the typical reader • Avoid cliché’s such as “The rapid growth of the Internet has ..”

20. More comments, contd. • From: http://www.wisdom.weizmann.ac.il/~oded/PS/re-writing.pdf • Avoid “Checklist” Phenomenon: Stating a bunch of items somewhere in the paper, but not coherently • Avoid “Obscure Generality”: It is good to generalize, but over-generalizing makes it very hard to understand • Avoid “idiosyncrasies” • Avoid a Lack of hierarchy/structure: Highlight important statements clearly • Avoid exploring all subtleties and refinements of an idea/concept when first presenting it; start with basics and later on, move to finer aspects • Be aware of the knowledge level of the reader • Get feedback from a student in your lab/group first and then someone outside the lab (but in CS or related field)

21. More comments, contd. • Avoid “labyrinth of implicit pointers”: abuse of it and this and that – make clear which entity you are referring to, in a consistent way • E.g. a protocol must be referred to I-SA throughout the paper; not I-SA once, Interleaved Slotted Aloha elsewhere, etc • Avoid “sentences with complex logical structures” • Use if-then-else statements with bullet lists, if need be • Use lists (itemized, enumerated) to the extent needed: if there are at least 3 items, that can make a list • Avoid “Mixture of mathematical symbols and text:” • Avoid “Cumbersome notations and terms” such as:

22. Robert Peters’ Words of Wisdom • Keep it brief. • Break it up. • Don’t be self-important. • Start your paragraphs with topic sentences. • Don’t write a detective novel. • Don’t try to handle too many ideas at once. • Use key words. • Signpost with transitional phrases. • Repeatedly summarize. • Avoid passive constructions. • Avoid adverbs. • Delete double negatives. • Chop off your first paragraph and rewrite. • Read it out loud. • Read it again cold. • Move back and forth between word processor and paper.Quoted from Peters pp. 231─233

23. More comments on papers • Each advisor will have his/her writing style • Make sure that you confer with advisor before you write papers for submission elsewhere • Take reviewers’ comments with equanimity • Do not lose heart on a reject decision • Do not see “red” on errors/flaws being pointed out – look at reviews objectively and be prepared to revise the paper as deemed best by you and advisor • Reviewers do point flaws that do not exist

24. Responding to Criticism • “The reader is always (well, at least sometimes) right (or at least kinda).” • Don’t get defensive and start making excuses: • “It’s in there!” [Then why didn’t they notice it?] • “I didn’t have room!” [Then maybe you should rethink your priorities.] • “It’s not important!” [But this reader thinks it is. So the paper has to explain it, or convince her that it’s not important.] • But ignore “There’s no future work” comments...

25. Thesis Structure • Specific structure varies, but in CS you should always: • Describe the problem • Explain why it’s important • State how you solved the problem • Make explicit claims about your approach • Support these claims experimentally and/or analytically • Place your approach in the context of current and past related work • Give directions for future work • Applies in smaller scale and with variations to proposals and technical papers

26. A Minor Quibble • Peters suggests (p. 215): • “Incidentally, don’t make substantial revisions based on input from only a single committee member, since their instructions will often be contradictory and you should resolve contradictions before extensive rewriting.” • The exception is your advisor! As a general rule, you should not circulate a draft paper/dissertation to your committee until your advisor has OK’d it. • Their reputation is on the line • The other committee members shouldn’t have to read a half-baked draft. Your advisor will help you bake it.

27. End of Part I