Four Habits of Effective Technical Paper Writers

1
Four Habits of Effective Technical Paper Writers
Dr. Douglas C. Schmidt d.schmidt_at_vanderbilt.ed
u
Professor of EECS Vanderbilt University
Nashville, Tennessee
2
A man who has the knowledge, but lacks the
power to express it, is no better off than if he
never had any ideas at all. -- Thucydides, Dean
of the Vanderbilt School of Engineering, 400 BC
3
Motivation

• Publishing papers in top quality venues is the
  single most effective way to invest in your
  future
• http//citeseer.ist.psu.edu/mostcitedn.html
• Publishing papers is inherently a social process
• i.e., your work will have to pass the scrutiny of
  reviewers who are experts in your field
• Reviewers often dont have a lot of time to spend
  on reading reviewing papers
• Although reviewers are devoted to doing the best
  possible most thorough job, qualified reviewers
  have a hectic demanding schedule
• A reviewer has limited time to read your paper
  frequent distractions to confuse him/her
• Often, your paper will get exactly one
  (superficial) reading by a reviewer

This talk describes concrete steps you can take
to enhance the quality of your papers increase
their changes of being accepted for publication
4
Types of Papers

• We write two general types of papers at ISIS
• Research papers, which describe a new idea or
  technique
• It must describe original/novel work
• It should present solid supporting evidence, not
  just conjecture
• Idea papers should be backed up by a convincing
  analysis
• Experience papers, which present new data based
  on actual experience that demonstrates the
  (in)effectiveness of technologies, describes
  problems encountered, suggests improvements
• It should provide new evidence (either positive
  or negative) to evaluate existing ideas
  techniques
• It should help provide direction for future
  research new insights of value to other
  practitioners using these technologies

5
Synopsis of the Paper Writing Process

• Do good research get solid results
• Avoid trying to publish speculative or premature
  papers in top venues
• Figure out what you want to say about your work
• Not everything you do is equally interesting to
  reviewers/readers
• Figure out who your audience is determine your
  venue
• Different audiences/venues have different
  expectations payoffs
• Decide whether youve got anything useful to add
• Stay current with research in your field
• Follow four habits of effective paper writers
• Adhere to a structure
• Present effectively
• Iterate continuously
• Collect integrate feedback

6
Habit 1. Adhere to a Structure

• Divide your paper into an abstract 5 sections
  
• The abstract summarizes the paper its
  contributions
• Its purpose is to get your paper into reviewers
  A pile
• Section 1 motivates the problem sketches your
  solution
• Convince reviewers why its a problem that its
  important to solve
• Section 2 describes how you solved the problem
• Convince reviewers qualitatively your solution
  really solves the problem described in Section 1
• Section 3 provides concrete evidence showing that
  your solution really solves the problem, e.g.,
  analytical results and/or results from empirical
  tests
• Convince reviewers quantitatively/analytically
  the problem is actually solved that you have
  properly interpreted your results
• Section 4 compares you with other work in the
  area
• Convince reviewers you have a novel contribution
• Section 5 presents lessons learned
• Convince reviewers your work is significant

7
Writing a Good Abstract

• The abstract is your summary of the conclusions
  of your paper its contributions to important
  research problems in your field
• A canonical form for writing good abstracts is
  often
• First provide the context
• Next state the problem being investigated
• Then outline the contribution(s) this paper makes
  to research on the problem
• Summarize the results of the research in this
  paper

