they need to defer to the experts of software development. I, as a software engineer, wouldn't try to design an epidemic model, i would defer to experts. Epidemic experts shouldn't be writing the implementation of their model, they should defer to the experts. Also, "It’s you, the software engineering community, that is responsible for tools like C++ that look as if they were designed for shooting yourself in the foo…
> Epidemic experts shouldn't be writing the implementation of their model, they should defer to the experts. Believe me, a lot of scientists would love to. But as pointed out in the OP: it is next to impossible to get funding for a paid software developer position in a research team. It's a problem the scientific community is increasingly aware of, but changing funding guidelines takes a long time. (Source: computati…
To software engineers criticizing Neil Ferguson’s epidemics simulation code
141–150 of 189 posts
Re: To software engineers criticizing Neil Ferguson’s epidemics simulation code
#142Earlier quoted context omitted.
These qualities are important for exactly the same reasons they are in production: Without those qualities, your code is brittle, your deploys are brittle, changes are brittle. It's just like saying "It runs on my machine". The scientific term for this is "Replication crisis [0]" 0 - https://en.wikipedia.org/wiki/Replication_crisis
> Without those qualities, your code is brittle, your deploys are brittle, changes are brittle. Is this brittleness stopping the scientists achieving what they need to achieve? Are you sure that writing tests makes science better? Or are you just assuming that? They aren't idiots and they aren't ignorant of how professional software developers work.
It is perfectly acceptable to write code without tests. Proof-of-Concept or Minimum Viable Product are a great place to write code without tests.
It is less acceptable if other people will run or use that code. It is even less acceptable if anyone (including oneself) ever updates or extends the code.
---
You could take this analogy to scientific instruments. Imagine you make a novel particle detector. You get a scientific result with your detector.
A colleague uses your detector, but they don't clean it properly before use, and they use a power supply with lower voltage. They don't detect any particles! Was your science bad? Would the "science be better" if there were clearer instructions and pre-requisites?
Now imagine another scientist makes a copy of your detector from the description in your paper. They get some stuff wrong because your description was ambiguous. Was the science bad?
---
By the way, all of these things are real problems with scientific investigations, and not just in the software realm.
Re: To software engineers criticizing Neil Ferguson’s epidemics simulation code
#143I poked at the github repo for a bit. The ugliness of the code doesn't bother me, but the quantity of parameters does. Here's one params file that specifies some of the inputs to a run of the model: https://github.com/mrc-ide/covid-sim/blob/master/data/param_... Here's another one: https://github.com/mrc-ide/covid-sim/blob/master/data/admin_... There are hundreds of constants in there. A lot of them appear to be wild…
Re: To software engineers criticizing Neil Ferguson’s epidemics simulation code
#144Earlier quoted context omitted.
These qualities are important for exactly the same reasons they are in production: Without those qualities, your code is brittle, your deploys are brittle, changes are brittle. It's just like saying "It runs on my machine". The scientific term for this is "Replication crisis [0]" 0 - https://en.wikipedia.org/wiki/Replication_crisis
The Replication Crisis is much larger in scope than just software reproducibility. But yes, it does include that too.
Re: To software engineers criticizing Neil Ferguson’s epidemics simulation code
#145The case in hand - is problematic because it highlights that lack of controls that are present and that should probably be present when building models and simulations to inform policies.
Quality control is important in nearly every other industry - the lack of quality controls in academia appears to be the root cause to me. Rather than particular language/build choices.
Re: To software engineers criticizing Neil Ferguson’s epidemics simulation code
#146Earlier quoted context omitted.
It's easier to dip your toes into, but it is a terrible language to learn software development with. It's such a hodge-podge of ill-thought-out and ill-fitting components with random names and no overall sense of structure that you're never going to learn core CS concepts from it, let alone good programming practice.
That's not really its purpose though, right? R is "an environment for statistical computing and graphics". Note that it doesn't talk about software engineering at all. I agree with you that R has lots of rough edges, but please remember that it's a 90's era clone of a 70's era language (S) and a lot of those rough edges and corners are legacies from that time. I completely agree that the naming conventions (i.e. the…
Re: To software engineers criticizing Neil Ferguson’s epidemics simulation code
#147Earlier quoted context omitted.
> Epidemic experts shouldn't be writing the implementation of their model, they should defer to the experts. Believe me, a lot of scientists would love to. But as pointed out in the OP: it is next to impossible to get funding for a paid software developer position in a research team. It's a problem the scientific community is increasingly aware of, but changing funding guidelines takes a long time. (Source: computati…
That's a fair point. Also, passing judgement on source code is a very easy thing to do. May he who writes/maintains perfect code cast the first stone.
Re: To software engineers criticizing Neil Ferguson’s epidemics simulation code
#148Earlier quoted context omitted.
> "The private sector's typical response to the problems in the article would be to hire qualified software engineers to assist researchers. Funding dictates this is impossible, so they make do." But that is a bizarre conclusion. Is it really cheaper to let scientists focus on something they know nothing about, than to hire an expert to do it? Do you cut costs by letting scientists mop the floor, clean the toilet and…
> Is it really cheaper to let scientists focus on something they know nothing about, than to hire an expert to do it? Do you cut costs by letting scientists mop the floor, clean the toilet and guard the entrance? Believe it or not, mean software engineer salaries are marginally higher than those of janitors and door security.
Re: To software engineers criticizing Neil Ferguson’s epidemics simulation code
#149Earlier quoted context omitted.
Sorry but there's a pretty big gap between understanding the domain for which your software is intended, and being qualified to work as a professional in that domain. The latter is what you're asking of academics.
I guess we are in agreement then ;) If academics are writing predictive modelling software, I ask that they are qualified to do so.
> I ask that they are qualified to do so.
You need to make up your mind on this one. Are you asking this or aren't you?
Re: To software engineers criticizing Neil Ferguson’s epidemics simulation code
#150I poked at the github repo for a bit. The ugliness of the code doesn't bother me, but the quantity of parameters does. Here's one params file that specifies some of the inputs to a run of the model: https://github.com/mrc-ide/covid-sim/blob/master/data/param_... Here's another one: https://github.com/mrc-ide/covid-sim/blob/master/data/admin_... There are hundreds of constants in there. A lot of them appear to be wild…
So code quality mattered less then usual. If there's a significant bug, then the operator will probably notice, and if there's an insignificant bug then no one cares. The large number of input parameters also doesn't matter. The operators are fully aware that they could artificially manipulate the output to wherever they wanted, but to do so would be cheating only themselves.
It feels to me like Ferguson's model was built with similar intent, and probably served that purpose well. The problem came only when the media portrayed the model as a source of authority apart from the people operating it, perhaps to create a feeling of objectivity behind the decisions driven from that. That created an expectation of rigor that either didn't exist (in the software engineering), or fundamentally can't exist given our current knowledge of the science (in the input assumptions).