10 ms·

Why we can ignore reviews of scientific code by commercial software developers

25 points by brunojppb 6y ago

draw_down 6y ago
Sure, don’t ask them to fix or debug it either.
guscost 6y ago
We should probably ignore most "scientific code" altogether. The jig is up. https://cacm.acm.org/magazines/2010/9/98038-science-has-only-two-legs/ https://cacm.acm.org/magazines/2010/9/98038-science-has-only... https://guscost.com/2020/05/12/pandemic-woo/ https://guscost.com/2020/05/12/pandemic-woo/
VMG 6y ago
This is just a list of excuses. Following good practices have nothing to do whether it is "commercial software" or "front-end software", as the author claims.
- mekane8 6y ago
  Agreed, especially the stuff about end users. Of course you want to prevent bugs that will impact users, but many of the other things being discussed have nothing to do with whether there is a non-technical person using the software.
techopoly 6y ago
I dislike this philosophy, that a person in one field of expertise can have nothing constructive to say about another, or can't learn it. Reminds me of "don't roll your own cryptography." Well, all the standard cryptographic algorithms were rolled by someone, and they had to have thrown out their first pancake too.
- turbine29 6y ago
  Especially when there is such a big overlap between software engineering and scientific computing. Not all software engineers write to-do apps in angular
OneGuy123 6y ago
Garbage article, quote from it: "They aren’t worried about it — not because this is a disaster they are trying to cover up, but because this is a routine bug that doesn’t really affect anything important." If you have a bug you can never know the side effects that it can be causing. So neither the article author nor the guys who wrote the covid sim understand complex systems. It would do them much good to read a few works by Taleb. Their problem is that they don't know what they don't know, they think they know what they don't know, but they don't. Also saying that it's "ok that scientific code is crappy formated/strutured" clearly demonstrates that these people, neither the author of the article, truly understand intuitively how quickly things can (and always do) go wrong with programs because they are complex beasts. This reads as an acadmic without truly intuitive knowledge of how things can go badly defending other academics. If a product is meant to put millions into quarantine it must be damn well tested and not a quick demo playground. A good product can obviously evolve from a quick academic playground, but academics seem to finish a product fully so rarely that they don't understand that unless they test it severly thourougly that it will have bugs.
- stmfreak 6y ago
  But I just read that your opinion isn’t valid because you are a software developer and not a scientist. The deity doesn’t speak through you! /s
  - OneGuy123 6y ago
    Yes indeed, I apologize and prostrate myself in front of the all-knowing gods of academia who never do anything wrong. /s
- matthewdgreen 6y ago
  Most scientific software developers have been developing and working with enormously complex codebases for years. You're clearly starting from the perspective that they're eggheads who have no experience with this area; that assumption is almost certainly wrong.
  - 6y ago
turbine29 6y ago
This is just a list of excuses. Yes, there are different standards, for scientific code compared to a website. but any number that is used for a decision, should be up to a standard. Including unit tests, readability and cleanliness. If it’s just a model, and ‘doesn’t need these’ then it should remain in the lab and far from policy decisions.
returningfory 6y ago
The article says: > While these checks could also be handled by unit tests, most scientists generally just end up with their own weird set of ad hoc test outputs and print statements. It’s ugly, and not infallible, but it tends to work well given the intensive nature of our result-testing behaviour and community cross-checking. The sense in which this statement is plainly wrong is actually addressed in the original article: > Regressions like that are common when working on a complex piece of software, which is why industrial software-engineering teams write automated regression tests. This is the whole point. You can only run your "ad hoc" print-statement-based tests once off, which is why such "tests" are useless for finding regressions.
Zecar 6y ago
Alarm bells are ringing from their refusal to release the original code. There is no justification whatsoever for that, and the excuses given are totally unrealistic.
matthewdgreen 6y ago
Scientific code is no different than prototypes of commercial products. The goal is to iterate quickly, rather than to make a perfect releasable product. Take a look at the early internal sketches of the iPhone and iPad and you'll see they look massively less elegant than commercial products: but nobody writes breathless articles about how Apple Does Not Known How To Design Consumer Products because of it.
- turbine29 6y ago
  Apple prototypes are not public nor are used to inform major decisions about public health policy
