Vol. 14 - Maintaining scientific software is a bad idea
Just delete your GitHub account. Empty your Zenodo. It's self-care.
There is a reason GitHub’s open-source guide for creators starts with self-care.
Maintaining code is a long-term endeavour, and more crucially, the skills involved in maintaining code are vastly different from the skills required to write good code in the long term.
Getting from an empty editor buffer to a piece of code that runs is a technical act. The questions you need to answer are: what is the way to write it so that it works, it is safe, and then when possible, it is fast. These can be difficult problems, definitely, but they are engineering problems.
But maintaining your code changes the geometry of these problems; you do not have to exist in interaction with your software, but in interaction with the way your code overlaps with your field. Changes in best practices means that last week’s release may not reflect the best standards anymore. New techniques, or criticisms on old techniques, need to be reflected. Changes in the language may lead to changes in the API. The surface over which issues can happen becomes immense.
What was a series of engineering decisions is turning into conflict resolution between, on the one hand, working with an aging code base, and on the other hand, academic fields that by definition are moving at a fast (and experimental) pace.
But the code itself is a part of this change — fields evolve when we do research, and we do research by using tools. I believe that Bachelard was right: it is the microscope who created microbiology. In the same way, it is the reification of the idea as something that can be executed that creates the research applications of the idea.
This is precisely where most of the tension comes from: when we use software, we trust that it does what is advertised. When our colleagues re-use our work, we become invested in whether this work is right or wrong. This is an immense responsibility. Waking up to a new GitHub issue that describes a bug that someone found when working on a paper is a genuinely harrowing experience.
I don’t really want to re-hash the discussion about credit for software, or funding for software. This is a lost cause. But we need, collectively, to realize the degree of emotional investment that happens when we develop, and commit to maintaining, a piece of software: not just because there is some attachment to the code as a technical object, but also because there is a feeling of responsibility for the way it will be used.
So, practice self-care. Close your GitHub account.
And with all that said, stay tuned for Vol. 15 next week, for a discussion of why building scientific software is actually worth it, sometimes.