The problem with software in evolutionary biology

A nice feature article came out a couple of days ago on Nature, about how to better fix bugs in scientific software. Unfortunately, I believe the article to be very useful for some, and very useless for others (or most). Within the field of evolutionary biology, I believe that such an article is more useless than useful. Mostly, I believe that the suggestions presented in the article are completely valid, but only for software that is already of good level to start with. That is, software written by scientists who already have some ideas of principles of good programming.

The harsh truth is that software engineering and programming are very often self-taught disciplines in biology (barred bioinformatics, perhaps). The very few courses of programming that are introduced in biology - at least in the institutes where I have been, which are admittedly few and thus I can only speak out of experience - concern statistical programming and are limited e.g. to R. However, many evolutionary biologists need simulations for their work, and thus need to be introduced to Object-oriented programming. This means being able to code in languages such as Python and/or C++, and being able of more than just defining and calling functions.

I believe my experience to be quite similar to others’. I learned Python during my master thesis (before I moved on to evolutionary biology) and I had to learn it by myself. As many people, I chose a tutorial online and started from there. It wasn’t until much later, during my PhD, that I realized that I was a terrible coder and that the code that I had written up to then was terribly inefficient, difficult to understand even to myself, and prone to bugs. In the following years, I learned about best practices, attended lectures, and now I consider myself a marginally better coder. Even so, one of the bugs I encoded in the beginning of my PhD came to bite me many years later, when I finally submitted the paper resulting from that simulation code. A comment by a reviewer put me on the right course, and I discovered a bug that ultimately changed the results of my work. Luckily it was before publication! Sometimes I wonder if I’m a lonely case, or if there is out there plenty of results that are flawed because of a bug in the code that no-one ever found.

In recent years I have been outspoken about this issue: programming practices are severely lacking in the field of evolutionary biology. Not only that, but software is often treated as an unimportant part of the research process in evolution. There are a few reasons why that is, and I think I identified a few (what follows is from a recent Tweet that I posted on the matter):

1. In the field, we lack awareness about good practices in programming. Most of us never learned about them, and some don’t even care. We don’t know how to comment and document code properly. We don’t really do it because…
2. …we lack the will to produce readable software. Often we put it online just because it is requested by a journal for “transparency”. Few reviewers take the time to review the code at the peer-review stage. And we ourselves have little time to go through someone else’s code unless it is directly relevant for our research.
3. We lack the incentives to produce re-usable software. For example, too much code is only created as proof of concept of how a new method works. It is never intended to be disseminated for exploitation by external potential users. And people who might be interested in it often lack the technical competence to reproduce the software or rewrite it. Such software becomes functionally dead after publication.
4. We do not have the logistical structure in place for code maintenance. Much research nowadays is conducted by PhD students and postdocs - that is, early career researchers. But early career researchers quit academia more often than not, leaving a hole of responsibility. And even when they have the chance of staying in academia, whose responsibility is it to maintain code? The lab where the work was performed? The first author of the paper? The author of the code? Maintenance takes time and resources away from the main game, which is publishing new results and writing grants.

It is obvious that we need to change a lot of things if we are to produce good software that can be reviewed and re-used. Most of these changes concern the system behind academia. In a world where we fight for money and we only get it for innovation, nobody will take time to make existing methods available as software. Nobody wants to pay the price and put resources into maintaining code. And nobody sees as necessary to hire research software engineers (a very rare position indeed) because the current clumpsy level of coding still leads to publications, which is the main return for any scientist. But we are wasting resources, which is inadmissible in a field where code is so incredibly important and is becoming even more so as time passes. We need to change.

• 2022 2
• 2020 4