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
A typical research paper is 10-15 pages in length.
Getting Started and Related Work Resources
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
- 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:
- 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 Bridget.
- 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):
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.
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
- 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.
- 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
- Experimental and/or Theoretical Results demonstrating/proving your
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.
- 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?
At the end of your paper is a Reference section listing all
the papers that you cited in your thesis.
- 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
- 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
- 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:
Each section of your paper should be organized as: high-level important points first, details second, summarize high-level points last.
- 1st paragraph: main idea of section
- middle paragraphs: expansion of the idea (further explanation or
elaboration of the topic)
- concluding paragraph
- Use ACTIVE verbs and 1st person plural when referring
to your work:
We present, we show, we demonstrate, ...
- Define terms, and always define them before using them
- 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
- 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
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
bibtex to format your thesis.
Examples of using latex and bibtex, importing figures, and starting point
latex documents are available here:
To see an example bibtex file and a latex file that cites its entries look in:
See my help pages
for information about
Tools for creating documents, graphs, and figures . Some of the content includes:
- latex and bibtex examples, help, and tutorials. and openoffice
- xfig and gimp: for drawing and editing
figures that can be saved in many differnt formats that can be
incorporated into webpages, latex documents, etc.
- gnuplot and xgraph to create line and bar
- file format conversion tools to convert
files from one format to another, and xwd
(X Window Dump) to capture the contents of a window to an image file.
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