CS Programming Project Writeup and Proposal Checklist
Writeups (or Technical Reports)
There should be a hypothesis, problem, or a
plan of work motivated by curiosity, by the
problem statement, by reading. The technical report:
documents why the hypothesis or problem is interesting and important
describes the technical approach used to verify or falsify the
hypothesis, solve the problem, or complete the work plan
describes the results, preferably with graphics and figures, less
preferably with tables, least preferably with prose.
discusses the results; their relation to the hypothesis, plan, or
problem, their interesting points, their predictable points, what
questions they raise, and what to do next.
- Descriptive Title
- Concise, accurate Abstract
These are not all necessary (Prior work could be included in the
intro, future in the discussion). They may not be sufficient either,
in that different aspects of the work may need their own main
sections, especially in a group project with separate efforts amongst
the members. But almost always the format resembles the following.
- Introduction, Background, Motivation, Goals -- What's the problem or hypothesis, why important,
what's the problems's history?
- Prior Work (yours and others') -- what's the current state of knowledge and
- Methods -- hardware, software, mathematical tools, experimental setup.
- Results -- no editorializing, just the facts. Graphs and tables are best.
A VERY BAD MISTAKE is to assume the reader or grader wants
to, or even can,
compile and run your code to see your results! NEVER DO THIS!
Too much can go wrong. Devote an appendix to transcripts of
interactions, to sample inputs and outputs, whatever it takes to show
what your program does! Imagine it's a live demo and you want to show off
all the features. Repeat: Include Your Results Explicitly Or Else.
- Discussion -- NOW you can editorialize. Is hypothesis verified or falsified? What's still unclear? How are results to be interpreted?
- Future Work -- what further work do the results motivate, what further
hypotheses spring to mind? How can current work be strengthened or carried further?
- References -- related work from the literature backing up statements and
justifying your approach. More is better.
Nothing deep, just good writing!
Don't start abstract with ``this paper''. Don't
peeve CB! . He's
Stay away from passive if it obscures who did
what. Eschew informality of all sorts. Use complete sentences.
Read your paper aloud to see how it sounds. Spelling shouldn't be a
problem nowadays but... Use paragraphs and sectioning to organize
things. Pick one term for a concept or artifact and use it
consistently throughout (e.g. Not: ``The system, our project, the
program, GRIFLOG...'' in various places). If you use mathematics,
make sure it reads like English. Reference all figures and tables in the text,
and make sure they all have self-explanatory captions. Assume your reader
is looking for the first excuse to stop reading (e.g. "doesn't reference
my work"), and that the paper will be read in this order: title,
abstract, conclusions, references, and only THEN if it passes all the readers' filters will it be looked at somewhat in order.
Proposals are all alike, from proposals of marriage (to the Father of
Bride) through sales pitches, proposals for funding, and proposals for
In every case you need to convince someone that you are the person to
a particular thing.
Form and Content
For a project,
your proposal describes the background, and the
what, why, how, current state, schedule of your project.
You can make up zippy titles for these sections -- the main thing here
is content. As always, graphics and diagrams to show you are
organized and you CAN organize are quite good.
- Background and Motivation:
What is the current state of knowledge or achievement
concerning the problem you want to work on? (You can leave details to
the ``Prior work'' section). What does the reader
need to know to appreciate the motivation for and importance of the
problem? What are the (possibly currently open) questions you'll be
investigating, why are they interesting or important? Why should I
keep reading this proposal?
- Prior work:
What has been done so far and by whom?
This section is an annotated bibliography of references to the literature and
explanations of what lore and techniques are out there and how they
relat to your problem. What was left undone that you are going to do,
or what body of work is your project closest to and how might it differ?
Sometimes this section is incorporated into the ``Background and
A super good idea if you can do it: for work you consider original,
find a set of axes (one or two,
that describe the domain of your problem. (Luckily, you get to make
these descriptive concepts up.) Then make a table using those axes.
Divide up the prior work into the appropriate cells. There is a cell
that is sparsely populated or totally empty. Guess what? That is what
you are propsing to do! The art comes in synthesizing the state of
the art so you can come up with axes that make sense and that
leave a hole for your proposed topic. For example, say computer
vision could use inputs that are black and white or color (this is one
and that are still or moving images (another axis). So you have a 2x2
table. If all the work
so far was in still B&W, still color, motion B&W, and there wasn't any
in motion color, you could populate the proper cells with the proper
references, and the empty cell demonstrates first how your work
fits in, and second that it MUST be worth doing since there's this hole.
What are you proposing to learn,
demonstrate, do, solve, try? Be specific. What question are you
trying to answer? How will you know you've succeeded or failed?
Remember there's a famous AI paper entitled ``I've seen your demo. So
what?'' Ideally, you are trying to come to some conclusion about a
hypothesis, not just, say, ``write some code to do X''.
- How: How are you going to proceed? What subproblems, subtasks,
are involved? How will you organize your approach to them? Flow
diagrams are good in this section, showing who is going to do what in
what order, what can be done in parallel, etc. (e.g. team
work in parallel for a while, integrate, test, experiment in parallel,
meet and discuss, rewrite,
take data, do statistics, write report).
Which problems are easy and which are hard?
- Current Assets: This is related to prior work, yours and
others'. If you have done a pilot project, if this is an extension of
a homework problem, if there is existing code you can or will use, if
another professor is interested....All these and similar
considerations are useful to give the reader confidence that you are
not just jumping off a cliff. Quite often there are MORE assets out
there than the proposer knows about, and so this list is a chance for
the reader to make suggestions for substantial shortcuts.
Personnel are relevant too: what is the composition of the team; how
does this proposal play to their strengths? Put another way, why
should the reader believe this team can do the job?
- Schedule: A list of milestones, possibly related to the steps in
the ``How'' section, with dates for expected completion.
- References: WARNING -- these are often read FIRST.
You need the usual bibliography in good academic style listing
all the literature you cite in the proposal. It is
suspicious-to-deadly if there are
That says to the reader: These guys aren't
serious players, they don't know what's been done, they are
doubtless clueless about how to go about things, and will spend all
their time learning or reinventing stuff. If for some reason the
proposal is so far out there that no one has ever tried to work on a
related problem, that had jolly well better be fully explained in
the ``There IS no Prior Work'' section.
This page is maintained by
Last update: 3.31.05.