Bad scientific code beats code following "best practices" (2014)
Scientific research often relies on quick, one-off scripts written by domain experts, while professional developers tend to bring heavier “best practices” and abstractions—even to small, experimental codebases. Commenters argue over which is worse: brittle, undocumented scientific code that undermines reproducibility, or over‑engineered systems that are hard to understand, modify, and adapt to evolving research questions. Many conclude the real issue is incentives and context, calling for a balance between simplicity and engineering discipline and for dedicated research software engineers to bridge the gap.
Overall reaction to the article
- Many see the post as a rant or strawman: it contrasts “bad scientists’ code” vs “bad programmers’ code” using extreme examples.
- Others say it resonates strongly, especially the critique of over‑engineering and cargo‐cult “best practices”.
- Several argue the real target should be “bad programmers” (often juniors or pattern‑cargo‑cultists), not software engineering as a whole.
Scientists vs. software engineers
- Common view: scientists often under‑engineer (messy, ad‑hoc, single‑use scripts); software engineers often over‑engineer (layers of abstraction, inheritance, “enterprise” patterns).
- Some argue scientists are often smarter in their domain and can be more effective for one‑off tools; others counter that domain intelligence does not substitute for software skill.
- Multiple commenters note that in practice, a huge amount of scientific code is buggy, unreproducible, and often does not even run a year later.
Overengineering, “best practices”, and complexity
- Strong criticism of:
- Excessive abstraction (deep inheritance, plugin systems, many tiny files, indirection layers).
- Pattern‑driven design (“Clean Code” taken literally, micro‑functions, sprawling module graphs).
- Enterprise Java / heavy OOP as historical sources of unnecessary complexity.
- Counter‑view: these are abuses of best practices, not the practices themselves; good engineering aims for the simplest design that supports long‑term change.
Pathologies in scientific code
- Recurrent issues: no tests, no version control, hard‑coded paths and data, undocumented build steps, hardware misuse (e.g., loading all data into RAM).
- Reproducibility is widely seen as poor; some say this underlies the replication crisis.
- Others note expectations differ: academia historically accepted “manual” reproducibility efforts, not push‑button reruns.
Imperial College COVID model example
- Several posts use this as a cautionary tale: large, long‑lived scientific code with severe bugs (non‑determinism, memory issues, fragile design) allegedly produced misleading policy‑relevant results.
- This is cited as evidence that “quick and dirty” research code can be dangerous when repurposed for real‑world decisions.
Collaboration and roles
- Many advocate dedicated “research software engineers” bridging domain expertise and engineering discipline.
- Pairing domain experts with maintainability‑focused developers is seen as ideal but underfunded; incentives in academia prioritize papers over robust software.