8
An Example Abstract
Many distributed real-time and embedded (DRE)
applications require a scalable event-driven
communication model that decouples suppliers from
consumers and supports advanced quality of
service (QoS) properties and event filtering
mechanisms. The standard CORBA Notification
Service is insufficient to enforce predictable
communication needed by DRE applications and does
not leverage Real-time CORBA capabilities, such
as end-to-end priority preservation, priority
models, and scheduling. This paper makes two
contributions to the study of scalable real-time
notification services for DRE applications.
First, we explain how we have addressed key
design challenges faced when implementing a
Real-time Notification Service for the TAO
real-time object request broker. We discuss the
optimizations used to improve the scalability of
TAOs Real-time Notification Service, which
integrates Real-time CORBA features (such as
thread pools, thread lanes, and priority models)
to provide real-time event communication by
dedicating thread resources with minimal locking
overhead in the critical path of event
propagation. Second, we analyze the results of
empirical benchmarks of the performance and
predictability of TAOs Real-time Notification
Service. These results show that the static
real-time assurances enforced by Real-time CORBA
are maintained within the more flexible context
of TAOs Real-Time Notification Service.
9
An Example Abstract
Many distributed real-time and embedded (DRE)
applications require a scalable event-driven
communication model that decouples suppliers from
consumers and supports advanced quality of
service (QoS) properties and event filtering
mechanisms. The standard CORBA Notification
Service is insufficient to enforce predictable
communication needed by DRE applications and does
not leverage Real-time CORBA capabilities, such
as end-to-end priority preservation, priority
models, and scheduling. This paper makes two
contributions to the study of scalable real-time
notification services for DRE applications.
First, we explain how we have addressed key
design challenges faced when implementing a
Real-time Notification Service for the TAO
real-time object request broker. We discuss the
optimizations used to improve the scalability of
TAOs Real-time Notification Service, which
integrates Real-time CORBA features (such as
thread pools, thread lanes, and priority models)
to provide real-time event communication by
dedicating thread resources with minimal locking
overhead in the critical path of event
propagation. Second, we analyze the results of
empirical benchmarks of the performance and
predictability of TAOs Real-time Notification
Service. These results show that the static
real-time assurances enforced by Real-time CORBA
are maintained within the more flexible context
of TAOs Real-Time Notification Service.
Provide the context
10
An Example Abstract
Many distributed real-time and embedded (DRE)
applications require a scalable event-driven
communication model that decouples suppliers from
consumers and supports advanced quality of
service (QoS) properties and event filtering
mechanisms. The standard CORBA Notification
Service is insufficient to enforce predictable
communication needed by DRE applications and does
not leverage Real-time CORBA capabilities, such
as end-to-end priority preservation, priority
models, and scheduling. This paper makes two
contributions to the study of scalable real-time
notification services for DRE applications.
First, we explain how we have addressed key
design challenges faced when implementing a
Real-time Notification Service for the TAO
real-time object request broker. We discuss the
optimizations used to improve the scalability of
TAOs Real-time Notification Service, which
integrates Real-time CORBA features (such as
thread pools, thread lanes, and priority models)
to provide real-time event communication by
dedicating thread resources with minimal locking
overhead in the critical path of event
propagation. Second, we analyze the results of
empirical benchmarks of the performance and
predictability of TAOs Real-time Notification
Service. These results show that the static
real-time assurances enforced by Real-time CORBA
are maintained within the more flexible context
of TAOs Real-Time Notification Service.
State the problem being investigated
11
An Example Abstract
Many distributed real-time and embedded (DRE)
applications require a scalable event-driven
communication model that decouples suppliers from
consumers and supports advanced quality of
service (QoS) properties and event filtering
mechanisms. The standard CORBA Notification
Service is insufficient to enforce predictable
communication needed by DRE applications and does
not leverage Real-time CORBA capabilities, such
as end-to-end priority preservation, priority
models, and scheduling. This paper makes two
contributions to the study of scalable real-time
notification services for DRE applications.
First, we explain how we have addressed key
design challenges faced when implementing a
Real-time Notification Service for the TAO
real-time object request broker. We discuss the
optimizations used to improve the scalability of
TAOs Real-time Notification Service, which
integrates Real-time CORBA features (such as
thread pools, thread lanes, and priority models)
to provide real-time event communication by
dedicating thread resources with minimal locking
overhead in the critical path of event
propagation. Second, we analyze the results of
empirical benchmarks of the performance and
predictability of TAOs Real-time Notification
Service. These results show that the static
real-time assurances enforced by Real-time CORBA
are maintained within the more flexible context
of TAOs Real-Time Notification Service.
Outline the contributions this paper makes to
research on the problem
12
An Example Abstract
Many distributed real-time and embedded (DRE)
applications require a scalable event-driven
communication model that decouples suppliers from
consumers and supports advanced quality of
service (QoS) properties and event filtering
mechanisms. The standard CORBA Notification
Service is insufficient to enforce predictable
communication needed by DRE applications and does
not leverage Real-time CORBA capabilities, such
as end-to-end priority preservation, priority
models, and scheduling. This paper makes two
contributions to the study of scalable real-time
notification services for DRE applications.
First, we explain how we have addressed key
design challenges faced when implementing a
Real-time Notification Service for the TAO
real-time object request broker. We discuss the
optimizations used to improve the scalability of
TAOs Real-time Notification Service, which
integrates Real-time CORBA features (such as
thread pools, thread lanes, and priority models)
to provide real-time event communication by
dedicating thread resources with minimal locking
overhead in the critical path of event
propagation. Second, we analyze the results of
empirical benchmarks of the performance and
predictability of TAOs Real-time Notification
Service. These results show that the static
real-time assurances enforced by Real-time CORBA
are maintained within the more flexible context
of TAOs Real-Time Notification Service.

