Live data from Hacker News

To software engineers criticizing Neil Ferguson’s epidemics simulation code

blog.khinsen.net

21–30 of 189 posts

Re: To software engineers criticizing Neil Ferguson’s epidemics simulation code

#21
Science is inherently a low stakes game. Most scientists are competing for budgets of no more than a few million a year, if they are really successful. There is little reward for producing excellent code, but a lot of reward for producing atrocious code to publish in prestigious journals.

If you want to be truly horrified look into the practices surrounding NEURON, a simulation tool that has been used to publish simulations since the 80s. You have to write code in a domain specific language called Hoc, that code is typically littered with hard coded constants. Code is copied over from one paper to the next, etc. Code is a means to an end, not something that is held in high regard. Moreover improving someone else's code style or quality won't earn you a degree or praise. Starting a competing "higher quality" project is bound to annoy or anger the establish players. It will be hard to get funding for it, because those players will likely review your proposal. In any case there is typically a 10-20 year gap between the people doing any decisions and the people actually doing any practical work.

Finally in some cases code is a competitive advantage, I'm sure that Neil Ferguson has churned out quite a few papers with the same framework by simply tweaking some things here and there. In that case you are ill advised to share the code with anyone.

Re: To software engineers criticizing Neil Ferguson’s epidemics simulation code

#22

This letter feels as though it is overlooking a large point of contention. >The scientists who wrote this horrible code most probably had no training in software engineering, and no funding to hire software engineers Shouldn't the argument be, that for research that is reliant on coding models, funding be allocated to experts that can assist in creating said models (software engineers)?

The conclusions from the first critical code review cited:

All papers based on this code should be retracted immediately. Imperial’s modelling efforts should be reset with a new team that isn’t under Professor Ferguson, and which has a commitment to replicable results with published code from day one.

On a personal level, I’d go further and suggest that all academic epidemiology be defunded. This sort of work is best done by the insurance sector. Insurers employ modellers and data scientists, but also employ managers whose job is to decide whether a model is accurate enough for real world usage and professional software engineers to ensure model software is properly tested, understandable and so on. Academic efforts don’t have these people, and the results speak for themselves.

https://lockdownsceptics.org/code-review-of-fergusons-model/

Re: To software engineers criticizing Neil Ferguson’s epidemics simulation code

#23

This letter feels as though it is overlooking a large point of contention. >The scientists who wrote this horrible code most probably had no training in software engineering, and no funding to hire software engineers Shouldn't the argument be, that for research that is reliant on coding models, funding be allocated to experts that can assist in creating said models (software engineers)?

Back in 2008-2009 my then PI tried this: it worked for a while, but then it proved to be untenable. Not because there wasn't enough money (there was) but because the university did not like the idea to get someone on board just to help researchers develop software, and thus there were so many roadblocks at one point that it was impossible to go on.

Re: To software engineers criticizing Neil Ferguson’s epidemics simulation code

#24

this is quite off the mark. the author sets the bar too low for himself by criticizing the most easily (and to be fair legitimately) dismissed criticisms of the Imperial College model. here's a better laid-out critique that the OP doesn't speak to: The Imperial College modelers released the source code a couple of days ago to the model that shut down the world economy. It's not the original model code but was rather…

It's worth noting that in a pandemic situation, waiting before taking action is "making a decision"

Shutting down the economy is costly, yes, but allowing a virus to continue its exponential growth with all of the unknowns that entails is much more costly in expectation (we can only speak in expectation given the unknowns)

Whether or not this model should have been the basis for such a decision I don't know, but it's important to keep in mind that taking proactive steps in a pandemic is conservative

Re: To software engineers criticizing Neil Ferguson’s epidemics simulation code

#25
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 foot. It’s also you, the software engineering community, that has made no effort to warn the non-expert public of the dangers of these tools"

that's a bit much. if someone buys a lathe, gets it home, flips the switch and tears off an arm are machinists to blame?

Re: To software engineers criticizing Neil Ferguson’s epidemics simulation code

#26
post #19

I'm somewhat skeptical. Firstly, I don't think the language is the problem with scientific code. You can write messy code in any language. So the warning then has to be about writing software in general. In that case, I think a warning like "don't try to write software unless you have years of training" is a bit much. Many people with no training learn to write nice code. Many projects made by amateurs might have ugl…

