CS Research and Writing Guide

This guide was written for students doing CS honors research and writing honors theses. It is also applicable to students doing research projects and writing research reports in CS courses with large, independent course projects.

The thesis describes your research work in the context of other related work. In particular, it describes the problem you are solving, your solution, your experiments and results, your contribution to the general research area, related work in the area, and future directions for your work. Even though you may have spent the majority of your time writing code, a thesis does not contain a description of, nor does it contain a copy of, your project source code. A typical honors thesis is about 20-30 pages in length. A typical research paper is 10-15 pages in length.

Contents:

Getting Started and Related Work Resources
Thesis Organization
Writing Style Guidelines
Unix Document Producing Tools bibtex and latex, xfig, gnuplot, xgraph, xwd, etc.
Running Experiments: tools for using lots of resources in a nice way

Research and Writing Links

Getting Started

  1. Create an annotated bibliography.
    As you read research papers related to your work, it is a good idea to create and update an annotated bibliography. The idea is to write a short summary of each paper as you read it so that you can more easily remember the ideas in the paper. This will be useful as you develop your own work and as you write the related work section of your thesis. In each paper's summary you should highlight the main ideas and contributions, the strengths and weaknesses of the work, and how it compares to your work. See the bibtex section below for an example of how to format annotated bibliography entries that can be referenced in a latex document. Some ways to find related work:
  2. Look at some example theses
    Look at past students' theses as a guide for writing your own. These are available in the CS office from the department AA.
  3. Talk to your thesis advisor.
    Talk to your thesis advisor early and often about what he/she expects from your thesis.

Written Thesis Organization

Your thesis advisor may have more specific guidelines for how to organize your thesis. The following are general guidelines for organizing a thesis (these guidelines also apply to to any CS research paper like a course project report, or journal or conference articles):
  1. Abstract
    The abstract is a brief summary of your work. It should be a high-level overview of the big ideas, motivations, and results of your work. It should be written to make the reader want to read the rest of your thesis. Briefly state the basic contents and conclusions of your paper: the problem you are solving, why the reader should care about this problem, your unique solution and/or implementation, and the main results and contributions of your work. An abstract should be 500 words or less.

  2. Introduction
    The introduction is the big picture of your work: what, why, and how. It should set the stage for explaining what you did. Here you should summarize the background information that the reader will need in order to understand the relevance of your work. You may assume a GENERAL familiarity on the part of your reader with the area of your work, but don't assume the reader has any prior knowledge of your particular project.

    An introduction should include:

    • Definition/statement of problem you are solving
    • Motivation of your work (why should a reader find your work important/interesting)
    • High-level description of your solution (including any novel techniques you devised and your contributions to the research area)
    • Summary of the main results of your work and conclusions from your work

  3. Related Work
    This is an essential part of a thesis; discussing related work is a good way to put your work in context with other similar work and to provide a way for you to compare and contrast your work to other work. It is not enough to just site related work; you need to explain to your reader in what way it is related to your work. A Related Work section in a thesis is typically longer, more detailed, and more complete than a journal or conference paper's Related Work section.

  4. One or more sections describing your solution
    In this section you describe the actual details of your thesis work. You should explain clearly what questions you were trying to answer, as well as how you decided to go about finding the answers, and you should describe in detail your solution and how it answers these questions.
    • Details of the problem you are solving
    • Details of your solution and the project's implementation
    • Discussion of how your solution solves the problem

  5. Experimental and/or Theoretical Results demonstrating/proving your solution
    This section should thoroughly describe the results you obtained. Whenever possible or appropriate, you should try to present your results pictorially using graphs or histograms. In addition you must explain your results; tell the reader what all these data mean.
    • Explain the tests you performed (and why)
    • Explain how you gathered the data and describe the environment in which you gathered data (include description of any simplifying assumptions you made, any software you wrote or used to run your experiments)
    • Present your results. Choose quality over quantity; the reader will not be impressed with pages and pages of graphs and tables, instead s/he wants to be convinced that your results show something interesting and that your experiments support your conclusions.
    • Discuss your results! Explain and interpret your results (possibly compare your results to related work). Do not just present data and leave it up to the reader to infer what the data show and why they are interesting. Negative results are interesting too; don't try to hide bad results, but do try to explain them.

  6. Conclusions & Future Directions for your work
    Conclude with the main ideas and results of your work. Discuss ways in which your project could be extended...what's next? what are the interesting problems and questions that resulted from your work?

  7. References
    At the end of your paper is a Reference section listing all the papers that you cited in your thesis.

  8. Don't include your project source code
    Even though you may have spent a long time writing code for your project, and even though you may be very proud of the beautiful, efficient code you wrote, a description of, or a listing of, your source code does not belong in a thesis. It may, however, be appropriate to include a description of your implementation at a higher-level. Typically, a description like this would appear as a short paragraph in the Results or Implementation sections of your thesis. The idea is that this high-level description helps to define what you did or helps to explain your testing environment.

