Writing Technical Cases

Writing Technical Articles

The notes below apply to technical papers in computer science and electrical engineering, with emphasis

on papers in systems and networks.

Read Strunk and White, Elements of Style. Again.

Give the paper to somebody else to read. If you can, find two people: one person familiar with the

technical matter, another only generally familiar with the area.

Papers can be divided roughly into two categories, namely original research papers and survey papers.

There are papers that combine the two elements, but most publication venues either only accept one or

the other type or require the author to identify whether the paper should be evaluated as a research

contribution or a survey paper. (Most research papers contain a "related work" section that can be

considered a survey, but it is usually brief compared to the rest of the paper and only addresses a much

narrower slice of the field.)

Research Papers

A good research paper has a clear statement of the problem the paper is addressing, the proposed

solution(s), and results achieved. It describes clearly what has been done before on the problem, and

what is new.

The goal of a paper is to describe novel technical results. There are four types of technical results:

1. An algorithm;

2. A system construct: such as hardware design, software system, protocol, etc.;

One goal of the paper is to ensure that the next person who designs a system like

yours doesn't make the same mistakes and takes advantage of some of your best

solutions. So make sure that the hard problems (and their solutions) are discussed

and the non-obvious mistakes (and how to avoid them) are discussed. (Craig

Partridge)

3. A performance evaluation: obtained through analyses, simulation or measurements;

4. A theory: consisting of a collection of theorems.

A paper should focus on

describing the results in sufficient details to establish their validity;

identifying the novel aspects of the results, i.e., what new knowledge is reported and what makes

it non-obvious;

identifying the significance of the results: what improvements and impact do they suggest.

Paper Structure

Typical outline of a paper is:

Abstract, typically not more than 100-150 words;

Introduction (brief!): introduce problem, outline solution; the statement of the problem

should include a clear statement why the problem is important (or interesting).

Related Work (or before summary). Hint: In the case of a conference, make sure to cite the

work of the PC co-chairs and as many other PC members as are remotely plausible, as well

as from anything relevant from the previous two proceedings. In the case of a journal or

magazine, cite anything relevant from last 2-3 years or so volumes.

1 of 9 9/11/01 1:37 AM

Writing Systems and Networking Articles wysiwyg://554/http://www.cs.columbia.edu/~hgs/etc/writing-style.html

Outline of the rest of the paper: "The remainder of the paper is organized as follows. In

Section 2, we introduce ..Section 3 describes ... Finally, we describe future work in Section

5." [Note that Section is capitalized. Also, vary your expression between "section" being the

subject of the sentence, as in "Section 2 discusses ..." and "In Section, we discuss ...".]

Body of paper

problem

approach, architecture

results

The body should contain sufficient motivation, with at least one example scenario,

preferably two, with illustrating figures, followed by a crisp generic problem statement

model, i.e., functionality, particularly emphasizing "new" functionality. The paper may or

may not include formalisms. General evaluations of your algorithm or architecture, e.g.,

material proving that the algorithm is O(log N), go here, not in the evaluation section.

Architecture of proposed system(s) to achieve this model should be more generic than your

own peculiar implementation. Always include at least one figure.

Realization: contains actual implementation details when implementing architecture isn't

totally straightforward. Mention briefly implementation language, platform, location,

dependencies on other packages and minimum resource usage if pertinent.

Evaluation: How does it really work in practice? Provide real or simulated performance

metrics, end-user studies, mention external technology adoptors, if any, etc.

Related work, if not done at the beginning

Summary and Future Work

often repeats the main result

Acknowledgements

Bibliography

Appendix (to