To software engineers criticizing Neil Ferguson’s epidemics simulation code

wait what. a fraction of the community might be a pretentious bunch of purist, but I don't think it's fair to criticize them for the tooling selection

one wouldn't pick a excavator just because it's the industry standard for moving earth to plant some tulip in a vase

and even if funding is scarce, google is free: the first result for planting tulips returns a bulb planter, not a bulldozer.

expose your “non-expert code” to the software engineering communities (and all other associated fields) to take a look.

1. Software engineers are expensive. Hiring them to write your code is how you end up needing even more money to do your science, and I think the software engineering world if anything can appreciate prioritizing being scrappy to get more done.

2. Open source is slow and doesn't produce consistent results in the timeframes you need in order to get things implemented in one-offs. In fact, the value you get from others looking at your code is pretty anemic unless other software engineers find your code useful, at which point they have real incentive to help you improve existing functionality instead of reinventing the wheel. I do think code should be published alongside papers as a matter of reproduceability, but I don't think opening up the code beforehand will accomplish much.

Which is all to say that while I agree with you in principle, I don't think your recommendations are practical.

I think this letter has it right: we should make better tools to help non-experts do less foot shooting. C++ is very, very foot shooty, and the usual answer of "well get better at C++" is a non-starter for non-experts.

I think there are other solutions too - software engineers with partial specializations in academic fields, volunteers, etc.

The problem here is the project is influencing decisions in healthcare.

Having worked in HPC and academia, I've seen code like this a lot. There are two archetypes I've noticed: (1) the well-meaning older academic maintaining legacy code, who have often done a lot of convergence testing, but still have code that isn't up to modern engineering practices, and (2) the domain experts with the attitude that "programming is much easier than my area of domain expertise". These are problems that require attitude changes within academia, not better warnings on online tutorials. The second group are going to ignore the warnings anyway.

Remember many of the people writing this academic code also teach programming courses in their departments! They view themselves as programming experts.