- electrograv 6y ago
  I think the problem here is when buggy “science code” / “prototype code” is used to inform life-and-death decisions made in the real world. It is therefore rather irresponsible of the scientific community to allow such a bad state of code technical debt to live on for so long, when it’s dealing with a field that is inherently tied to the study of life-or-death scenarios (like we are facing right now). The only way to avoid this inevitable conclusion of irresponsibility would be if the scientists behind the model warned that it cannot be trusted at all due to the potential of a large number of unknown bugs (did they?). Otherwise, either the scientists are irresponsibility incapable of understanding how to write reliable complex code, or were not honest about the trustworthiness of their code.
  - matthewdgreen 6y ago
    We're in the middle of a rapidly-evolving epidemic that is killing thousands of people per day. Leaders need information, even imperfect information right now. There is no time to hire a team of production engineers so they can release a slightly more stable multi-core version 1.0 in 2023. If there is ever an asteroid heading towards the earth, I swear that some segment of HN will write angry articles about how the hastily built nuclear-powered spaceship we sent to intercept it doesn't have proper unit tests. They'll demand that we delay the launch until 300 days after impact.
preordained 6y ago
So, I looked at the article they are refuting (or one of them?) and expected a bunch of superficial criticism as suggested in this refutation, but it does not look to me at all that "superficial" criticism is being defended against: https://lockdownsceptics.org/code-review-of-fergusons-model/ https://lockdownsceptics.org/code-review-of-fergusons-model/ ^^^Swallow your politics if you can for a moment and read. At a minimum it seems that the rebuttal here was being argued in very bad faith. Given the stage set, I was expecting bikeshedding about the Law if Demeter or JSON vs other format, etc...
ken 6y ago
> A software developer will care more about maintainability and end-user experience than a scientific coder, who will likely prize flexibility and control instead. Importantly, this means that programming patterns and norms that work for one may not work for the other — exhortations to keep code simple, to remove cruft, to limit the number of parameters and settings, might actually interfere with the intended applications of a scientific code for example. Granted, but when publishing, these need to be primary concerns. Source code, then, is a communications medium. Many famous scientists like Einstein and Feynman would do their work in their heads, not by filling blackboards with equations. When they needed to publish, they'd write down equations because that is the medium of communications. You make it as simple as possible, so people can follow you. E=mc^2 is brilliant because it is so simple. Maxwell's equations got a lot more traction once they were simplified down to just 4. Scientists using computers for research or analysis are welcome to use any messy code they want, but if they wish for others to follow their work, they need to clean it up to the standards of the industry. It was beat into my head from a young age that research is only part of being a scientist. You also need to be able to communicate your ideas -- hence all of the writing class requirements. Scientists need to take this to heart, and if they wish to publish in terms of source code, to write source code that others can read. When even professionals in the field have trouble verifying your work, you've got a problem. It's been a while since I worked in scientific computing, but I never saw a single published paper with a program where the program even matched the description in the paper it was attached to.
- mekane8 6y ago
  Yes, I agree with this. Everyone is welcome to write their own messy code while in the "get it working" phase, but it needs to be cleaned up and made somewhat verifiable before it is shared with others. I currently work with and mentor software development interns, some of whom are aspiring data scientists, and we make sure to give them training on how to write clean code.
- pvg 6y ago
  There's no quality of communication that can magically circumvent a motivated-reasoning sort of critique. That's why this is an issue with the critique and not the other way round. As a trivial historical example - an entire world superpower regularly and persistently engaged in and acted on large-scale unscientific motivated reasoning against its own self-interest and the problem with that was not that the best scientifically verifiable ideas available were inadequately communicated.
