Brunel Software Engineering Lab BSEL A guide to

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

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 Conferences Software Engineering Journals FSE, ICSE TSE, TOSEM ESEM, ICSME, GEKKO JSS, IST, ESE MSR, PROMISE, EASE SQJ, SEP ICSE workshops IET

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), 153 -160, 2002 �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 1. 2. 3. 4. use Kent Beck’s 4 sentence approach: State the problem. State why the problem is a problem. A startling sentence. 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 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 http: //www. eecs. qmul. ac. uk/~norman/papers/good_writing/Technical%2 0 writing. pdf � Kent Beck, How to Get a Paper Accepted at OOPSLA https: //plg. uwaterloo. ca/~migod/research/beck. OOPSLA. html � Mary Shaw. 2003. Writing good software engineering research papers: minitutorial. In Proceedings of the 25 th International Conference on Software Engineering (ICSE '03). IEEE Computer Society, Washington, DC, USA, 726 -736.