icse-experiments

ICSE Experiments

Design the study to survive an empiricist's audit, because that is who reviews

it. ICSE's rigor criterion scores "thoroughness and completeness of an

evaluation" (2027 call wording, read 2026-07-08), and the community has strong

default expectations per study type that function as unwritten checklists.

Evidence proportional to claim

| Claim shape | Minimum evidence ICSE reviewers expect |

|---|---|

| "Technique X finds more bugs than Y" | Real subject programs, Y actually run (not quoted from its paper), same budget/timeout, statistics + effect size |

| "Developers struggle with Z" | Systematic observation: survey with stated sampling, interviews to saturation, or instrumented behavior — not anecdote |

| "LLM-based tool solves task T" | Ablations over prompts/models, contamination discussion, cost reporting, non-LLM baseline where one exists |

| "Metric M predicts defects" | Multiple projects, time-aware splits, comparison against trivial baselines (size, churn) |

| "Our benchmark/dataset enables research" | Construction protocol, quality validation sample, license clarity, comparison with existing sets |

The recurring failure is claim-evidence mismatch: a general claim ("improves

program repair") evaluated on one narrow slice (single-hunk Java bugs from one

dataset). Either widen the evidence or narrow the claim before reviewers do.

Subjects and benchmarks

• Real programs, stated selection. Say how subjects were chosen —

"all Defects4J v2 projects" beats "10 popular GitHub projects" because the

latter invites cherry-picking suspicion. Report scale (kLOC, stars, age)

so readers can judge representativeness.

• Version-pin everything. Repository SHAs, dataset versions, dependency

locks; mining studies live or die on whether the corpus can be rebuilt.

• Guard against benchmark leakage in AI-for-SE work: if the model's

training data plausibly contains your benchmark (most public code

pre-2024 does), you must address contamination — held-out post-cutoff

bugs, mutation of subjects, or explicit caveats. Reviewers now ask

unprompted.

Baselines and fairness

Rerun baselines in your environment with tuned-in-good-faith configurations

and identical budgets. Where rerunning is impossible (unavailable code,

proprietary systems), say so and downgrade the comparison's claims. A

suspiciously weak baseline is the fastest way to lose a rigor score: reviewers

know these tools' published numbers.

Statistics as the SE community practices them

SE data are typically non-normal, so community convention favors

non-parametric machinery: Mann-Whitney/Wilcoxon tests paired with an effect

size — Vargha-Delaney Â12 or Cliff's delta — rather than bare p-values, with

multiple-comparison correction when many hypotheses are tested. For

stochastic techniques (search-based SE, LLM sampling), repeat runs (community

folklore says ≥10, more is better), and report distributions, not single

bests. These are norms, not posted rules — but a paper missing them collects

the same review sentence every time.

Per comparison, report all four:
  central tendency  -> median across repetitions
  dispersion        -> IQR or min-max across seeds/runs
  significance      -> Mann-Whitney U (corrected if many tests)
  effect size       -> Â12 or Cliff's delta, with magnitude label
Plus: exact repetition count, budget/timeouts, hardware, and total compute.

Qualitative rigor

For interviews, surveys, and coding studies the checklist changes shape:

sampling strategy and saturation argument; codebook development story; a

second coder with inter-rater agreement (Cohen's kappa or Krippendorff's

alpha) on at least a sample; quotes traceable to anonymized participant IDs;

instruments in the replication package. Mixed-methods papers are welcome at

ICSE precisely when each half meets its own bar.

Threats-driven design

Write the threats-to-validity section before running the study, as a design

instrument: every internal-validity threat you can name pre-hoc (selection

bias, implementation bugs in your own tooling, evaluation-metric gaming) is

one you can still mitigate cheaply — a random audit sample, a sanity

experiment, an independent reimplementation of the metric. Threats discovered

during writing week can only be confessed, not fixed. This inversion is the

single highest-leverage habit in the ICSE evidence culture; see

icse-writing-style for how the section is then written.

Sanity experiments that catch your own bugs

Before believing any headline number, run the cheap falsifiers: a

null-technique control (does a random or trivial variant score

suspiciously close to your tool? then the metric, not the technique, is

doing the work); a known-answer audit (hand-verify a random sample of

your tool's outputs — SE evaluation pipelines mislabel more often than

techniques fail); and a metric-implementation cross-check (compute one

cell of the results table with an independent script). Papers retracted or

majorly revised over evaluation bugs almost always lacked one of these three

runs, each of which costs an afternoon.

Ablations for AI-era SE papers

When the technique wraps a model, reviewers want the wrapper separated from

the model: fix the model and vary your components; fix your components and

vary the model (at least one open-weights option so others can reproduce);

report token/dollar/time costs; state decoding parameters and exact model

versions with dates — "GPT-4" is not a reproducible identifier and will be

flagged under verifiability.

Output format

[Claim inventory] each headline claim -> evidence row above -> met / gap
[Subjects] selection rule, scale, version pins, contamination status
[Baselines] rerun? tuned? budget-matched? which comparisons are downgraded
[Statistics] tests, effect sizes, repetitions, corrections present?
[Qualitative] sampling, codebook, agreement stats (if applicable)
[Pre-hoc threats] threats named at design time -> mitigation experiments queued