matthewdgreen 6y ago
I read the critique in depth. Let me summarize the claims: 1. The developers had a couple of bugs that cause non-deterministic outputs in weird settings. It's a randomized model so this isn't a disaster, but obviously it would be better to have all non-determinism derived from a single seed. However, none of the bugs point to scientific issues. Still, these are real bugs that should be fixed. And indeed: another team pointed out some issues, they triaged the report, and it appears that they've been fixing these issues. 2. The code doesn't run well multi-threaded, and so the scientists run it on a single core. This seems like a feature the developers have de-prioritized. The critics make a HUGE deal about how using a single core is inefficient, but at the end of the day: if scientists can get simulations done in a reasonable time using a single core, this seems like a valid prioritization of limited development effort. The critics know better, obviously. 3. There aren't a bunch of unit tests. But as the authors point out code is in development and being altered continuously to reflect new developments in society and new knowledge about the virus, so it seems hard to develop unit tests that won't become broken as the underlying components change. 4. The critics seem to have a strong grounding in epidemiology. I'm just kidding, they claim to be pure software engineers, but still insist on spending a significant fraction of their critique disputing the calculation of R0 and lecturing the epidemiologists on how they think it should be calculated. This is a giant red flag given that the critics' sole stated expertise is software engineering. 5. The developers are continuing to add features to simulate new aspects of the ongoing pandemic (e.g., new code to simulate the impact of contact tracing apps) instead of fixing every minor issue in the code. Given that we're in the midst of a deadly epidemic that is putting human beings into the ground, this seems like a completely unavoidable resource allocation decision to me. 6. The critics can't even be bothered to pretend their criticism is objective. E.g., the piece concludes with "on a personal level, I’d go further and suggest that all academic epidemiology be defunded." Yeah, sure, you're a totally disinterested software expert here. I guarantee you if you look at any piece of software -- commercial or scientific, no matter the budget -- with the politically-motivated goal of tearing apart the author, you will succeed. I can say this having spent years doing security and expert witness code reviews for some of the biggest and smallest companies in the software industry. This piece isn't a critique, it's just a hatchet job. And not even a particularly creative one.
- 6y ago
Silhouette 6y ago
The sheer arrogance displayed in this article is breathtaking. Scientists are so super-smart that not only are they experts on the science, they are also better at the entirely orthogonal skill of programming than the entire programming industry! The results from using this software have directly influenced political decisions that have resulted in the greatest mass curtailment of personal liberty in modern history, not to mention the rest of the response to a public health situation that is going to cost hundreds of thousands of lives around the world. The idea that code that demonstrably contains bugs and exhibits non-deterministic behaviour, written in a style that has proven time and again to be resistant to mechanical testing, formal verification or expert peer review, should be defended because while it's written in such a style that doesn't matter because this code was written by scientists is... I don't even have strong enough words. It's laughable. It's patently absurd. Sorry for the slightly ranty comment, but I am genuinely furious that people are trying to defend this work in this way. It is insulting to me as a professional software developer who has also worked on many scientific and engineering programs over the years. It is the antithesis of good scientific practice, where methods are transparently disclosed and peer review and attempts to reproduce (or fail to reproduce) important results are actively encouraged. And it is downright offensive to me as someone who can't look after close family members right now because laws made in no small part because of this software prevent it.
zwieback 6y ago
In my time in research I've come across this contemptuous attitude scientists have for coders and engineers again and again. It's just arrogance and insecurity mixed together and has no place in today's research environments where results depend more and more on complex models.
wcoenen 6y ago
This reminds me of those code reviews where you have a colleague that prefers to spend hours trying to refute reasonable minor comments, instead of 5 minutes to address them.
- lostmsu 6y ago
  > refute reasonable minor comments If they are truly minor, they should not block the change. I am guessing colleague tries to refute reasonability, which totally makes sense, because if in every review they have to fix minor unreasonable comments to progress, that stalls the thing completely.
- watwut 6y ago
  Refuting them is addressing them. The other person simply disagrees.
gammarator 6y ago
Whether the Imperial code is good or bad doesn't actually matter: you can derive the headline numbers that motivated the lockdowns analytically, without any simulation at all [1]. (The real problem with the worst case estimate is that it assumes people don't individually change their behavior in the face of a pandemic.) [1] https://twitter.com/trvrb/status/1258879531022082049 https://twitter.com/trvrb/status/1258879531022082049
unsrsly 6y ago
This debate is sort of in the weeds. The models are not that important. We have plenty of real world evidence to be very concerned about Covid19. The following facts are not contradictory: 1. The code is bad, maybe even unreliable 2. Scientific software should adhere to best practices for software development 3. At a bare minimum, complex simulation software should be able to generate correct answers for well-understood toy models 4. Covid19 is a dangerous disease that can spread exponentially and kill a lot of people if mitigation measures are not taken (look at Wuhan, Lombardy, NYC)

