Read alongside
ReScience C (journal of computational replications)
Journal of replications, including failed ones; read reports to learn how differences are documented.
Objectives
- Before concluding "it does not work", check for implementation bugs, configuration mismatches, too few runs and an evaluation unable to show the expected effect.
- Document a failed reproduction with environment differences, guessed details, contact with the authors and what partially matched.
- Revise a hypothesis after a negative result, label the revision as exploratory and design a new confirmatory test.
- Explain how hypothesizing after results are known and selective reporting distort a literature.
- Tell a real research failure story: expectation, result, diagnosis and decision.
Why it matters
Many hypotheses fail, and reproductions of published results sometimes fall short. A supervisor wants to know that you will notice, diagnose and report this, rather than quietly tuning until something looks positive.
Core ideas
Is it really negative? Before concluding that an idea does not work, rule out the boring explanations: a bug (does a reference implementation or sanity check agree?), a configuration mismatch (are you running what you think you are running?), too few runs to detect the expected effect (how wide is your interval?), and a metric or workload that cannot show the effect at all. "No difference" from three noisy runs is inconclusive, not negative.
Failed reproductions. Distinguish "we could not reproduce the result with the information available" from "the claim is false". Record every difference: hardware, software versions, preprocessing, hyperparameters you had to guess, and what did match. Contact the authors; many gaps come from undocumented details. Re-tuning baselines can also overturn earlier conclusions, as Melis et al. showed for language models.
Revising hypotheses honestly. A negative result often suggests a narrower hypothesis ("the gain appears only under bursty load"). That is progress, but the new hypothesis was shaped by the data, so it needs a fresh test on new runs, workloads or data. Presenting it as the original plan is hypothesizing after the results are known, a well-known route for false positives into the literature.
Reporting. Negative results belong in thesis chapters, internal reports and lessons-learned sections. Venues for replications exist: ReScience C publishes reimplementations and replications of computational studies, explicitly including failed ones, and the ML Reproducibility Challenge collects reproductions of recent ML papers. ACM's terminology helps you say precisely which kind of reproduction you attempted.
Common misconceptions
- "No significant difference means the idea does not work." The experiment may have been too small or noisy to tell.
- "A failed reproduction proves the authors wrong." It may reflect missing details or a different environment; say which.
- "Changing the hypothesis after seeing data is cheating." It is normal exploration if you label it and test the revision on new data.
- "Negative results are wasted time." They prune the search space and often reveal the assumption that matters.
How to approach it
Keep a dated log of hypotheses so revisions are visible. For interviews, prepare one honest failure story from your own work (expectation, result, diagnosis, decision); never invent one. Interviewers look for calibrated judgment, not for projects that always worked.
Self-check before you finish
- Could your experiment have detected the effect you expected, given its noise?
- Which sanity check would reveal a bug in your implementation?
- Which details of the original paper did you have to guess?
- Is your revised hypothesis being tested on data that did not shape it?