• Summarize the results of the research in this
  paper

13
Writing a Good Introduction

• The introduction motivates the problem to be
  solved sketches the solution
• A canonical form for writing good introductions
  includes
• Provide the context for the work, e.g., sketch
  emerging trends
• Explain which research-worthy problems in this
  context your paper focuses on
• Describe your approach for solving these problems
  outline why this paper is novel relative to
  other work
• Outline the papers organization, emphasizing its
  contribution

14
Writing a Good Solution Section

• Many authors of papers make the following
  mistakes
• Do an extremely poor job of motivating what
  problems their technologies actually solve
• Focus on low-level implementation details no one
  cares about
• Many reviewers lose interest in solutions that
  arent well motivated/described
• Its particular important to motivate your
  solutions in conferences since the reviewer
  assignment process tends to be rather chaotic
• It may help to apply the following structure
  repeatedly to Section 2
• Focus on key design challenges
• For each challenge describe the
• Context
• Problem
• Solution approach
• Solution applied

Good diagrams are essential
15
Writing a Good Results Section

• The results section should provide concrete
  evidence showing that your solution really solves
  the problem
• e.g., analytical results and/or results from
  empirical tests
• Experiments should be described using canonical
  format, e.g.,
• Characterize hardware/software testbed
• Describe experiment design
• Present empirical results
• Analyze/interpret the results
• Experiments should be repeatable
• e.g., distribute the benchmarking source
• It is hard to publish papers in top venues
  without thorough empirical results

16
Writing a Good Related Work Section

• Your related work section should make the
  contribution of your paper abundantly clear
• It is not the job of the reviewers to ferret out
  this information
• One aspect of identifying the contribution is to
  cite make appropriate comparisons with previous
  work (including your previous work)
• A research paper should compare contrast the
  work with prior work, demonstrating novelty
• An experience paper should compare its results
  with other papers that present similar or
  opposing data
• An experience paper that merely confirms that
  which is well known has opposed to that which is
  widely believed) is of little value
• Make sure that the results of your evaluation in
  Section 3 actually support the contributions you
  claim in the related work section!

If you cant concisely convey the contributions
of the paper in the related work section then the
work is either (1) premature, (2) insufficiently
novel, or (3) inadequately motivated
17
Writing Good Concluding Remarks

• A common mistake is to simply restate the
  abstract
• It is particularly important that systems work
  conclude by summarizing lessons learned from
  developing evaluating the technologies
  showcased in the paper
• This helps reviewers appreciate that the authors
  actually did significant work have sufficiently
  generalized their findings so that others may
  benefit
• Lessons learned should include a mix of pros
  cons, e.g.
• The component middleware paradigm elevates the
  abstraction level of middleware to enhance
  software developer quality and productivity. It
  also introduces accidental complexities, however,
  that are hard to handle in an ad-hoc manner for
  large-scale applications. For example, the CCM
  requires many configuration files due to its
  large number of configuration points. Model-based
  tools help to alleviate the accidental
  complexities of component middleware
• Its ok to briefly summarize future work, but
  dont go overboard since theres insufficient
  room to validate claims

