8 ms·

> 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,

> 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.
- tylerhou 5y ago
  Let's suppose that your software currently has an incident where the service is degraded. For every day you don't push a fix, you lose 0.X% of revenue. Some engineer creates a fix by turning off some recently added experiment responsible for the service degradation. The rollback passes all unit tests and integration tests. You know this fix is low-risk (maybe because your service was healthy for the ~1 year prior to the rollout). Even if there is some risk that this rollback breaks the service at some point in the future, in comparison to the known revenue loss the expected loss of that breakage would be minimal. Another engineer objects to the rollback saying that "they don't know of the long term effects of such a rollback." You try to counter their claims by showing that previous rollbacks were almost always successful, and when they caused another failure that failure was not nearly as bad as the original service degradation. Also, the rollback passes all tests. That engineer then repeats "we don't know of the long term effects of this particular rollback, and I'm skeptical that the fix is good because the failing experiment and rollback was identified so quickly." (Rollback vs. fix-forward doesn't actually matter; the point is that all available knowledge shows that the fix is low risk, historically supported, and that there is likely no mechanism for random failure in 6+ months.) Do you think it would be correct to prefer the second engineer's claims?
  - ifyoubuildit 5y ago
    Yeah, I get your point, at the end of the day the net result is what we care about. But the assumptions that you use to calculate that net are where all of the disagreements stem from. In your example, you've constrained it to losing well defined revenue, and "you know this fix is low risk", so the answer is easy. Maybe (wrongly or rightly) you don't have faith in the revenue numbers, or in the test suite or the engineers writing the tests or the fix, maybe there's office politics involved, etc. This thread started with my reaction to these lines from op: > Knowing long-term effects (1+ years) is not a precondition of approval for most vaccines. It just so happens that vaccines usually take a long time for approval, so we end up knowing long-term effects as a side effect. This is because there generally isn't a known mechanism for vaccines to have long term effects. Not ruling out the possibility, but we understand how vaccines work pretty well. [...] I've seen this claim dozens of times, and it always always always makes me think of those scenarios where you find a bug in code that you or someone you trust/respect wrote from the ground up, and you wonder "how in the f*** did this ever work?". I'm not claiming I'm right to feel that way, maybe this is a defect in my character, but I just can't buy the "we understand vaccines pretty well" thing.

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.

tylerhou 5y ago
Let's suppose that your software currently has an incident where the service is degraded. For every day you don't push a fix, you lose 0.X% of revenue. Some engineer creates a fix by turning off some recently added experiment responsible for the service degradation. The rollback passes all unit tests and integration tests. You know this fix is low-risk (maybe because your service was healthy for the ~1 year prior to the rollout). Even if there is some risk that this rollback breaks the service at some point in the future, in comparison to the known revenue loss the expected loss of that breakage would be minimal. Another engineer objects to the rollback saying that "they don't know of the long term effects of such a rollback." You try to counter their claims by showing that previous rollbacks were almost always successful, and when they caused another failure that failure was not nearly as bad as the original service degradation. Also, the rollback passes all tests. That engineer then repeats "we don't know of the long term effects of this particular rollback, and I'm skeptical that the fix is good because the failing experiment and rollback was identified so quickly." (Rollback vs. fix-forward doesn't actually matter; the point is that all available knowledge shows that the fix is low risk, historically supported, and that there is likely no mechanism for random failure in 6+ months.) Do you think it would be correct to prefer the second engineer's claims?
- ifyoubuildit 5y ago
  Yeah, I get your point, at the end of the day the net result is what we care about. But the assumptions that you use to calculate that net are where all of the disagreements stem from. In your example, you've constrained it to losing well defined revenue, and "you know this fix is low risk", so the answer is easy. Maybe (wrongly or rightly) you don't have faith in the revenue numbers, or in the test suite or the engineers writing the tests or the fix, maybe there's office politics involved, etc. This thread started with my reaction to these lines from op: > Knowing long-term effects (1+ years) is not a precondition of approval for most vaccines. It just so happens that vaccines usually take a long time for approval, so we end up knowing long-term effects as a side effect. This is because there generally isn't a known mechanism for vaccines to have long term effects. Not ruling out the possibility, but we understand how vaccines work pretty well. [...] I've seen this claim dozens of times, and it always always always makes me think of those scenarios where you find a bug in code that you or someone you trust/respect wrote from the ground up, and you wonder "how in the f*** did this ever work?". I'm not claiming I'm right to feel that way, maybe this is a defect in my character, but I just can't buy the "we understand vaccines pretty well" thing.