The Community for Technology Leaders

Tips for Software Authors


Pages: pp. 5-7

Abstract—Mission Statement: To be the best source of reliable, useful, peer-reviewed information for leading software practitioners—the developers and managers who want to keep up with rapid technology change.

If you're thinking of writing for IEEE Software, you'll increase the odds of a favorable outcome by following a few simple tips. When authors contact me, I invariably refer them to our former editor in chief Steve McConnell's essay titled "How to Write a Good Technical Article" (September/October 2002). The current issue marks the fifth anniversary of this essay's publication,and Steve's advice is as valid today as it was then. So, this is an opportune time to review his advice and point out what makes or breaks a candidate article.

Target audience

A successful submission begins with understanding what IEEE Software is about. It's a professionalmagazine targeting reflective practitioners who want to be on the leading edge. Such software professionals come from a broad span of backgrounds and orientations. Many are interested in learning from their peers' experiences and exploring topics beyond the boundaries of their core practices. Certainly, they're after timely information.

A rigorous but flexible review

Its rigorous peer review process is one reason IEEE Software is commonly confused with academic publications. However, our orientation, style, content, evaluation criteria, and operation differ significantly from those of research periodicals.

We have more flexibility in selecting content than a research journal but less flexibility than a for-profit trade magazine. We do sometimes publish succinct, scholarly research articleswhen we deem their message relevant to our audience. We also welcome healthy controversy, publishing well-grounded opinion pieces provided they're open-minded toward opposing views. Occasionally we experiment with formats that fall outside our familiar article formulas, but we tend to be more selective than usual with such submissions.

Essential qualities

Of course, we require technical articles to be sound and coherent, but other essential qualities that McConnell stressed are equally important:

  • Focus. Address one topic, avoid tangents, and resist temptation to tackle multiple threads.
  • Clarity. Offer unambiguous take-away messages.
  • Accessibility. Write in a direct, matter-of-fact manner using plain language. Readers who aren't familiar with a specific field's insider jargon must still be able to understand the article.
  • Objectivity. Avoid the perception of self-serving bias, disguised sales pitches, or evangelizing a specific tool or method with blind disregard for its limitations and pitfalls.
  • Humility. Be cautious and modest with claims. Don't overinterpret results. Avoid overgeneralizing from observations and experience.
  • Quick progression. Motivate the work but be sparing with background information. Get to the point after succinctly positioning the work and demonstrating familiarity with the context, referring readers to the literature as necessary.
  • Brevity. Keep the article short, stop when you've delivered the message, and avoid repetition.

Reviewers' criteria

Our reviewer evaluation form had a makeover in early 2007 to emphasize these essentials. We also recently posted supplemental information on the magazine portal to better guide reviewers and authors ({reviewers,author}.htm). Our reviewers use the following criteria when evaluating candidate articles:

  • Is it relevant to practitioners? Do its topic and content reflect current or predicted industry needs? Does the article offer clear, concrete, convincing insights or advice? Are the results it presents supported by practical application?
  • Is it technically sound? Are the arguments logical and coherent? Are the underlying methods scientific and applied correctly?
  • Does the introduction state the objectives in terms that encourage readers to read on? Does it move quickly to its central topic?
  • Is it well organized and focused?
  • Is it concise? Accepted articles seldom exceed eight magazine pages.
  • Is it written in a style accessible and appealing to practitioners? Does it avoid excessive jargon and overly complex or theoretical treatments?
  • Does it avoid shallow or purely anecdotal content such as unsupported or unverifiable claims, clichĂ©, and superficial advice? Does it treat its topic with sufficient depth, rigor, and balance to be of value to readers?
  • Does it cite the work from which it derives and briefly position itself relative to other pertinent work? An extensive literature review, however, isn't required.
  • If it's not a survey or synthesis article, does it present original work? If it derives from previous work, it must contain a significant amount of new material or offer a novel perspective.

The rules on derivative work and such