18
Habit 2. Present Effectively

• Since reviewers tend to be harried busy, its
  essential that your papers be presented
  effectively so they will spend time reading
  enjoying them
• There are two general aspects to effective
  presentation
• Concise clear writing style
• Visually appealing typesetting

Harried Reviewer
19
Concise Clear Writing Style

• Learning to write concisely clearly is the
  single most important contribution you can make
  to your future success
• Here are some tips
• Write clearly unpretentiously
• Favor a down-to-earth style rather than a stuffy,
  academic one
• Clarity ease of reading are important in most
  writing, but they're especially important for
  technical writing
• Avoid passive voice
• Break up long sentences paragraphs
• Use everyday words make it sound natural
• Read a book or two on writing style, e.g.
• Strunk White's The Elements of Style
• Williams' Style Ten Lessons in Clarity and Grace
• Trimble's Writing with Style Conversations on
  the Art of Writing

Take heart! The world is full of people who are
smarter than you, but few of these people can
convey what it is they know effectively via
writing
20
Visually Appealing Typesetting

• Good typesetting is a matter of skill in page
  layout, typography, and graphics, not to mention
  printer quality
• Use the best software tools (word processor,
  drawing editor, etc.) you can
• Make liberal use of drawings to illustrate key
  points
• You may not think you need any drawings, but
  chances are you do
• At the least they break monotony, and at best
  they'll get your point across as no amount of
  explanation can

• Not all drawings have to be formal UML diagrams
• Informal drawings and even sketches often convey
  just as much information more
• If you are artistically challenged,'' then have
  someone else do the drawings for you

21
Habit 3. Iterate Continuously

• You won't get your paper right the first time
• You won't even get it right the first five times
• In fact, you'll probably never get it totally
  right
• Paper writing is an on-going process
• Expect to write re-write your papers many times
• Even though lots of examples of good papers
  books to help you write them, technical paper
  writing (like any other kind of writing) is still
  an iterative process
• The best way to improve is to practice, practice,
  practice!
• Don't look for perfection in one paper before you
  begin work on the next
• Remember, papers don't exist in isolation they
  affect one another
• As with any iteration, your efforts should
  converge at some point, but that's just the point
  where the papers have stabilized enough to let
  other people read, understand, comment on them

If your advisor wont help you improve as a
writer you may need a new advisor
22
Habit 4. Collect Integrate Feedback

• Have your colleagues review your papers before
  submission
• Hold writers workshops in your research groups
• www.cs.wustl.edu/schmidt/writersworkshop.html
• Respond to reviewer comments when they arrive
• This should be a formal process
• Once the feedback starts rolling in, be prepared
  to hear the worst
• Often something that seemed thoroughly
  comprehensible to the authors thoroughly
  confounded someone else
• The negative feedback can be disheartening,
  especially at the beginning when you're most
  vulnerable also most likely to receive it from
  people
• While some criticism might not be valid or might
  result from a simple misunderstanding, most of it
  will probably be legitimate
• Give your reviewers the benefit of the doubt
  bend over backwards to make them happy
• You may end up making many, many more people
  happy in the long run

. .
23
The Paper Evolution Process
Tech Report
Workshop

• The ultimate goal of any research activity should
  be to publish it in an top archival journal
• This journey is often an incremental process
• i.e., tech report to workshop to conference to
  journal
• Its important that each variant be significantly
  better

Conference
Journal
Dont submit the same work to multiple venues
simultaneously dont plagiarize!!!
http//www.schneier.com/blog/archives/2005/08/plag
iarism_and.html
24
Concluding Remarks

• Adopting these habits won't guarantee your
  success as a paper writer, of course
• Nor is this list exhaustive
• But at least it should help you focus your
  efforts profitably
• The better your papers are, the more impact
  they'll have the more opportunities youll have
  in your career

A computer scientist is equally a scientist a
writer -- expend the effort to learn the other
half of your profession
25
Parting Thought
Not on sad Stygian shore, nor in clear sheen Of
far Elysian plain, shall we meet those Among the
dead whose pupils we have been Yet meet we
shall, and part, and meet again, Where dead men
meet, on lips of living men.