How can we document software and computational analyses in such a way that others can convince themselves of their validity, and build on them for their own work? The question has been around for many years, and a number of attempts have been made to provide partial answers. This post provides a brief review and describes my own tentative answer, inviting you to play with it.
Konrad Hinsen's blog
Thirty years after my first contact with computational (ir)reproducibility, I am happy to note that many things have improved. Reproducibility, computational and otherwise, is increasingly recognized as an important aspect of scientific quality control, and mostly considered worth striving for. However, I also note that more and more people, including reproducibility activists, have lost contact with the day-to-day reality in which reproducibility matters. Reproducibility is becoming an item on a checklist, and its precise incarnation the subject of political bickering aimed at making it easy to check off that item. So let's take a look at why computational reproducibility matters for researchers.
The Interface of Kai Krause's Software @mprove
Matthias Müller-Prove, Innovative Benutzungsschnittstellen, 1998/99, University of Hamburg
The Case Against Formal Verification, 50 Years Later - Ivan Gavran
Writings on software correctness, AI, formal verification, and other technical topics.
Code Worth Writing - Ray Myers | SSW 2026
Ten quick tips to SNIFF out sustainable and secure scientific software
Modern computational biology depends heavily on open-source software tools, analysis pipelines, and containerized workflows developed and shared by the research community. While there is extensive guidance (including Quick Tips and Simple Rules articles) on how to build robust and sustainable scientific software, far less has been written for researchers in the role of software users evaluating whether an existing tool is reliable, secure, and sustainable enough for their work. Here we present ten quick tips to help researchers critically assess the tools they adopt. Our tips are organized around a framework that centers on key evaluation features: source, network, interaction, fit, and fragility (SNIFF). These dimensions prompt researchers to consider who maintains a tool and why, whether it is embedded in a broader ecosystem, how actively its developers and users engage, whether it matches the intended use case and licensing requirements, and how robust its dependencies and security practices are. By applying these tips, researchers can make more informed decisions, reduce the risk of relying on abandoned or insecure software, and contribute to a more sustainable scientific software ecosystem.
Linking the world's research to the code it runs on - OpenAlex blog
Research relies on software. Software written by scientists, for science, runs through the entire modern research stack: NumPy and SciPy, R and ggplot2, Jupyter, BLAST, ImageJ, AlphaFold. Yet in the scholarly record, that software is nearly invisible. Software is not usually cited formally in publications and is usually just mentioned in the text, which means […]
R. S. Doiel, Software Engineer/Analyst — Robert's ramblings
By R. S. Doiel, 2026-02-21 (revised: 2026-03-03, epilogue added 2026-03-27)
How to SNIFF out Good Scientific Software
New PLOS Computational Biology paper: "Ten Quick Tips to SNIFF Out Sustainable and Secure Scientific Software"
Simon on Twitter / X
Can AI help connect theorems humans write in papers to proofs computers can check?We just released TheoremGraph (https://t.co/PQ8FcFQGat), and I made a 3Blue1Brown style video overview of the idea.This project was my first real research experience, and it meant a lot. Start… pic.twitter.com/yMUA0QziXM— Simon (@waskaja) June 29, 2026
Composure
On yet another foray into the list of opinions I have that I’m sure are making me progressively more unemployable by the day, I asked some people on the internet: who is doing interesting work on software composability these days and where do I find them?
Substrates conference series - Substrates 2026
An increasing number of researchers see their work as interactive authoring tools or software substrates for interactive computational media. By talking about “authoring tools”, we remove the divide between programmers and users; “software substrates” let us look beyond conventional programming languages and systems; and “interactive computational media” promises a more malleable and adaptable notion of tools for thought we are striving for. This workshop aims to bring together a wide range of perspectives on these matters.
The Man Who Revolutionized Computer Science With Math
Serpentine software
I don’t usually write hot takes. But StrongDM’s Software Factory post is worth it, so here goes. Their post is elegant, short, and well-written, so I’m going to just go through a bunch of pull quotes. Compounding correctness long-horizon agentic coding workflows [now] compound correctness rather than error This is a big, empirical claim. I’m already convinced by my own experiences that agents, suitably scaffolded, can form a Brownian ratchet, such that pouring on more compute helps, on balance.
Improving Science That Uses Code
Abstract. As code is now an inextricable part of science it should be supported by competent Software Engineering, analogously to statistical claims being
Computational reproducibility
The why and how of making scientific computations reproducible
Computational Law
RaC, rules as code, legislation as code, automated decision making, papers, resources, disasters, people
Legislation as Code | Version: 2
Governing Digital Legal Systems: Insights on Artificial Intelligence and Rules as Code · MIT Computational Law Report
Hamish Fraser
Konrad Hinsen's blog
Home Page - Software Heritage
GNU Guix transactional package manager and distribution — GNU Guix
Keynote: Reproducibility and replicability of computer simulations | Canal U
Reproducible research: methodological principles for transparent…
Reproducible Research II: Practices and tools for managing compu…