Essay About Technical Papers And Related Work

Writing Technical Cases
Essay Preview: Writing Technical Cases
Report this essay
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 doesnt 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/
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 isnt
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