Writing Style Guidelines

  1. Write in a top-down style
    First present the the high-level ideas of your work, then expand them. This applies to the overall organization of your paper as well as the organization of sub-sections and individual paragraphs. For example, by reading just your abstract a reader should get a high-level idea of what problem you are solving, how you solved it, why it is interesting, and how well it solved the problem. If the reader then reads your Introduction, s/he will understand these in a bit more detail, and so on.

  2. Conclude each paragraph, section and entire paper
    Each chunk of your paper whether it be a paragraph, a sub-section, a section, or the entire paper should have a conclusion. For example, each section should be written as follow:
    • 1st paragraph: main idea of section
    • middle paragraphs: expansion of the idea (further explanation or elaboration of the topic)
    • concluding paragraph
    Each section of your paper should be organized as: high-level important points first, details second, summarize high-level points last.

  3. Use ACTIVE verbs and 1st person plural when referring to your work:
    We present, we show, we demonstrate, ...

  4. Define terms, and always define them before using them

  5. Use figures
    Use diagrams to help explain system design, and graphs or tables for presenting results. If your project has a GUI component, then your paper should have some screen dumps of your interface (look at the man page for xwd, and use xv to covert to gif or jpg formats). Typically, you will have at least one figure showing the high-level design of your solution.

  6. Write well
    It may seem nit-picky, but using correct grammar and spelling is very important. Don't submit a sloppily written paper containing lots of spelling or punctuation errors or tortured grammar. You want people to be impressed with the ideas in your paper and to take you seriously, not to be amused by the level of your English. Nothing puts your work in a bad light faster than sloppy writing, so make the effort to proofread what you've written.

Bibtex and Latex

You are welcome to use any software you would like to write your thesis. On the CS lab machines, you can use latex and bibtex to format your thesis. Examples of using latex and bibtex, importing figures, and starting point latex documents are available here: /home/newhall/public/latex_examples. To see an example bibtex file and a latex file that cites its entries look in: /home/newhall/public/latex_examples/paper/

See my help pages for information about Tools for creating documents, graphs, and figures . Some of the content includes:

Running Experiements: using lots of resources in a nice way

If you plan to run experiments that use most, or all, of our computing resources, then read through the CS Project Etiquette page off the CS Help pages.

Also, you should run your experiements on CS lab machines when they are not heavily used by other students (durring class time and right before hw assignments are due). To do this, you may want to start your experiments early in the morning when you are likely to be asleep. You can use cron to run a job for you at some specified time. Look at the man page for crontab to see how to submit a cron job (you can use this to run a script of all your experiements at off peak times). When you add an entry to crontab make sure to add it so that you specify the month and day of the month as well as other time fields (this way, if you forget to remove it, it only runs once every year rather than once every night). You should, however, remember to run crontab -e after your cron job runs and remove it.

Some other sources of writing advice