25 points by brunojppb 6y ago

Sure, don’t ask them to fix or debug it either.

We should probably ignore most "scientific code" altogether. The jig is up. https://cacm.acm.org/magazines/2010/9/98038-science-has-only-two-legs/ https://cacm.acm.org/magazines/2010/9/98038-science-has-only... https://guscost.com/2020/05/12/pandemic-woo/ https://guscost.com/2020/05/12/pandemic-woo/

VMG 6y ago

This is just a list of excuses. Following good practices have nothing to do whether it is "commercial software" or "front-end software", as the author claims.

mekane8 6y ago
Agreed, especially the stuff about end users. Of course you want to prevent bugs that will impact users, but many of the other things being discussed have nothing to do with whether there is a non-technical person using the software.

techopoly 6y ago

I dislike this philosophy, that a person in one field of expertise can have nothing constructive to say about another, or can't learn it. Reminds me of "don't roll your own cryptography." Well, all the standard cryptographic algorithms were rolled by someone, and they had to have thrown out their first pancake too.

turbine29 6y ago
Especially when there is such a big overlap between software engineering and scientific computing. Not all software engineers write to-do apps in angular

OneGuy123 6y ago

Garbage article, quote from it: "They aren’t worried about it — not because this is a disaster they are trying to cover up, but because this is a routine bug that doesn’t really affect anything important." If you have a bug you can never know the side effects that it can be causing. So neither the article author nor the guys who wrote the covid sim understand complex systems. It would do them much good to read a few works by Taleb. Their problem is that they don't know what they don't know, they think they know what they don't know, but they don't. Also saying that it's "ok that scientific code is crappy formated/strutured" clearly demonstrates that these people, neither the author of the article, truly understand intuitively how quickly things can (and always do) go wrong with programs because they are complex beasts. This reads as an acadmic without truly intuitive knowledge of how things can go badly defending other academics. If a product is meant to put millions into quarantine it must be damn well tested and not a quick demo playground. A good product can obviously evolve from a quick academic playground, but academics seem to finish a product fully so rarely that they don't understand that unless they test it severly thourougly that it will have bugs.

stmfreak 6y ago
But I just read that your opinion isn’t valid because you are a software developer and not a scientist. The deity doesn’t speak through you! /s
- OneGuy123 6y ago
  Yes indeed, I apologize and prostrate myself in front of the all-knowing gods of academia who never do anything wrong. /s
matthewdgreen 6y ago
Most scientific software developers have been developing and working with enormously complex codebases for years. You're clearly starting from the perspective that they're eggheads who have no experience with this area; that assumption is almost certainly wrong.
- 6y ago

turbine29 6y ago

This is just a list of excuses. Yes, there are different standards, for scientific code compared to a website. but any number that is used for a decision, should be up to a standard. Including unit tests, readability and cleanliness. If it’s just a model, and ‘doesn’t need these’ then it should remain in the lab and far from policy decisions.

returningfory 6y ago

The article says: > While these checks could also be handled by unit tests, most scientists generally just end up with their own weird set of ad hoc test outputs and print statements. It’s ugly, and not infallible, but it tends to work well given the intensive nature of our result-testing behaviour and community cross-checking. The sense in which this statement is plainly wrong is actually addressed in the original article: > Regressions like that are common when working on a complex piece of software, which is why industrial software-engineering teams write automated regression tests. This is the whole point. You can only run your "ad hoc" print-statement-based tests once off, which is why such "tests" are useless for finding regressions.

Zecar 6y ago

Alarm bells are ringing from their refusal to release the original code. There is no justification whatsoever for that, and the excuses given are totally unrealistic.

matthewdgreen 6y ago

Scientific code is no different than prototypes of commercial products. The goal is to iterate quickly, rather than to make a perfect releasable product. Take a look at the early internal sketches of the iPhone and iPad and you'll see they look massively less elegant than commercial products: but nobody writes breathless articles about how Apple Does Not Known How To Design Consumer Products because of it.

