Rerun Your Analysis Two Years Later and Get the Same Numbers: A Workflow

Fourteen months after submission, the second-round reviewer asks for one extra control variable in the main model. You open the project folder and find analysis_new.sav, analysis_new_fixed.sav and final_REAL.sav. None of them reproduces the coefficients in Table 3. This is an extremely common situation, and it involves no misconduct at all. It only takes a few undocumented manual cleaning steps.

Reproducibility is the floor of scientific credibility: the same data and the same analysis should produce the same numbers. If the authors themselves cannot manage that, nobody else will.

Three terms that get mixed up

This article focuses on the first layer, because it is entirely within your control and everything else rests on it.

Folder structure: separate what must never be touched

A simple layout that works for most projects:

• data_raw/ — original data, read-only. Never edit files here.
• data_processed/ — files created by code. Delete the folder and the code must be able to rebuild it.
• code/ — scripts numbered in run order: 01_clean, 02_derive, 03_models, 04_tables.
• output/ — tables and figures written by the code.
• README — which file runs first and what software is needed.

The core rule: raw data are sacred, everything else is disposable. If a value was entered wrongly, fix it with a commented line of code, never in the original file.

Code instead of clicks

You do not have to abandon SPSS or Excel to work reproducibly. You do need a text record of every step:

• In SPSS, press “Paste” instead of “OK” to save syntax to a .sps file, then run from that file.
• In Stata, work in a .do file rather than typing into the command window.
• In R and Python, write scripts or Quarto, R Markdown or Jupyter documents that run top to bottom.
• Excel is the hardest case. At minimum keep a log of each cleaning step, and avoid opening and resaving CSV files containing dates or gene names in Excel, which silently reformats them.

The test: delete the processed data and output folders, then rerun everything from the start. If every table in the manuscript reappears unchanged, you have basic reproducibility.

Silent sources of drift

1. Package versions: a function whose default changes between versions can change your results. Record versions with renv in R, a requirements file or conda environment in Python, or at least print sessionInfo at the end of your output.
2. Random numbers: bootstrapping, train–test splits, simulations, multiple imputation. Always set a seed at the top of the script and report it.
3. Absolute paths: “C:/Users/Sam/Desktop/…” breaks instantly on anyone else's machine. Use paths relative to the project folder.
4. Run order: a variable created in script 03 but used in script 02 because you ran them by hand in a different order. A clean rerun exposes this.
5. Rounding: reporting a rounded number and then calculating with it. Compute with full precision and round only for display.

Version control without becoming a programmer

Git has a steep reputation, but you only need three habits: take a snapshot (a commit) whenever the code runs, write one line saying what changed, and push to a private remote. Graphical clients and the Git panes built into RStudio or VS Code make this a few clicks. The biggest payoff is knowing exactly which code produced the tables in the version you submitted on a given date.

If Git still feels like too much, at minimum zip the code folder with a date every time you submit or resubmit, and store it with the reviewer correspondence.

Dynamic documents: numbers generated by code

Quarto and R Markdown let you mix prose with code, so the number in “the regression coefficient was 0.34” comes straight from the output. No more updating a model and forgetting one figure in the discussion. If the journal wants Word, these tools export to Word.

A reproducibility check before submission

1. Run the full pipeline on another computer or a clean user account.
2. Compare every number in the tables and text against the code output, ticking each one off.
3. Ask a colleague to run the project using only the README. Note how long it takes and where they stumble.
4. Archive the submitted version (code, de-identified data if permitted, README) in a DOI-issuing repository or a dated private archive.

Some journals now employ data editors who rerun code before publication. Doing this check yourself first avoids a technical desk return.

What to do with an old, messy project

You do not need to redo everything. Pick the main results table, write code that rebuilds exactly that table from raw data, and stop there. For secondary analyses, record what you remember in the README. Half reproducible beats not reproducible at all.

One thing to do today: create a data_raw folder, copy the original data into it and make it read-only. That single step removes the most common source of trouble, which is accidentally overwriting the original data.

Câu hỏi thường gặp