Editor's Note: How to Write Research Articles in Computing and Engineering Disciplines
FEBRUARY 2010 (Vol. 21, No. 2) pp. 145-147
1045-9219/10/$31.00 © 2010 IEEE

Published by the IEEE Computer Society
Editor's Note: How to Write Research Articles in Computing and Engineering Disciplines
Ivan Stojmenovic
  Download Citation  
Download Content
PDFs Require Adobe Acrobat
Writing contributions in a form that other people can understand is a very slow process. The purpose of this editorial is to serve as a guideline for making research presentations as easy to comprehend as absolutely possible. Perceived simplicity of any original idea is its ultimate advantage.
The key advice to a successful presentation is to repeat the description of main contribution four times: in the title, abstract, introduction, and text. That is, to make readable, appealing, and as complete as possible versions of the work using the order of 10, 100, 1,000 and 10,000 words. Each of them should be self-contained and complete to the greatest possible extent. This corresponds to the decreasing portion of readers for corresponding parts of the article. To the extent possible, each of these parts should address, in this order: the problem statement, existing solutions, the new solution(s), assumptions and limitations, analysis, simulation, and comparison with the best competing solutions.
Research is a problem solving exercise, differing it from development, implementation, or another type of work. Consequently, any research article should make a clear problem statement.
The selected title of an article should describe the main contribution and the essence of the basic ideas used. The abstract is the most important part of a research article. Instead of listing topics covered in the article, the abstract should convey the essential information found in the paper. The author should make an effort to claim the contribution properly at the most visible place, in the abstract. It should have the following structure (each part with flexible length):

    1. A problem statement of the research under consideration.

    2. A short list of existing solutions and what their drawbacks are, from the point of view of the above defined problem statement.

    3. The essence of the proposed solution, and why it is expected to be better under the same conditions.

    4. What type of analysis (theoretical, experimental, simulations, implementations, etc.) was done to show that the proposed solution is really better than any of the existing ones, from both the performance and the complexity points of view.

    5. What the major qualitative and/or numerical highlights of the analysis are.