turbine29 6y ago
Apple prototypes are not public nor are used to inform major decisions about public health policy
electrograv 6y ago
I think the problem here is when buggy “science code” / “prototype code” is used to inform life-and-death decisions made in the real world. It is therefore rather irresponsible of the scientific community to allow such a bad state of code technical debt to live on for so long, when it’s dealing with a field that is inherently tied to the study of life-or-death scenarios (like we are facing right now). The only way to avoid this inevitable conclusion of irresponsibility would be if the scientists behind the model warned that it cannot be trusted at all due to the potential of a large number of unknown bugs (did they?). Otherwise, either the scientists are irresponsibility incapable of understanding how to write reliable complex code, or were not honest about the trustworthiness of their code.
- matthewdgreen 6y ago
  We're in the middle of a rapidly-evolving epidemic that is killing thousands of people per day. Leaders need information, even imperfect information right now. There is no time to hire a team of production engineers so they can release a slightly more stable multi-core version 1.0 in 2023. If there is ever an asteroid heading towards the earth, I swear that some segment of HN will write angry articles about how the hastily built nuclear-powered spaceship we sent to intercept it doesn't have proper unit tests. They'll demand that we delay the launch until 300 days after impact.

preordained 6y ago

So, I looked at the article they are refuting (or one of them?) and expected a bunch of superficial criticism as suggested in this refutation, but it does not look to me at all that "superficial" criticism is being defended against: https://lockdownsceptics.org/code-review-of-fergusons-model/ https://lockdownsceptics.org/code-review-of-fergusons-model/ ^^^Swallow your politics if you can for a moment and read. At a minimum it seems that the rebuttal here was being argued in very bad faith. Given the stage set, I was expecting bikeshedding about the Law if Demeter or JSON vs other format, etc...

ken 6y ago

> A software developer will care more about maintainability and end-user experience than a scientific coder, who will likely prize flexibility and control instead. Importantly, this means that programming patterns and norms that work for one may not work for the other — exhortations to keep code simple, to remove cruft, to limit the number of parameters and settings, might actually interfere with the intended applications of a scientific code for example. Granted, but when publishing, these need to be primary concerns. Source code, then, is a communications medium. Many famous scientists like Einstein and Feynman would do their work in their heads, not by filling blackboards with equations. When they needed to publish, they'd write down equations because that is the medium of communications. You make it as simple as possible, so people can follow you. E=mc^2 is brilliant because it is so simple. Maxwell's equations got a lot more traction once they were simplified down to just 4. Scientists using computers for research or analysis are welcome to use any messy code they want, but if they wish for others to follow their work, they need to clean it up to the standards of the industry. It was beat into my head from a young age that research is only part of being a scientist. You also need to be able to communicate your ideas -- hence all of the writing class requirements. Scientists need to take this to heart, and if they wish to publish in terms of source code, to write source code that others can read. When even professionals in the field have trouble verifying your work, you've got a problem. It's been a while since I worked in scientific computing, but I never saw a single published paper with a program where the program even matched the description in the paper it was attached to.

mekane8 6y ago
Yes, I agree with this. Everyone is welcome to write their own messy code while in the "get it working" phase, but it needs to be cleaned up and made somewhat verifiable before it is shared with others. I currently work with and mentor software development interns, some of whom are aspiring data scientists, and we make sure to give them training on how to write clean code.
pvg 6y ago
There's no quality of communication that can magically circumvent a motivated-reasoning sort of critique. That's why this is an issue with the critique and not the other way round. As a trivial historical example - an entire world superpower regularly and persistently engaged in and acted on large-scale unscientific motivated reasoning against its own self-interest and the problem with that was not that the best scientifically verifiable ideas available were inadequately communicated.

matthewdgreen 6y ago

