6 ms·

> This is because there generally isn't a known mechanism for vaccines to have long term effects. I know a lot of people believe this, but as a developer who r

> This is because there generally isn't a known mechanism for vaccines to have long term effects. I know a lot of people believe this, but as a developer who regularly deploys code to production, this mindset blows me away. I'm not saying that being a developer means I know anything about this. I'm well aware of my (our? I don't know what you do) peoples habit of thinking being good at our craft means we're also somehow suddenly good at others. But if I told someone that I don't need to know the effects of v7.1.3 before patching it because I can't think of a mechanism for it going wrong, and besides, we already released all those other versions and they were fine, I'd hopefully be fired. I get it, software and medicine are different things, and some things just aren't practical in meat space, but the mindset around testing is something that I think will always be difficult for me to understand after being in this occupation for so long.

copperx 5y ago
I'm pretty sure understanding the biology behind it all can help make predictions about the outcome in the same way that you know that merging a pull request isn't going to bring the entire internet down. I mean, it could. But there's no known mechanism that will trigger such an event. That reminds me of the first atomic bomb test. We weren't 100% sure that the atmosphere wasn't going to ignite with an atomic bomb, but those that knew the physics knew it was almost impossible. > "If, after calculation, [Compton] said, it were proved that the chances were more than approximately three in one million that the earth would be vaporized by the atomic explosion, he would not proceed with the project. Calculation proved the figures slightly less -- and the project continued." https://www.insidescience.org/manhattan-project-legacy/atmosphere-on-fire https://www.insidescience.org/manhattan-project-legacy/atmos...
- ifyoubuildit 5y ago
  > I'm pretty sure understanding the biology behind it all can help make predictions about the outcome ... Of course it can, that's what you use to write your test plan. But I never (ever) rely on those predictions alone. Everyone who has done this long enough knows that if you don't test your code well enough before you push it out, it will fail. Hell, it'll even fail sometimes when you did thoroughly test it.
  - copo233 5y ago
    Yeah but you know, as much as you know anything else really, that your code won't break your toaster.
    - ifyoubuildit 5y ago
      https://www.amazon.com/Tovala-Gen-Multi-Mode-Programmable-Stainless/dp/B07K85LXBK https://www.amazon.com/Tovala-Gen-Multi-Mode-Programmable-St...
  - pixl97 5y ago
    Well, in computers our test plans generally run in seconds. If you had to push code and wait a year for feedback then how you tested and pushed code would change dramatically. Now imagine the environment you were pushing code to was 1. Always changing in very small ways that could sometimes have huge affects due to completely random variable changes you had no control over. 2. Every host your ran your software on 'could be' different in ways that are incompatible and you have no way of testing all of them. Welcome to the problem space of biology.
    - ifyoubuildit 5y ago
      Well said. But some people take this as "well we can't realistically do the exhaustive test, and we really want this thing, so let's assume the outcome will be positive". That's fine when it's your own choice, but it's not when you're forcing it on other people.
