Reproducible by Design: a practical standard for science that ships

Reproducibility is not a “nice-to-have” at the end of a project. It is a design constraint.

Modern science is increasingly software, data, and teams—yet many results still depend on fragile environments, undocumented decisions, and workflows that only one person can run. When that happens, the work may be impressive, but it is hard to trust, hard to extend, and hard to deliver.

This publication is my attempt to help change that in a pragmatic way—using lessons from software engineering, bioinformatics, and delivery/leadership, adapted to the realities of research.

What I mean by “reproducible”

Reproducible does not mean “I can rerun it if I remember what I did.” It means:

• the workflow can be rerun by someone else with minimal back-and-forth,
• the environment is recoverable (not a fragile laptop state),
• parameters and provenance are captured automatically,
• validation is explicit (not just “it finished”).

In bioinformatics (ex: microbiome/metagenomics) this matters even more: multi-step pipelines, large cohorts, and version-sensitive tools create many ways to “almost reproduce” something—and still be wrong.

The Reproducible by Design standard (RBD)

This is not a rigid ideology. It is a set of practices that consistently improves quality and delivery when applied with judgment.

If you adopt only a few, start with the first three.

1. Design for re-runs from day one
   Treat re-running as a first-class use case, not an afterthought.
2. Capture provenance by default
   Inputs, reference data, tool versions, parameters, and code revision should be recorded automatically.
3. Automate the boring correctness
   If it matters, script it. Manual steps should be rare and documented.
4. Make the safe path the easy path
   The default way to run the workflow should also be the most correct way.
5. Validate continuously, not at the end
   Add fast sanity checks and fail early (counts, ranges, controls, expected outputs).
6. Separate scientific choices from engineering choices
   Science decisions (definitions, thresholds, cohort logic) must be explicit; engineering choices (execution, portability, performance) must be robust.
7. Treat environments as artifacts
   Prefer pinned dependencies and containers when portability matters; provide a documented fallback when constraints exist (common on HPC).
8. Make failure diagnosable
   Logs, structured outputs, and a clear debug path turn “it failed” into “here is why.”
9. Reduce coordination cost on purpose
   Clear ownership and a simple definition-of-done beat long meetings and ambiguous responsibilities.
10. Improve continuously
    Reproducibility is maintained through iteration: small releases, changelogs, and postmortems when things break.

Why team culture belongs here

Even with a solid pipeline, teams can still move slowly if the working model is unclear.

In research groups, it is common to see:

• unclear ownership (“everyone” owns it, so nobody owns it),
• implicit standards (“we all know what good means”),
• repeated discussions and rework,
• friction that is avoidable with lightweight agreements.

A simple working agreement—how decisions are made, how work is reviewed, what “done” means—can move a group from “storming” to “performing” without heavy bureaucracy. I’ll cover how to do that in a way that respects the realities of science.

What you can expect here

I will publish practical content across two initial series:

RBD Bioinformatics

Reproducible microbiome/metagenomics in practice: cohort processing patterns, QC, benchmarking, interpretation, reporting, and what breaks in real life.

RBD Teams

Lightweight delivery systems for research groups: ownership, working agreements, definition-of-done, reviews, and “continuous improvement” without process theatre.

I will focus on adoption: practices people can actually apply. Expect clear trade-offs, concrete examples, and templates over time.

What I will optimize for (and what I won’t)

I will optimize for quality that scales:

• clarity over complexity,
• validation over vibes,
• repeatable workflows over one-off heroics.

I will avoid:

• cargo-cult processes,
• advice that ignores failure modes,
• “one-off scripts” presented as best practice.

What’s coming first

To make this immediately useful, I’ll start with high-impact assets:

1. Your first production-grade Nextflow pipeline
   Structure, profiles (local/HPC), containers, CI, and validation.
2. Brittle environments: how to stop losing days to tooling
   Practical patterns for reproducibility without overengineering.
3. Working agreements for research teams
   A lightweight model to reduce friction, improve execution, and protect quality.

Some guides and examples will remain free. More elaborate, production-ready templates and checklists will be available via subscription to help cover costs and keep the work sustainable.

Subscribe

If this aligns with the way you want to do science, subscribe for updates and early access to templates: