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

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