Failure to disclose derivative work is a showstopper. If your contribution builds on or is inspired by previously published ideas, it's derivative work. In fact, a completely original article is rare. If it builds on others' work, we expect the article to give due credit through proper citation. If it builds on your own previous work, we expect it to briefly explain what's new.

IEEE Software doesn't accept an article if a similar submission under evaluation by another publication reports on essentially the same work. Many publications, as ours, consider multiple concurrent submissions a wasteful and unethical practice. Nor do we accept articles presenting results that have been published in another forum whose scope overlaps with ours. Finally, we normally don't reconsider an article if we've previously rejected it.

These rules might seem restrictive, but they're necessary for a sustainable and fair peer review process.

Practitioner reports and case studies

Experience reports and case studies by practitioners are always popular, but hard to come by. We welcome balanced, impartial articles recounting experiences with emerging and existing processes, practices, techniques, methods, tools, and frameworks. In particular, we're interested in your story if

  • you have valuable insights from your projects or organizations from which other practitioners can learn;
  • you can place these insights in a larger context, indicating their origins and discussing alternative approaches;
  • the insights are deep enough to reveal the approaches' limitations; and
  • you can support them by qualitative or quantitative data.

Special issues and sections

Submissions to special focus sections (or special issues) follow a slightly different process from that for standalone feature articles. We post a call for articles for each focus section at the magazine portal at least nine months before the planned publication date. The submitted articles must fit the focus section's theme, scope, and vision. The guest editors perform an initial screening to assess this fit before a submission undergoes peer review. The best way to gauge your article's suitability for a focus section is to contact the guest editors directly.

Sometimes page limitations force us to reject a good article after the review process. In such cases, the guest editors might recommend that the editor in chief reconsider the article as a standalone feature. We contact the authors when this happens.

Empirical studies

The same essentials regarding style, organization, and progression apply to articles reporting on empirical studies (the standard research paper structure doesn't cut it with our readers). A study needn't be large to deserve consideration, but it must have compelling practical implications. It should focus on results and their implications, referring readers to online sources and other articles for details. Use tables, illustrations, and sidebars when possible. Use a more casual and direct style than you would in a research paper, and avoid repeating self-evident information. Attaching supplementary material might be necessary to give reviewers the information they need for a thorough evaluation.

So how much detail should such an article contain? Our Empirical Results editor, Forrest Shull, advises that you give readers a basic understanding of what occurred in your study and satisfy them of your approach's soundness. Readers need to know such things as your sample size, participant profiles, and any issues that could bias the results. When discussing validity threats, however, be to the point and focus on real ones. Avoid clouding the main findings by discussing peripheral issues. You can skip open research questions and future work.

Another option is to submit your work to Forrest, who wears a second hat as our new Voice of Evidence columnist. He explains VoE submission goals and motivations on page 10 of this issue.

The final stretch

Only rarely does an article get published without a round of fairly involved revisions. A second round of reviews followed by further, more minor revisions is common. In some circumstances, a third review cycle might be necessary. After you've addressed the reviewers' comments, staff editors work with you to polish the article and mold it into magazine style. So, when you're deciding where to put your effort, worry less about form and wordsmithing and more about content.

All this might sound like drudgery, but reviews and editing pay off. You'll be pleased with the outcome.


Further instructions and details about the submission process are available on the magazine's Author Guidelines page ( If you're a first-time author, Steve McConnell's essay (linked from there) is a must-read. I'd be happy to give feedback if you're unsure about an idea or topic. Write to me at

New in this issue

I'm excited about our new department, Voice of Evidence. Editor Forrest Shull and his guest contributors embark on an ambitious endeavor: to harness empirical findings about prominent software development practices, tools, and techniques from the depths of research literature and bring them into reflective practitioners' plain view.

Also, Martin Robillard joins the editorial board as associate editor in chief for the new Development Infrastructures area. He'll grow and oversee the magazine's coverage of software development tools, environments, platforms, and frameworks. Martin is an assistant professor in the School of Computer Science at McGill University. A dynamic member of the tools and aspect-orientation communities, Martin focuses his research on supporting software maintenance and evolution.

65 ms
(Ver 3.x)