A clear abstract is the key to having the work properly credited in other people's work. Literature reviews of forthcoming papers could simply "cut and paste" the abstract there. The limited space is too often simply wasted by writing general sentences about the field and excessive explanations about the problem that should be part of the introduction.
This structure is also suitable for performance evaluation types of articles, where the problem is to determine the best protocol under various conditions. Existing performance evaluations are existing solutions. What are their drawbacks? Why is this evaluation novel, and what new insights about the protocols are gathered? How does performance evaluation data in this article compare to previous ones?
In brief, the introduction of a paper should present the same content, in the same order, as the abstract, with more space provided. There is also space to address some possibly additional items, such as a general overview of the field and motivation. The introduction should be sufficiently self-contained to comprehend the essence of contribution for people generally working in the area. They should be able to correctly understand what the important aspects of the contribution are, and how good the contribution is. The problem statement needs precise definition, but very technical definitions and statements should be avoided (and presented in later text). Instead, good intuition for the involved definitions or facts should be presented and even illustrated if desirable. Existing solutions and their criticism should be limited normally to only those directly relevant to the contribution. Conditions, context, assumptions, and limitations of the research done should be stated. Under what conditions and scenarios is the new solution the best one? The structure and content of the rest of the document is normally outlined at the end of an introduction in a single paragraph. It should also state the preliminary conference version of journal submission, if any. The introduction should therefore attempt to present a full version of the article in a concise, readable, and intuitively clear form.
Section 2 should give a full literature review. It should collect known results relevant to the problem stated, whether or not they are used in the proposed contributions. It is important to underline the need for a clear cut, clear separation line, between existing work and new ideas being presented in the paper. There are in fact three such separation lines: one in each of the abstract, introduction, and the most important one between the literature review section and the rest of the text.
In some cases, the paper may present minor variations, with major consequences, of an existing solution. In this case, the contribution may look large in the essence, but short in text. It is still advisable to separate these two, even if it means a single paragraph of text in describing novel ideas.
One of the major pieces of advice is to do a really thorough literature review on the suggested topic (which will be quite rewarding in the long run). This advice stems from a scientific view of doing research, where the best solution is searched for given model and assumptions. There also exists an innovation view of research, where a good solution is desired for a practical problem. In the scientific point of view, the new solution should be compared with competing solutions, the best existing solutions under particular assumptions, metrics, and models. In the innovation viewpoint, the emphasis is rather on the validation of the new idea, without comparing it with something else that exists. A very frequent problem, however, is to mix the two approaches by attempting to solve a practical problem by using its simple modeling (every model is incorrect, but some of them are useful), but evaluating it in a different "practical" model. Another issue is comparison with solutions that use different metrics and assumptions from the one used in new solution (unfair advantage).
Every discussed reference should be related to the stated problem and contribution in one of several ways: It does not exactly solve the same problem; it solves the same problem, but makes different assumptions about the system; it does not meet certain desirable properties; it has some additional limitations; or it makes the same assumptions, but does not work well under certain important conditions and scenarios that are the primary target of the new solution. A clear statement for each identified solution in this respect is recommended. The space allocated to describing existing solutions should also be "proportional" to its closeness to the new idea and assumptions. Some solutions do not need to be described at all, and a simple convincing statement of why they do not solve the problem at hand may suffice. Other solutions may need a brief description of the general philosophy of the solution before being able to make a similar statement. Otherwise, the solution is a candidate to be a competing one, and requires more attention and space. Such existing solutions need clear, concise descriptions of how they work so that readers can understand a comparison. They are targets for "defeat" by analytical and/or experimental comparisons. There might be a clear reason why a particular competing solution is inferior to the newly proposed one. Inability to "defeat" a particular solution certainly leaves a negative impression on readers.
In summary, the literature review should be a critical one, focused around desired outcome and contribution relevant. It should discuss advantages and drawbacks of known solutions that are relevant to the problem studied, and also discuss the relevance of each reviewed item to the topic studied and newly proposed solutions.
The remaining sections should present new contributions (including conditions, assumptions, and limitations, where appropriate) and their analysis. That is, the very same items listed above should be presented in full, preferably in the same order. Assumptions refer to the simplifications made in the model used so that the solution can be easily understood, while preserving most properties of a realistic model and enabling easy theoretical and/or experimental tractability. Analysis could be analytical, by simulation, or by implementation. Analytical analysis could provide, for example, the proof of validity of the major ideas of the paper. It could lead to a rough estimation of the performance (e.g., message complexity or average/worst time complexity for computation), calculation of parameter values for simulation, and other relevant properties and findings.
After stating the input and the output of an algorithm (which should also be given a mnemonic name), the key idea should be described (clearly and concisely) before discussing steps.
One should always keep in mind that a figure may be worth a thousand words. Important new concepts, and new ideas, should be illustrated by examples and figures as appropriate, to help the reader in understanding them, and to demonstrate one's own understanding of these concepts. Examples should not be trivial, but meaningful and helpful. Figures with examples and diagrams with performance evaluation should not be overly repetitive. A new example is welcome if it offers something essentially different and insightful compared to previous ones. Similarly, additional performance diagrams are welcome only if they offer new performance data, substantially different from data in previous diagrams, for the selected set of parameter values. Repetitive diagrams offering similar value for the analysis should be omitted. The additional size in page length should be justified by the additional contribution, explanation and insight made.
Captions deserve special attention. Reading only the figure captions of the paper should almost substitute for the first rough reading of the entire paper. In the case of simulation diagrams, parameter values and protocol names must be clearly visible and/or listed in the caption. Captions should include title, description of one or more phenomena that deserve attention, explanation (essential reason for observed behavior), and possibly the implication for the protocol/system design.
It is a very difficult task to find a new solution that is best in all circumstances. The primary task in the simulation part of an article is to identify assumptions, metrics, models, and parameter values for which the new solution is better than existing ones. The authors should search for scenarios in which their solution is the best. One should not be overly optimistic about new ideas and make unfounded claims. A smaller but justified claim is better than a large unfounded one.
One of the key pieces of advice is to include all of the possible criticisms of your own idea and contribution directly in the article. It is much better that authors criticize their own work and demonstrate good judgment than to leave such "pleasure" to the examiners and referees. Authors should show that they are in full control of the problem, solutions, and their performance.
Some people read only the abstract and the conclusion. Thus, important things missing in the abstract should be placed in the conclusion section. It could state what has been achieved by the current research, and could discuss and reiterate major advantages and drawbacks of the new solution. The most important part of the conclusion section is to list future work that can be done using the results of the current article. This may offer readers some open problems to study, and such feasible problems could lead to later citations of the article. Sometimes the space can be used to in fact briefly outline some ideas that the author intends to develop further.
One recommendation is to follow a + - + pattern in the introduction and the main text. That is, to start with positive enthusiastic comments about new work and the contribution, then become realistic and list all the drawbacks and limitations, but then finish on a positive note, with a clear statement about the value of the new contribution.
It is important to check if the article has an overall flow, a smooth transition from topic to topic, from familiar information to new information. Within the abstract, introduction, or main text, repetitions should be avoided. One statement and its description should be given in a single, most suitable place in that part of the article.
Writing should be clear and concise. It helps in revealing flaws or new ideas. Shorter and more direct phrases should be used wherever possible. Each concept or algorithm should have a descriptive name. Terms should be normally defined before using them, and should be used precisely and consistently, ambiguities should be avoided, the text should discuss how related concepts are different and/or similar, and passive voice should be avoided. Do not use words like "obviously" or "clearly," which may insult the reader's intelligence.
Finally, after the scientific presentation is deemed acceptable, it is time to pay more attention to the language used and the overall appearance. It is very important to use proper English grammar and sentence structure, and avoid slang and colloquialisms. Misprints must be corrected.
Precision in writing is not easily attained, but one always begins by using the correct word at the proper place and by carefully constructing each sentence. English descriptions and English text has preference to mathematical symbolism wherever possible, for smoother reading. Keep the formulas to a minimum and avoid symbols if ordinary language will do as well. Mathematical symbolism is by its nature intimidating, even to mathematicians. Another good reason to avoid math formalism is the impact of possible misprints. A single misprint anywhere in a fully mathematical formula and the expression can have disastrous consequences for the interpretation and understanding, not only of that particular formula, but the rest of the text. The reader may even be unable to continue reading the article. In some cases, the best approach is to give a math expression followed by its "decoding" with analogous statements in English. However, often it is simply not easy to avoid math symbolism without loosing precision.
The advice so far was applicable to technical papers in general, including "systems" papers. "Systems" papers should discuss the reality, lessons learned, and choices made. Does the paper describe something that has actually been implemented? If so, how has it been used, and what has this usage shown about the practical importance of the ideas? Otherwise, do the ideas justify publication now? What did the authors learn and what should the reader learn from the paper? How generally applicable are these lessons? What were the alternatives considered at various points, why were the choices made the way they were, and did the choices turn out to be right? How realistic are assumptions? Does the formal model, if presented, give new information, and is it supported by any deep theorem?
Writing a good paper is a hard work, but you will be rewarded by a broader distribution and greater understanding of your ideas within the community. Please refer to http://www.computer.org/portal/web/csdl/transactions/tpds for a full version of this editorial.
Ivan Stojmenovic

For information on obtaining reprints of this article, please send e-mail to: tpds@computer.org.