A guide to writing good software engineering papers Tracy Hall Brunel Software Engineering Lab (BSEL)

The lifecycle of a research paper…

Agenda Introduction Paper content Publication strategies Structure of papers Style of writing Dealing with reviews Dealing with success! References

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

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

Content So what????? Must have something valuable to present! What is your idea? Why is it important??? What *problem* have you solved. Not just here’s a story of what I’ve done… Have a very clear message that is maintained in a simple thread throughout – right from the title.

Structure of papers Title and authors Abstract Introduction Background Methods Results Threats to validity Discussion Conclusions References

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), , 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)

Abstract Write first Use a structured abstract: Objective Background Methods Results Conclusions Or use Kent Beck’s 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.

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)

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

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

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

Results Section Be factual Present plenty of clear demographic data to contextualise your results. Don’t discuss the results Use tables/graphs etc. Clearly explain how to interpret figures presented. Don’t expect readers to take results on trust

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

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.

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

Writing style Don’t over-claim. Provide evidence of claims. Don’t 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 Fenton’s guide!

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. DON’T GIVE UP!!!! Be honest and *kind* as a reviewer yourself!!!

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

References Simon Peyton Jones, How to write a great research paper, Microsoft Research, Cambridge Norman Fenton, Improving your Technical Writing Skills df df Kent Beck, How to Get a Paper Accepted at OOPSLA Mary Shaw 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,