About me
For students
How to write a computer science paper
Writing tips
Short intro to JBoss and EJB
Short introduction to Subversion
Getting started with LaTeX
LaTeX notes
Software notes

How to write a computer science paper

You can find several resources on how to write a scientific paper on the Internet. Some good ones of them are linked on my main guidance page on writing a thesis or paper. This page summarizes some core issues on that topic. These issues apply to writing a master's or PhD thesis as well. However, the requirements to the contribution differ greatly between these kinds of publications as does the number of pages you are allowed to write (usually about 100 pages for a thesis and only about 8–10 pages for a full research paper).


First and foremost decide on what precisely is the contribution of your paper over the state of the art. If you think you have several contributions, focus on the most important one. It may be that you can add one or two contributions as side topics, but in general you should focus on the most important one in order to keep your paper focussed. As a side note: If you think you have several contributions for a single paper, you should probably invest in researching state of the art and related work more thoroughly.

When you know your contribution, think of a good title and sketch a straight argumentation line (red line) from the problem over the solution to the proof. This will help you to formulate the abstract and keep your paper focussed.


Find a short and precise title for you paper exactly matching the content. It's worth investing time into this matter as the title will be that part of the paper by which it will be referenced (in case it gets published).


The abstract is one of the most important parts of the paper. You have only a few seconds in order to catch the reader's interest. A bad abstract may already move you towards the rejection side in the reviewer's decision process.

In your abstract, establish the context, motivate the problem, briefly describe the solution, and present the results of your work. Ideally, use one (short) sentence for each of the previously mentioned content items in order to keep your abstract short. Overall, this should be a short summary of the whole content of your paper, including results. See the abstract as a personal challenge for each of your papers.

Writing the abstract in advance helps in getting your paper focused. However, re-read the abstract after you finished the paper. You will generally rewrite it after that for improvement.

Paper structure

Generally, papers follow the structure given below:

  1. Introduction: introduces into the context of the paper and leads to the problem.
  2. State of the art: describes the current state of the art in the area of your paper.
  3. Problem motivation: precisely points to the problem addressed by the paper. Sometimes, this part is already included in the introduction.
  4. Solution: describes how you solved the problem.
  5. Proof / Evaluation / Discussion: You have to prove that your solution solves the problem indeed. Depending on the paper, this will look different. In theory papers, you usually have a formal/mathematical proof while in empirical papers you usually present the analysis (quantitatively and qualitatively) of a prototype implementation. However, you should know best how to prove your work.
  6. Related work: briefly summarizes the work of others in the same area of your paper, e.g., addressing the same problem or having a similar solution to a potentially different problem. Moreover, set the related work in relation to your own work, describing what is similar and where the differences are. Please note that it is bad practice to make the work of others bad in order say that you do it better. Compare your work to the work of others in an objective/neutral way – and be honest!
  7. Future work: state your ideas of what you estimate could be done in the future in order to further improve on the addressed problem. You may also state further problem areas you identified to be researched in the future. This section is not mandatory, but may be useful for others in identifying interesting new research problems.
  8. Conclusion: concludes the paper by again pointing to your key message. In contrast to the abstract, you can build on the fact that the reader now knows the content of your paper.

These items do not necessarily have their own section and some of them might be combined, e.g., state of the art and problem motivation. However, the listed items should be present in your paper as they are usually necessary to understand your work and your contribution and a reviewer of a conference or journal will look for them.

The question of whether related work comes at the end or together with the state of the art section has to be answered for each paper individually. Sometimes it fits better at the beginning and sometimes better at the end. If I don't need to build on the content of the related work section, I usually keep it at the end as it allows for better comparison of the own and related work.

For the section headlines, try to be as specific as possible and don't use the generic titles where possible, e.g., "The XYZ-Framework" is much better than just "Solution" as it gives your solution a name. Some of the sections such as "Related Work" or "Conclusion" will of course be named that generic way.