icse-writing-style

ICSE Writing Style

ICSE prose is judged by empiricists. The reviewer pool's shared training —

controlled experiments, mining studies, qualitative methods — produces a house

reading style: they locate the research questions, check that the design

answers them, and read the threats-to-validity section as a candor test. Write

for that reading order, not for a general CS audience.

The load-bearing skeleton

A canonical ICSE technique-plus-evaluation paper spends its ten pages (2027

format: 10 pages main text including all figures/tables/appendices, +2 pages

references only) roughly like this:

| Section | Pages | What reviewers extract from it |

|---|---|---|

| Introduction | 1.5 | The SE problem, who suffers it, the claim, the contributions list |

| Background / motivating example | 1 | One concrete failing case the technique later fixes |

| Approach | 2–2.5 | How it works, precisely enough to reimplement (verifiability) |

| Study design | 1.5 | RQs, subjects, baselines, metrics, protocol — before any results |

| Results, organized by RQ | 2.5 | One answer per RQ, stated then evidenced |

| Discussion + implications | 0.5–1 | What researchers and practitioners should do differently |

| Threats to validity | 0.5 | Honest limits with mitigations |

| Related work + conclusion | 1 | Delta over neighbors (see icse-related-work) |

Empirical studies swap Approach for extended methodology; the RQ-driven spine

stays. If a section cannot say which RQ it serves, it is a cut candidate.

Research questions as contract

State 2–4 RQs in the introduction or design section, then answer them in order

with boxed findings:

\subsection{RQ1: How often do generated patches overfit the test suite?}
...evidence...
\begin{tcolorbox}
\textbf{RQ1 finding.} 47\% of patches passing the full suite fail held-out
tests; overfitting concentrates in multi-hunk patches.
\end{tcolorbox}

Reviewers navigate by these boxes. An RQ that is asked but never answered, or a

finding with no RQ, both read as design drift — a rigor flag.

The threats-to-validity craft

The section is expected, but its quality is what gets scored. Community

convention organizes threats as construct validity (are you measuring the right

thing?), internal validity (could something else explain the result?), external

validity (to what does it generalize?), and — for statistical work — conclusion

validity. Three rules separate a real threats section from ritual:

1. Name your actual weakest point, the one a hostile reviewer would find

anyway. Preempting it converts an attack into a footnote.

1. Pair every threat with what you did about it (mitigation) or why it is

tolerable (bounded impact). A threat with neither is a confession.

1. Ban imported boilerplate. "Our results may not generalize to other

projects" appears in thousands of papers; "our 17 subjects are all Java

build systems, and the technique reads JVM bytecode, so C# generalization

is untested" is yours alone.

Motivation that survives the relevance criterion

ICSE scores relevance to software engineering explicitly. Ground the opening in

an engineering pain that is evidenced, not asserted: a quantified cost from a

cited study, a documented incident, an observed practice from your own

formative data. The weakest ICSE openings assert that a problem "is important

and has attracted increasing attention" — citation-mulch that spends the most

valuable half page on nothing.

Calibrated claims

The verifiability criterion punishes claim/evidence gaps, so calibrate:

• Quantify or delete: "substantially outperforms" → "improves F1 by 0.09–0.14

across all three benchmarks (Table 3)".

• Scope every generalization: "for the Java projects studied", "in our

interview population".

• Distinguish observation from causation everywhere except where the design

licenses causal language (a controlled experiment does; a mining

correlation does not).

• Make the contributions list checkable — each bullet should name the section

and, where relevant, the artifact directory that substantiates it.

The abstract, sentence by sentence

An ICSE abstract that reviewers bid on accurately runs six moves: (1) the

engineering problem with its cost; (2) the gap in how existing work handles

it; (3) the approach in one mechanism-revealing sentence; (4) the study

design in one sentence — subjects, baselines, method; (5) headline results

with numbers, scoped; (6) the availability sentence. Move 4 is the one

authors from other communities omit and SE reviewers miss immediately: at

ICSE the study is a first-class part of the contribution, and an abstract

that hides it reads as having something to hide.

Ten-page compression without desk-reject risk

The IEEE template's formatting rules are desk-reject-enforceable, so recover

space editorially: merge motivating example into the introduction; convert

prose protocol descriptions into a design table; move non-decision-critical

material to the replication package and cite it in the availability statement

(the package, unlike the paper, has no page cap); tighten figures — SE papers

lose half-pages to screenshots that could be 4-line listings. Never touch

\vspace, margins, or font sizes.

Output format

[Structure audit] skeleton section -> present/missing/oversized (page budget)
[RQ contract] each RQ -> design element -> boxed answer (complete? ordered?)
[Threats quality] real weakest point named? mitigations paired? boilerplate found?
[Claim calibration] list of unquantified/over-scoped claims with rewrites
[Space plan] cuts and relocations to reach 10 pages template-clean