I'd like to point out I've met a lot of software engineers that subscribe to two in reverse. "This domain area of expertise is much easier than programming, ergo I am qualified to solve it."

Re: To software engineers criticizing Neil Ferguson’s epidemics simulation code

#27
post #3

I get what he’s saying, but the “non-experts” using code to represent their models should also let outside help come when the need arises. When your model predicts an apocalyptical scenario and government is taking drastic measures based on it, it’s a good time to expose your “non-expert code” to the software engineering communities (and all other associated fields) to take a look.

should also let outside help come when the need arises. 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.…

I will personally pay for a professional review of the next model the British government uses to guide lockdowns. Cost problem solved.

Re: To software engineers criticizing Neil Ferguson’s epidemics simulation code

#28

this is quite off the mark. the author sets the bar too low for himself by criticizing the most easily (and to be fair legitimately) dismissed criticisms of the Imperial College model. here's a better laid-out critique that the OP doesn't speak to: The Imperial College modelers released the source code a couple of days ago to the model that shut down the world economy. It's not the original model code but was rather…

> Any such model ought to have been independently reviewed before it is ever used for real policy decisions. Policy analysis is awash in models but no one ever really checks them. Going forward, health policy makers should ask for and disclose independent validation of any model before using its results to make recommendations of any consequence.

That's ignoring the time-limited nature of a virus response. "No decision" is itself a decision. Delay has a real cost, and using a potentially imperfect model is simply using the best information at hand.

I think everyone would agree that the ideal is to have well-documented, thoroughly-tested, easy-to-use, and bulletproof models to inform public response to every emergency. However, those models can't be built instantly, and that kind of bulletproofing is not directly relevant to the day-to-day research work aided by such models.

Adding research capacity to ensure that governments have a stable of well-researched, thoroughly-vetted models for emergencies would be a great thing, but it would also be quite expensive. Keeping any single model up to spec might be the job of 1FTE (so an additional ~$150k/grant/yr -- large for a research budget but small for a government), but that would have to be multiplied by every area where the government might possibly want research-informed decisionmaking on short notice.

> Even if the documentation, coding, and testing problems were fixed, the model logic is fatally flawed, which is evidenced by its poor forecasting performance.

That sounds like a great scientific criticism! Model validation is the cornerstone of research on computer models of things, and finding a poor forecast opens the door to many great research questions.

But without that further research, "poor performance" sounds a (loud) note of caution, but isn't necessarily fatal. The leading-order problem is to understand why the model performed poorly: was it improperly calibrated with information known at the time (such as if the virus behaves differently than assumed)? Was there some out-of-sample feature of the forecast that the model would not expect to do well on (e.g., low death rates in an open society because everything was shut down for severe weather anyway?) Is an overall trend correct but the timing in error?

"Flawed," I think, can be easily shown, and this should probably be expected in a research model. "Fatally flawed," however, is a stronger claim that must pass a greater burden of proof.

Re: To software engineers criticizing Neil Ferguson’s epidemics simulation code

#29

this is quite off the mark. the author sets the bar too low for himself by criticizing the most easily (and to be fair legitimately) dismissed criticisms of the Imperial College model. here's a better laid-out critique that the OP doesn't speak to: The Imperial College modelers released the source code a couple of days ago to the model that shut down the world economy. It's not the original model code but was rather…

> the model logic is fatally flawed, which is evidenced by its poor forecasting performance.

Where's the proof the model is flawed? The criticism goes both ways, if on one side the model does not have documentation, it's also fair to say that if someone claims it's "fatally flawed" they need to point out in the code where the issues are.

Re: To software engineers criticizing Neil Ferguson’s epidemics simulation code

#30
post #3

I get what he’s saying, but the “non-experts” using code to represent their models should also let outside help come when the need arises. When your model predicts an apocalyptical scenario and government is taking drastic measures based on it, it’s a good time to expose your “non-expert code” to the software engineering communities (and all other associated fields) to take a look.

I don't think the government is taking drastic measures based solely on this code. It's just a way to model facts we already know. We know that viruses spread exponentially, and we know what exponential growth looks like this just lets use model different assumptions to see how they affect that model.

The model is way more granular than that. Have you read it?
Post reply on HN