A guide to writing good software engineering papers Tracy Hall
Brunel Software Engineering Lab (BSEL)
Slide 2
The lifecycle of a research paper
Slide 3
Slide 4
Slide 5
Slide 6
Slide 7
Slide 8
Slide 9
Agenda Introduction Paper content Publication strategies
Structure of papers Style of writing Dealing with reviews Dealing
with success! References
Slide 10
Introduction Papers are important trophies for researchers!
Outputs CV H-index But papers also: help move knowledge on. convey
our new ideas to the community
Slide 11
Publication strategies Workshop, conference or journal paper?
Short or long paper? 2*, 3* or 4* venue? Software Engineering
ConferencesSoftware Engineering Journals FSE, ICSETSE, TOSEM ESEM,
ICSME, GEKKOJSS, IST, ESE MSR, PROMISE, EASESQJ, SEP ICSE
workshopsIET
Slide 12
Content So what????? Must have something valuable to present!
What is your idea? Why is it important??? What *problem* have you
solved. Not just heres a story of what Ive done Have a very clear
message that is maintained in a simple thread throughout right from
the title.
Slide 13
Structure of papers Title and authors Abstract Introduction
Background Methods Results Threats to validity Discussion
Conclusions References
Slide 14
Title and authors Keep the title: Short Informative Engaging
Eg. Requirements problems in twelve software companies: an
empirical analysis T Hall, S Beecham, A Rainer, IEE
Proceedings-Software 149 (5), 153-160, 2002Requirements problems in
twelve software companies: an empirical analysis Sort out author
list asap Be aware of publications rules on authors (e.g. IEEE and
ACM)
Slide 15
Abstract Write first Use a structured abstract: Objective
Background Methods Results Conclusions Or use Kent Becks 4 sentence
approach: 1. State the problem. 2. State why the problem is a
problem. 3. A startling sentence. 4. The implication of the
startling sentence.
Slide 16
An abstract done in this style would be: The rejection rate for
OOPSLA papers is near 90%. Most papers are rejected not because of
a lack of good ideas, but because they are poorly structured.
Following four simple steps in writing a paper will dramatically
increase your chances of acceptance. If everyone followed these
steps, the amount of communication in the object community would
increase, improving the rate of progress. (Kent Beck)
Slide 17
Introduction Section Sell your idea, The first sentence is
important Structure: What, why and how. State your explicit
contributions Aims and research questions with motivations
Paragraph describing the structure of the paper
Slide 18
Background Section Set the context to your work with the
current-state-of-the art: Describe the problem, and why it is
important and interesting. Try to use examples. Describe your
solution Discuss how your solution solves the problem. Throughout
cite *relevant* work. Make sure that the work you cite is timely.
See Simon Peyton Jones guide
Slide 19
Methods Section Explicitly describe methods that are:
Motivated/justified Thorough Rigorous Validated Your methodology
must be repeatable Replication package (data/scripts etc.) should
be provided
Slide 20
Results Section Be factual Present plenty of clear demographic
data to contextualise your results. Dont discuss the results Use
tables/graphs etc. Clearly explain how to interpret figures
presented. Dont expect readers to take results on trust
Slide 21
Discussion Section Discussion is about squaring the circle
Answer your research questions Discuss the: Significance of your
results, fit of results, use of results, future work Throughout
cite relevant references
Slide 22
Threats to validity Section Address types of threat: Construct
validity Internal validity External validity Show how these threats
have been mitigated. Provide reasons why these threats do not
negate the results.
Slide 23
Conclusions Section Summary of everything you have said
Emphasise the important: Contributions of your results Uses of your
results Try to end on a strong point about the future
Slide 24
Writing style Dont over-claim. Provide evidence of claims. Dont
be chatty, be authoritative. First person voice?! Use short
sentences. Use plain English. Eliminate typos and poor grammar.
Eliminate repetition, but Include proper signposting. Take care
with references. Stick to formatting guidelines. Try to include
graphics/tables/diagrams/pictures. Have a gold standard paper in
mind as your personal template. Please read Norman Fentons
guide!
Slide 25
Dealing with reviews Dealing with rejection is a core feature
of a researcher Get as much feedback on your work as possible.
Before submission. Believe the feedback Try to quickly get over the
injustice of what reviewers have said Ignore the rudeness of some
reviewers. Believe that there is great value in the reviewers
comments. Always address reviewers comments. DONT GIVE UP!!!! Be
honest and *kind* as a reviewer yourself!!!
Slide 26
Dealing with success! Once accepted: Consider how to publicise
an accepted paper to improve its exposure Publish your paper on
open-access Extend conference papers into journal papers
Slide 27
References Simon Peyton Jones, How to write a great research
paper, Microsoft Research, Cambridge Norman Fenton, Improving your
Technical Writing Skills
http://www.eecs.qmul.ac.uk/~norman/papers/good_writing/Technical%20writing.p
df
http://www.eecs.qmul.ac.uk/~norman/papers/good_writing/Technical%20writing.p
df Kent Beck, How to Get a Paper Accepted at OOPSLA
https://plg.uwaterloo.ca/~migod/research/beckOOPSLA.html
https://plg.uwaterloo.ca/~migod/research/beckOOPSLA.html Mary Shaw.
2003. Writing good software engineering research papers:
minitutorial. In Proceedings of the 25th International Conference
on Software Engineering (ICSE '03). IEEE Computer Society,
Washington, DC, USA, 726-736.
