Organizing a Bioinformatics Project

Before you start

Helpful to have used version control and environments first; see Git & GitHub for scientists and Conda environments.
Any term new? The Glossary has it.

Learning objectives

By the end of this lesson you will be able to: lay out a bioinformatics project in folders that stay sane as it grows, protect your raw data, and write the README and naming habits that make your work reproducible (by others and by future you).

Future you will thank you

Every analysis starts tidy and drifts into chaos: final_v2_REALLY_final.csv, a script that only runs if you click things in the right order, raw data accidentally overwritten. A little structure at the start prevents all of it. None of this is advanced; it is just a handful of habits that separate work you can trust from work you cannot.

1A folder layout that scales

Give every project the same simple skeleton. You will always know where things are.

Raw data in one place (and never touched), processed files separate, code in scripts, outputs in results, and a README explaining it all.

my_project/
  data/raw/         # the original files, exactly as you got them
  data/processed/   # cleaned / intermediate files your code makes
  scripts/          # your code, one script per step
  results/          # figures, tables, the things you report
  README.md         # what this is and how to run it

2Treat raw data as read-only

The single most important rule: never edit your raw data in place. Download it, put it in data/raw/, and from then on only ever read from it; every change goes to a new file in data/processed/. If a step goes wrong, you can always rerun from untouched originals. On the command line you can even lock it:

chmod -w data/raw/*    # remove write permission, so you cannot overwrite it by accident

3Name things so you can find them

Good names save hours. A few habits:

No spaces in file names; use underscores or hyphens (control_rep1.fastq.gz, not control rep 1.fastq.gz).
Dates as YYYY-MM-DD (2026-06-17_results.csv) so they sort correctly.
No "final". It is never final. Use a version or a date instead.
Describe the content, not the mood: deseq2_results_treated_vs_control.csv beats output3.csv.

4A README is the map

A short README.md at the top of the project is the difference between work someone can reuse and a folder no one (including you in six months) can decode. It does not need to be long. Say: what the project is, where the data came from, and the order to run the scripts in.

# Airway RNA-seq re-analysis

Differential expression of dexamethasone-treated airway cells.
Data: GEO GSE52778 (Himes et al. 2014).

## How to run
1. scripts/01_download.sh   - fetch the data
2. scripts/02_quantify.sh   - reads to counts
3. scripts/03_deseq2.R      - differential expression -> results/

The reproducibility test

Could a colleague clone your project folder and, by reading only the README, reproduce your results? If yes, you have done this right. Pair this layout with a pinned environment (see the conda lesson) and version control (the Git lesson), and your work is genuinely reproducible.

Check your understanding

Where should the cleaned/intermediate files your code produces go?

Right. Raw stays untouched; everything your code makes goes to data/processed/.

Why name files with dates like 2026-06-17?

Correct. Year-month-day sorts correctly and removes guesswork about which file is newer.

What is the single most important rule for your raw data?

Right. Untouched raw data means you can always rerun from a clean start. Make changes into data/processed/.

Which file name is the best choice?

Correct. No spaces, a sortable date, and a name that describes the content. "Final" and vague names cause pain later.

What is the point of a project README?

Exactly. A README that states what the project is, where the data came from, and the order to run things is the heart of a reproducible project.

Next in Track 6