I read the critique in depth. Let me summarize the claims: 1. The developers had a couple of bugs that cause non-deterministic outputs in weird settings. It's a randomized model so this isn't a disaster, but obviously it would be better to have all non-determinism derived from a single seed. However, none of the bugs point to scientific issues. Still, these are real bugs that should be fixed. And indeed: another team pointed out some issues, they triaged the report, and it appears that they've been fixing these issues. 2. The code doesn't run well multi-threaded, and so the scientists run it on a single core. This seems like a feature the developers have de-prioritized. The critics make a HUGE deal about how using a single core is inefficient, but at the end of the day: if scientists can get simulations done in a reasonable time using a single core, this seems like a valid prioritization of limited development effort. The critics know better, obviously. 3. There aren't a bunch of unit tests. But as the authors point out code is in development and being altered continuously to reflect new developments in society and new knowledge about the virus, so it seems hard to develop unit tests that won't become broken as the underlying components change. 4. The critics seem to have a strong grounding in epidemiology. I'm just kidding, they claim to be pure software engineers, but still insist on spending a significant fraction of their critique disputing the calculation of R0 and lecturing the epidemiologists on how they think it should be calculated. This is a giant red flag given that the critics' sole stated expertise is software engineering. 5. The developers are continuing to add features to simulate new aspects of the ongoing pandemic (e.g., new code to simulate the impact of contact tracing apps) instead of fixing every minor issue in the code. Given that we're in the midst of a deadly epidemic that is putting human beings into the ground, this seems like a completely unavoidable resource allocation decision to me. 6. The critics can't even be bothered to pretend their criticism is objective. E.g., the piece concludes with "on a personal level, I’d go further and suggest that all academic epidemiology be defunded." Yeah, sure, you're a totally disinterested software expert here. I guarantee you if you look at any piece of software -- commercial or scientific, no matter the budget -- with the politically-motivated goal of tearing apart the author, you will succeed. I can say this having spent years doing security and expert witness code reviews for some of the biggest and smallest companies in the software industry. This piece isn't a critique, it's just a hatchet job. And not even a particularly creative one.

6y ago

Silhouette 6y ago

The sheer arrogance displayed in this article is breathtaking. Scientists are so super-smart that not only are they experts on the science, they are also better at the entirely orthogonal skill of programming than the entire programming industry! The results from using this software have directly influenced political decisions that have resulted in the greatest mass curtailment of personal liberty in modern history, not to mention the rest of the response to a public health situation that is going to cost hundreds of thousands of lives around the world. The idea that code that demonstrably contains bugs and exhibits non-deterministic behaviour, written in a style that has proven time and again to be resistant to mechanical testing, formal verification or expert peer review, should be defended because while it's written in such a style that doesn't matter because this code was written by scientists is... I don't even have strong enough words. It's laughable. It's patently absurd. Sorry for the slightly ranty comment, but I am genuinely furious that people are trying to defend this work in this way. It is insulting to me as a professional software developer who has also worked on many scientific and engineering programs over the years. It is the antithesis of good scientific practice, where methods are transparently disclosed and peer review and attempts to reproduce (or fail to reproduce) important results are actively encouraged. And it is downright offensive to me as someone who can't look after close family members right now because laws made in no small part because of this software prevent it.

zwieback 6y ago

In my time in research I've come across this contemptuous attitude scientists have for coders and engineers again and again. It's just arrogance and insecurity mixed together and has no place in today's research environments where results depend more and more on complex models.

wcoenen 6y ago

This reminds me of those code reviews where you have a colleague that prefers to spend hours trying to refute reasonable minor comments, instead of 5 minutes to address them.

lostmsu 6y ago
> refute reasonable minor comments If they are truly minor, they should not block the change. I am guessing colleague tries to refute reasonability, which totally makes sense, because if in every review they have to fix minor unreasonable comments to progress, that stalls the thing completely.
watwut 6y ago
Refuting them is addressing them. The other person simply disagrees.

gammarator 6y ago

Whether the Imperial code is good or bad doesn't actually matter: you can derive the headline numbers that motivated the lockdowns analytically, without any simulation at all [1]. (The real problem with the worst case estimate is that it assumes people don't individually change their behavior in the face of a pandemic.) [1] https://twitter.com/trvrb/status/1258879531022082049 https://twitter.com/trvrb/status/1258879531022082049

unsrsly 6y ago

This debate is sort of in the weeds. The models are not that important. We have plenty of real world evidence to be very concerned about Covid19. The following facts are not contradictory: 1. The code is bad, maybe even unreliable 2. Scientific software should adhere to best practices for software development 3. At a bare minimum, complex simulation software should be able to generate correct answers for well-understood toy models 4. Covid19 is a dangerous disease that can spread exponentially and kill a lot of people if mitigation measures are not taken (look at Wuhan, Lombardy, NYC)