I recently came across a post in the fortran-lang forum referring to a blog post that makes an assertion that research software is likely to remain a tangled mess. I have a sufficient amount to say that should hopefully refute such an assertion, and give us some hope for the future.
One of the points made is that researchers simply do not have the time or desire to study the art of software engineering and master that skill. I’m not entirely sure that is true. For starters, researchers are generally members of institutions of higher learning. Why should they feel disinclined from learning? Perhaps the incentive structures in place at universities and laboratories really is that far out of whack, but I haven’t experienced that myself. And at any rate it wouldn’t be much different than suggesting researchers are too busy to learn math. It’s a necessary skill and we should encourage researchers to treat it as such.
To the point idea of incentive structures, it was suggested that researchers receive no recognition for the software they write, only for the results. But that’s not true anymore. Methods are being developed for citing research software directly. In fact there is now a journal specifically targeting the publication of research software, and a sister journal for publishing educational software so that researchers and educators can get credit for the software they develop.
Another couple of points made are that researchers tend to leave the code in a state that it is difficult to build or doesn’t work on different systems, and that they tend to reinvent the wheel for many things because they simply don’t know other solutions are available. There is an active community working diligently to address these problems. For example Fortran is a programming language specifically aimed for use by scientists and engineers. Now that tools like the Fortran Package Manager are available and with the community support behind fortran-lang.org, building, making available for others, and finding existing solutions for Fortran software has become much easier.
Finally, having cleaner code would actually make research efforts go faster, not slower. All that time spent fixing flaky build systems, chasing down bizarre bugs, and deciphering cryptic spaghetti code could be used to solve real problems. The scientific community would be so much more productive, with it being so much easier to collaborate and make use of each others’ work. In the same way that we don’t make excuses for surgeons not to wash their hands and keep their instruments organized because they’re just too busy, we shouldn’t make excuses for researchers not to keep their code organized and reusable.
So yes, there are challenges facing the adoption of better software practices for research software. But as I’ve shown, those challenges are being addressed. I don’t think research software is doomed to forever remain a tangled mess.