joshuamorton 5y ago
> But if I told someone that I don't need to know the effects of v7.1.3 before patching it because I can't think of a mechanism for it going wrong, and besides, we already released all those other versions and they were fine, I'd hopefully be fired. But this isn't what they're saying. They're saying that there are few to no ways for it to not have any detectable issues for 6 months and then suddenly go wrong (which I'll note is also true for software!). Canarying and staged rollouts are a good idea in software, as they are in medicine. But much like you don't think its necessary to canary v7.1.3 for a year, just in case it has a bug that makes it shut down suddenly after 200 days, its probably not necessary to wait a year to see if a vaccine causes sudden acute liver failure after 7 months, because there just isn't a biological mechanism for it to do that (the vaccine is already out of your body by that point!). And to the extend that such issues are possible (leap days can do weird stuff), we can look specifically for those mechanisms (like say monitoring for stuff that would lead to liver damage in the weeks after vaccination).
- ifyoubuildit 5y ago
  > But this isn't what they're saying. They're saying that there are few to no ways for it to not have any detectable issues for 6 months and then suddenly go wrong (which I'll note is also true for software!). Over the years I've become a little obsessed with imagining the ways things can fail (I'm just as fun at parties as you can probably imagine). An example that immediately jumps to mind where that is not true for software would be something that quietly uses some resource that you didn't expect (open ports, filehandles, space on disk/memory, the space inside of however many bits you have for a field, anything like that). These are things that you don't know to test until you've seen them fail, and only then can you start to automate. One possible analogy here is cancer or autoimmune issues. If you get diagnosed with either of those today, they almost certainly started a while ago, they just weren't detectable until today. Or maybe they would have been if you knew exactly where to look, just like if you knew to keep an eye on how many ports you had left on your live server. (Not claiming these vaccines cause these things, I'm sure some peoples blood pressure started rising as they read this). The complexity of software is nowhere near that of the human body or populations of humans, and yet it can be incredibly hard to predict. Multiple backwards compatible versions on the client and server side, running on different hardware with different operating systems, all of these things changing over time. Unexpected behaviors can absolutely show up at any time. Of course you can't test it all, but you do what you can, and then after that you monitor very carefully, but its way more expensive to fix the problem after it reaches prod. In humans, there's a chance that its not just expensive, it's impossible.
outworlder 5y ago
> But if I told someone that I don't need to know the effects of v7.1.3 before patching it because I can't think of a mechanism for it going wrong, and besides, we already released all those other versions and they were fine, I'd hopefully be fired. You are missing the point. If someone told you they are worried that your code is going to turn the CPU into strawberry jelly, you would be correct if you said 'there's no known mechanism that will cause that'.
- ifyoubuildit 5y ago
  Analogies are always flawed, but in this one, the pharmaceutical is the code and the human population is the set of machines its going to run on. The adverse effect would be an error that happens during runtime. It's not quite strawberry jelly, but depending on the target you're writing for, you could destroy the actual hardware (think embedded devices). If you presuppose that adverse effects can't happen, then sure, your quip makes sense. But pharmaceuticals having adverse effects isn't some unimaginable thing, it's expected and tested for.
  - cthalupa 5y ago
    >But pharmaceuticals having adverse effects isn't some unimaginable thing, it's expected and tested for. Not for potential issues tens of years later, which is basically the concern people are raising about these vaccines. We instead look at known potential mechanisms that could cause harm and operate off of that. We have studied the short term side effects of these vaccines, much we do anything else, and have looked at known potential mechanisms that could cause issues down the line, and have not identified any. This is more or less the same standard applied to just about any medical research for drugs, vaccines, other treatments, etc.
    - ifyoubuildit 5y ago
      > Not for potential issues tens of years later, which is basically the concern people are raising about these vaccines. I am concerned about tens of years later, but also about just ones of years later as well. We've done the best we can so far, and it seems like a clear win for some categories of people. For others, it's not so clear (like young healthy people with a previous infection living in the age of omicron for example. This is not medical advice, go to your doctor for that). > This is more or less the same standard applied to just about any medical research for drugs, vaccines, other treatments, etc. Sure, but I'm not chomping at the bit to take any more of those either (already had all the usual vaccines and then some, minus flu). And those other things have been around long enough that adverse effects eventually become unmissable. You see those occasionally in class action commercials.
johnny22 5y ago
I kinda think of it as if you were writing an unofficial third party client for a black box remote API that doesn't want third party clients and can update all their official clients in days or weeks in different ways.
- ifyoubuildit 5y ago
  Absolutely. That or trying to reverse engineer a binary and patch it to do something new, while its constantly updating itself at the same time.
snowwrestler 5y ago
The thing to understand about vaccines is that they trigger things that your body does all the time by itself. A vaccine is more like kicking off a job than deploying new source code.
- ifyoubuildit 5y ago
  > The thing to understand about vaccines is that they trigger things that your body does all the time by itself I'm not against vaccines at all for the record. But this doesn't seem like a strong argument for them. Cells multiply by themselves all the time. Triggering that effect is how you get cancer. Your heart beats constantly. Triggering that too much (or in the wrong rhythm) is not a good thing. There are probably a ton more examples.
  - selcuka 5y ago
    > Cells multiply by themselves all the time. Triggering that effect is how you get cancer. Your heart beats constantly. Triggering that too much (or in the wrong rhythm) is not a good thing. Those are wrong analogies though. Vaccines don't trigger something too much. They trigger the exact same mechanism that will be triggered anyway when you get infected with the actual virus, but in a safe way.

copperx 5y ago

I'm pretty sure understanding the biology behind it all can help make predictions about the outcome in the same way that you know that merging a pull request isn't going to bring the entire internet down. I mean, it could. But there's no known mechanism that will trigger such an event. That reminds me of the first atomic bomb test. We weren't 100% sure that the atmosphere wasn't going to ignite with an atomic bomb, but those that knew the physics knew it was almost impossible. > "If, after calculation, [Compton] said, it were proved that the chances were more than approximately three in one million that the earth would be vaporized by the atomic explosion, he would not proceed with the project. Calculation proved the figures slightly less -- and the project continued." https://www.insidescience.org/manhattan-project-legacy/atmosphere-on-fire https://www.insidescience.org/manhattan-project-legacy/atmos...

ifyoubuildit 5y ago
> I'm pretty sure understanding the biology behind it all can help make predictions about the outcome ... Of course it can, that's what you use to write your test plan. But I never (ever) rely on those predictions alone. Everyone who has done this long enough knows that if you don't test your code well enough before you push it out, it will fail. Hell, it'll even fail sometimes when you did thoroughly test it.
- copo233 5y ago
  Yeah but you know, as much as you know anything else really, that your code won't break your toaster.
  - ifyoubuildit 5y ago
    https://www.amazon.com/Tovala-Gen-Multi-Mode-Programmable-Stainless/dp/B07K85LXBK https://www.amazon.com/Tovala-Gen-Multi-Mode-Programmable-St...
- pixl97 5y ago
  Well, in computers our test plans generally run in seconds. If you had to push code and wait a year for feedback then how you tested and pushed code would change dramatically. Now imagine the environment you were pushing code to was 1. Always changing in very small ways that could sometimes have huge affects due to completely random variable changes you had no control over. 2. Every host your ran your software on 'could be' different in ways that are incompatible and you have no way of testing all of them. Welcome to the problem space of biology.
  - ifyoubuildit 5y ago
    Well said. But some people take this as "well we can't realistically do the exhaustive test, and we really want this thing, so let's assume the outcome will be positive". That's fine when it's your own choice, but it's not when you're forcing it on other people.

joshuamorton 5y ago

> But if I told someone that I don't need to know the effects of v7.1.3 before patching it because I can't think of a mechanism for it going wrong, and besides, we already released all those other versions and they were fine, I'd hopefully be fired. But this isn't what they're saying. They're saying that there are few to no ways for it to not have any detectable issues for 6 months and then suddenly go wrong (which I'll note is also true for software!). Canarying and staged rollouts are a good idea in software, as they are in medicine. But much like you don't think its necessary to canary v7.1.3 for a year, just in case it has a bug that makes it shut down suddenly after 200 days, its probably not necessary to wait a year to see if a vaccine causes sudden acute liver failure after 7 months, because there just isn't a biological mechanism for it to do that (the vaccine is already out of your body by that point!). And to the extend that such issues are possible (leap days can do weird stuff), we can look specifically for those mechanisms (like say monitoring for stuff that would lead to liver damage in the weeks after vaccination).

ifyoubuildit 5y ago
> But this isn't what they're saying. They're saying that there are few to no ways for it to not have any detectable issues for 6 months and then suddenly go wrong (which I'll note is also true for software!). Over the years I've become a little obsessed with imagining the ways things can fail (I'm just as fun at parties as you can probably imagine). An example that immediately jumps to mind where that is not true for software would be something that quietly uses some resource that you didn't expect (open ports, filehandles, space on disk/memory, the space inside of however many bits you have for a field, anything like that). These are things that you don't know to test until you've seen them fail, and only then can you start to automate. One possible analogy here is cancer or autoimmune issues. If you get diagnosed with either of those today, they almost certainly started a while ago, they just weren't detectable until today. Or maybe they would have been if you knew exactly where to look, just like if you knew to keep an eye on how many ports you had left on your live server. (Not claiming these vaccines cause these things, I'm sure some peoples blood pressure started rising as they read this). The complexity of software is nowhere near that of the human body or populations of humans, and yet it can be incredibly hard to predict. Multiple backwards compatible versions on the client and server side, running on different hardware with different operating systems, all of these things changing over time. Unexpected behaviors can absolutely show up at any time. Of course you can't test it all, but you do what you can, and then after that you monitor very carefully, but its way more expensive to fix the problem after it reaches prod. In humans, there's a chance that its not just expensive, it's impossible.

outworlder 5y ago

> But if I told someone that I don't need to know the effects of v7.1.3 before patching it because I can't think of a mechanism for it going wrong, and besides, we already released all those other versions and they were fine, I'd hopefully be fired. You are missing the point. If someone told you they are worried that your code is going to turn the CPU into strawberry jelly, you would be correct if you said 'there's no known mechanism that will cause that'.

ifyoubuildit 5y ago
Analogies are always flawed, but in this one, the pharmaceutical is the code and the human population is the set of machines its going to run on. The adverse effect would be an error that happens during runtime. It's not quite strawberry jelly, but depending on the target you're writing for, you could destroy the actual hardware (think embedded devices). If you presuppose that adverse effects can't happen, then sure, your quip makes sense. But pharmaceuticals having adverse effects isn't some unimaginable thing, it's expected and tested for.
- cthalupa 5y ago
  >But pharmaceuticals having adverse effects isn't some unimaginable thing, it's expected and tested for. Not for potential issues tens of years later, which is basically the concern people are raising about these vaccines. We instead look at known potential mechanisms that could cause harm and operate off of that. We have studied the short term side effects of these vaccines, much we do anything else, and have looked at known potential mechanisms that could cause issues down the line, and have not identified any. This is more or less the same standard applied to just about any medical research for drugs, vaccines, other treatments, etc.
  - ifyoubuildit 5y ago
    > Not for potential issues tens of years later, which is basically the concern people are raising about these vaccines. I am concerned about tens of years later, but also about just ones of years later as well. We've done the best we can so far, and it seems like a clear win for some categories of people. For others, it's not so clear (like young healthy people with a previous infection living in the age of omicron for example. This is not medical advice, go to your doctor for that). > This is more or less the same standard applied to just about any medical research for drugs, vaccines, other treatments, etc. Sure, but I'm not chomping at the bit to take any more of those either (already had all the usual vaccines and then some, minus flu). And those other things have been around long enough that adverse effects eventually become unmissable. You see those occasionally in class action commercials.

johnny22 5y ago

I kinda think of it as if you were writing an unofficial third party client for a black box remote API that doesn't want third party clients and can update all their official clients in days or weeks in different ways.

ifyoubuildit 5y ago
Absolutely. That or trying to reverse engineer a binary and patch it to do something new, while its constantly updating itself at the same time.

snowwrestler 5y ago

The thing to understand about vaccines is that they trigger things that your body does all the time by itself. A vaccine is more like kicking off a job than deploying new source code.

ifyoubuildit 5y ago
> The thing to understand about vaccines is that they trigger things that your body does all the time by itself I'm not against vaccines at all for the record. But this doesn't seem like a strong argument for them. Cells multiply by themselves all the time. Triggering that effect is how you get cancer. Your heart beats constantly. Triggering that too much (or in the wrong rhythm) is not a good thing. There are probably a ton more examples.
- selcuka 5y ago
  > Cells multiply by themselves all the time. Triggering that effect is how you get cancer. Your heart beats constantly. Triggering that too much (or in the wrong rhythm) is not a good thing. Those are wrong analogies though. Vaccines don't trigger something too much. They trigger the exact same mechanism that will be triggered anyway when you get infected with the actual virus, but in a safe way.