12 ms·

"Uber is most reliable over the weekends when engineers don't change it" :)

kenrose 10y ago
We see this pattern at PagerDuty over the majority of our customers. There is a definite lull in alert volume over the weekends that picks up first thing Monday morning. It's led to my personal conclusion that most production issues are caused by people, not errant hardware or systems.
- asimuvPR 10y ago
  I've come to question releasing often as a result.
  - jon-wood 10y ago
    I can see the argument that if releasing causes things to break then don't release so frequently, but in practice the end result of that is lots of things breaking at once and having to unpick everything. Debugging is much easier if you're debugging a single change fresh in your mind.
    - bryanlarsen 10y ago
      Yeah, debugging 2 bugs that are shadowing each other often takes several orders of magnitude longer to debug than just a single issue.
    - Thrillington 10y ago
      While having tooling for tight debugging loops allows short release cycles, it leaves that decision up to the business
    - asimuvPR 10y ago
      You are right. Making small changes that can be isolated for debugging purposes is a good approach. What I mean is that we should always question "best" practices and how we apply them to our development process. These days there is a tendency to drink the kool-aid (guilty of this as well). DevOps is something that we are still learning and developing as a profession.
      - dozzie 10y ago
        > DevOps is something that we are still learning and developing as a profession. Not really. DevOps is simply a modernish label for system administration that we have for dozens years already.
        the_other 10y ago
        Isn't that just "Ops"?
        dozzie 10y ago
        My point exactly.
        aurelianito 10y ago
        Yes, but now we actually try to automate in a systematic way; as opposed to a single admin hacking some custom shell scripts. That's what the dev in devop mean. And that's new, at least it was not a common activity in the XX century.
        dozzie 10y ago
        If by "systematic way" you mean a group of programmers clueless about system administration hacking together some custom Ansible scripts, then I wouldn't call it progress. Sysadmins have tools to automate their work for a long, long time (cfengine, bcfg2, even Puppet and Chef predates DevOps hype). DevOps didn't bring anything new to the table.
        aurelianito 10y ago
        Is not about doing it right or wrong. Is about the automation that is reused cross-project and the fact that a lot of things that used to require a sysadmin now we automated its job away. If developers implement it correctly or poorly is a different issue. It is also not about hype (or not). I do agree that the name is posterior to the beginning of the practice, but it is the name that we have.
  - zaroth 10y ago
    It seems like so many "best practices" are really thinly veiled attempts at exploding complexity with only tenuous potential business advantages. We create ourselves so many of the problems we are paid to solve.
    - mLuby 10y ago
      "We create ourselves so many of the problems we are paid to solve" Sounds lucrative ;)
      - jessaustin 10y ago
        It works for doctors and lawyers; why shouldn't software developers try it?
    - thomaslee 10y ago
      > It seems like so many "best practices" are really thinly veiled attempts at exploding complexity I'll bite. :D It's a bit more nuanced than that IMO, the "deploy often" mantra is only as good as the process around release + deploy. If you half-ass testing and push to production without without a process for verification -- or if, say, your deploy process is half-baked, or your staging environment is worthless -- you can probably expect "interesting" production deploys on a pretty regular basis. As much as we'd like to pretend we're all good engineers, this happens more often than you'd expect -- even with good engineers: at some point a company transitions from scrappy startup to a shambling beast, and the things that used to work for a scrappy startup (like skimping on testing and dealing with failures in production) are insufficient when you've got more eyes on the product. Further, the engineering culture remains stuck in "scrappy startup" mode long after the shambling has begun. And all that's ignoring the fact that less frequent deploys with more changes have their own set of problems. We actually got to a point with deploys of a certain distributed system such that we were terrified if we had more than a few days worth of changes queued up. So many things that could go wrong! :) > We create ourselves so many of the problems we are paid to solve. This, on the other hand, I completely 100% agree with: if not us, then who? :) EDIT: minor formatting change
  - cortesoft 10y ago
    The breakage rate per new feature is fairly constant; if you release 7 new features once a week or 1 new feature once a day, you will have the same number of issues. The question then is; is it easier to deal with all the issues at once, or a smaller number of issues every day?
    - danek 10y ago
      In addition to that, I would also worry about interactions between issues. I tend to lean towards spreading out the issues over time to make the eventual diagnosis easier. Occasionally we'll have a problem where we cannot deploy to production for several days (normally it's once a day). A massive inventory of ready-to-deploy features builds up. When we do finally deploy, this deluge of features and fixes creates new issues that force a rollback, delaying the deploy even longer...
      - pc86 10y ago
        Sounds like a testing/UAT issue.
      - cortesoft 10y ago
        Absolutely. Confounding issues are the biggest problem, even more so than sheer volume in a small time frame.
  - msoad 10y ago
    You can roll back a small release that broke the world. A
  - AYBABTME 10y ago
    Or the opposite: embrace failure, practice resiliency, work with it instead of against it!
  - awj 10y ago
    Funny, I've taken it as justification for releasing often. If I have a hard time changing one thing without breaking the service, it's nearly impossible to change a hundred things without breaking something. Since it's a given that I will have to change things, I'll try to stick to a scope where I stand a chance of doing so successfully.
- selckin 10y ago
  Do they have the same load/users during the weekend?
  - jweir 10y ago
    No, in the video he states that the weekend is their busiest period.
- DuskStar 10y ago
  Absolute numbers of alerts are probably a lot less useful than alerts/use, or alerts/users. After all, if people use the services PagerDuty covers less often on the weekend then you might see a lower alert volume even if issues are relatively more common.
- ex_amazon_sde 10y ago
  > most production issues are caused by people It's a well known fact, both for systems and networks.
- Yhippa 10y ago
  After working at various enterprises over the years (where deployments are slower in some cases) I've noticed you'd do a Thursday/Friday/weekend deployment, everything "looks good" and you'll still have a bunch of issues Monday morning due to users finally using the system en masse.
  - jsprogrammer 10y ago
    The user experience is pleasant as well. Nothing better than your dependency breaking at 4PM on Friday with no support until Monday.
  - dnautics 10y ago
    Pretty sure the user volume for Uber is higher over the weekends than during the week. Particularly system stressful times are 1:30-2:15am PT on Saturday and Sunday mornings.
    - kasparsklavins 10y ago
      There is less commuting on weeekends.
      - rsanek 10y ago
        In the talk, he specifically mentions that weekends are the busiest.
    - chejazi 10y ago
      While a lot of people go out on Friday and Saturday night, I don't think the total volume surpasses commute volume. The surge in pricing you experience late at night is largely due to the number of drivers on the road, which would be less given the time of day. Edited out consideration: traffic in your area might be a good proxy for Uber volume. Traffic late at night is generally low.
      - dnautics 10y ago
        Your statement is true in San Francisco, but Pacific time zone also encompasses Oakland, south bay, los Angeles, and san Diego, where relatively few people commute using Uber compared to going out using Uber. From personal experience, having driven for Lyft and Uber I'm two cities (Sf, sd) surge in SF does get acutely high in the morning, more broadly in the evening (work departure times are spread out over a wide range of hours), and acute around 2am. In California, bar closures statewide are 2am at the latest, so that accounts for unified departure times in multiple markets.
- anezvigin 10y ago
  Would PagerDuty consider publishing some anonymized aggregate statistics?
- employee8000 10y ago
  90% of outages are caused by configuration changes which is why change management was so hot for enterprise software.
- ChuckMcM 10y ago
  That conclusion is well founded. We correlated issues at Blekko across a lot of different factors, the one that always held was code or configuration changes. Not too surprising in the large but definitely confirmed by the data.
  - hinkley 10y ago
    So I should fire all my developers is what you're saying... Man, I'm gonna save so much money.
    - ryandrake 10y ago
      You laugh, but a lot of time the best thing for a software product is to not make so many damn changes. People tend to over-estimate the value of features and tweaks and under-estimate the risk of things going wrong.
      - hinkley 10y ago
        Oh I know. I've been in a meeting with several bosses where I tell them flat out "don't give me more developers, give me more hardware and tools". They usually look like I have an extra arm growing out of the top of my head.
    - ChuckMcM 10y ago
      That does save a lot of money :-) The trick is managing the rate of change and the risk of disruption. If you manage it to no risk you end up changing too slowly, if you manage it to close to the risk you end up with unexpected downtime and other customer impacting events. Understanding where you are between no risk and certain doom really only comes with experience.
- hinkley 10y ago
  I'm bad at optimism, but maybe the takeaway here is that we're finally at the point where it's not the hardware or systems that are the biggest problem. The automation is actually working well enough that it's not the tall tent pole.
- Aeolun 10y ago
  That doesn't surprise me at all. If you're not changing software, you can't create any additional bugs.
  - pbhjpbhj 10y ago
    Bet I can!;o)
- di4na 10y ago
  Question is : people at each level. Here most of the alerts happens at night... due to batchs... Most of the other alerts are due to network issues, moving servers due to hardware intervention that change the topology of the network, etc etc.
- mathattack 10y ago
  Couldn't this also just as easily be a change in usage patterns?
gjolund 10y ago
"Move fast and break things" is the worst thing to happen to software development that I can remember.
- enraged_camel 10y ago
  I think it's OK to move fast and break things when you're in the initial product development stage, where you need to develop features quickly and try lots of new stuff to see what sticks. Once you have paying customers though, it may be time to slow down and start caring about stability, at least for your main branch.
  - chetanahuja 10y ago
    It's also ok to "move fast and break things" when the most critical thing you're breaking is your annoying high school "friend"s ability to share the latest racist meme with you. There's a reason facebook made this phrase popular.
adekok 10y ago
I suspect that the issue isn't the engineers. It's the changes. A system running just fine will usually continue to run just fine. Until it's changed.
- fail2fail2ban 10y ago
  Or until the power is cycled. That's why it's best to do the crazy monkey or whatever it's called, walk into the production offline datacenter, online for testing (you do have geographically redundant datacenters right?) and pull out a half dozen random NIC cables. You can simulate with software tools but nothing beats the real test.
  - softawre 10y ago
    > crazy monkey Literally lol'd. It's "chaos monkey".
    - jsprogrammer 10y ago
      Chaos monkey is a simulation, I believe.
      - bch 10y ago
        It's not a simulation, it's real-world production technology. https://en.wikipedia.org/wiki/Technical_details_of_Netflix https://en.wikipedia.org/wiki/Technical_details_of_Netflix
        rrdharan 10y ago
        And it's OSS: https://github.com/Netflix/SimianArmy/wiki/Chaos-Monkey https://github.com/Netflix/SimianArmy/wiki/Chaos-Monkey
        s_kilk 10y ago
        I think they meant that Netflix Chaos Monkey is a "simulation" of the real-deal, which is sending a shaved-ape into a physical server room and pulling out physical network cables. I didn't read it as derogatory.
mshenfield 10y ago
Facebook noticed the same thing. http://www.darkcoding.net/software/facebooks-code-quality-problem http://www.darkcoding.net/software/facebooks-code-quality-pr... - "Exhibit C: Our site works when the engineers go on holiday"
- jackweirdy 10y ago
  Hospital mortality rates in each department are also lowest when there's a conference for that specialty nearby. The doctors all go there, few/no routine surgeries are done that day, far fewer people die.
  - dsacco 10y ago
    This is interesting. Do you have a source for this?
    - jackweirdy 10y ago
      I believe I read it here, though there are several similar studies and this might not be the one I originally read. https://www.ncbi.nlm.nih.gov/pubmed/25531231 https://www.ncbi.nlm.nih.gov/pubmed/25531231
  - huac 10y ago
    That study gave no causal reasons. In particular, there was no effect on number of surgeries done. It's just as possible that research-oriented doctors go to the conference, and those doctors are worse at performing surgeries.
  - SilasX 10y ago
    Isn't that because a surgery, if it fails, will result in the patient dying immediately, rather than some random time later? If you do more surgeries, you will increase both the failed and the successful surgeries, whether your success rate is 10 or 90 percent. Compare: "bomb explosions tend to increase around the time when we send in the bomb squad. I guess bomb defusing is pointless." IOW: Surgeries and bomb defusing tend to move forward a lot of the death-probability-mass (while, in theory, destroying some of it).
samstokes 10y ago
"A ship in harbor is safe — but that is not what ships are built for."
- crpatino 10y ago
  Are you implying that software purpose is to provide developers with puzzles to tinker with... in detriment of their paying customers?
  - samstokes 10y ago
    I see how one could interpret it that way. I meant to imply rather that software generally needs to be regularly changed in order to continue providing value to its paying customers. At minimum, you've got keeping up with security patches, library/framework deprecations etc. Software which has literally not been changed in years is often an insecure timebomb, with unpatched vulnerabilities, and as soon as you do need to change it, you're stuck because all its dependencies are deprecated. Besides, you also need to keep up with the market, competitors, customers' usage patterns changing, etc.
    - hueving 10y ago
      It's a bad analogy because they don't upgrade ships while they are in use. People aren't saying software is most stable when it's not used, they are saying it's most stable when people stop changing it.
    - crpatino 10y ago
      Ok, that's a reasonable position, though not one I completely agree with. It would be nice if we as customers had the freedom to pick up which upgrades to install, and to limit ourselves to security patches and (maybe, some) library deprecations. Windows upgrades let you do just that, even if it is a pain to manage. In my previous job, we held monthly meetings to discuss which windows patches to install in our dozens of business critical Win2k3 servers. For most software, upgrades are opaque. In the best case, you are given a binary choice: install now or install later. In many cases you dont even get that, either the product stops working until you apply the patch or the patch gets automatically applied without your explicit consent. Which would itself not be a problem if most upgrades did what they are ment to do. Instead, as the GP suggest, patches introduce new (sometimes critical) bugs all the time. With pure repair patches, the balance is mostly positive siince they fix more bug than they break, but with every new feature (which usually is required by a minority of very vocal customers) comes a risk that some other more important feature is going to stop working as expected. Industry wide, we lack the discipline to change things in a responsible way. Change management is today what source version control was back in the 90s: something that most people has heard good things about, but most people is not doing correctly, and a significan minority not at all.
kaspm 10y ago
Does anyone who has worked in software for any period of time not realize this? Computers are dumb they (generally) repeat the same tasks reliably _compared to humans_. Occasionally there are system failures but most failure are caused by code or configuration changes, especially when they interact with inputs and systems in untested ways.

We see this pattern at PagerDuty over the majority of our customers. There is a definite lull in alert volume over the weekends that picks up first thing Monday morning. It's led to my personal conclusion that most production issues are caused by people, not errant hardware or systems.

asimuvPR 10y ago
I've come to question releasing often as a result.
- jon-wood 10y ago
  I can see the argument that if releasing causes things to break then don't release so frequently, but in practice the end result of that is lots of things breaking at once and having to unpick everything. Debugging is much easier if you're debugging a single change fresh in your mind.
  - bryanlarsen 10y ago
    Yeah, debugging 2 bugs that are shadowing each other often takes several orders of magnitude longer to debug than just a single issue.
  - Thrillington 10y ago
    While having tooling for tight debugging loops allows short release cycles, it leaves that decision up to the business
  - asimuvPR 10y ago
    You are right. Making small changes that can be isolated for debugging purposes is a good approach. What I mean is that we should always question "best" practices and how we apply them to our development process. These days there is a tendency to drink the kool-aid (guilty of this as well). DevOps is something that we are still learning and developing as a profession.
    - dozzie 10y ago
      > DevOps is something that we are still learning and developing as a profession. Not really. DevOps is simply a modernish label for system administration that we have for dozens years already.
      - the_other 10y ago
        Isn't that just "Ops"?
        dozzie 10y ago
        My point exactly.
        aurelianito 10y ago
        Yes, but now we actually try to automate in a systematic way; as opposed to a single admin hacking some custom shell scripts. That's what the dev in devop mean. And that's new, at least it was not a common activity in the XX century.
        dozzie 10y ago
        If by "systematic way" you mean a group of programmers clueless about system administration hacking together some custom Ansible scripts, then I wouldn't call it progress. Sysadmins have tools to automate their work for a long, long time (cfengine, bcfg2, even Puppet and Chef predates DevOps hype). DevOps didn't bring anything new to the table.
        aurelianito 10y ago
        Is not about doing it right or wrong. Is about the automation that is reused cross-project and the fact that a lot of things that used to require a sysadmin now we automated its job away. If developers implement it correctly or poorly is a different issue. It is also not about hype (or not). I do agree that the name is posterior to the beginning of the practice, but it is the name that we have.
- zaroth 10y ago
  It seems like so many "best practices" are really thinly veiled attempts at exploding complexity with only tenuous potential business advantages. We create ourselves so many of the problems we are paid to solve.
  - mLuby 10y ago
    "We create ourselves so many of the problems we are paid to solve" Sounds lucrative ;)
    - jessaustin 10y ago
      It works for doctors and lawyers; why shouldn't software developers try it?
  - thomaslee 10y ago
    > It seems like so many "best practices" are really thinly veiled attempts at exploding complexity I'll bite. :D It's a bit more nuanced than that IMO, the "deploy often" mantra is only as good as the process around release + deploy. If you half-ass testing and push to production without without a process for verification -- or if, say, your deploy process is half-baked, or your staging environment is worthless -- you can probably expect "interesting" production deploys on a pretty regular basis. As much as we'd like to pretend we're all good engineers, this happens more often than you'd expect -- even with good engineers: at some point a company transitions from scrappy startup to a shambling beast, and the things that used to work for a scrappy startup (like skimping on testing and dealing with failures in production) are insufficient when you've got more eyes on the product. Further, the engineering culture remains stuck in "scrappy startup" mode long after the shambling has begun. And all that's ignoring the fact that less frequent deploys with more changes have their own set of problems. We actually got to a point with deploys of a certain distributed system such that we were terrified if we had more than a few days worth of changes queued up. So many things that could go wrong! :) > We create ourselves so many of the problems we are paid to solve. This, on the other hand, I completely 100% agree with: if not us, then who? :) EDIT: minor formatting change
- cortesoft 10y ago
  The breakage rate per new feature is fairly constant; if you release 7 new features once a week or 1 new feature once a day, you will have the same number of issues. The question then is; is it easier to deal with all the issues at once, or a smaller number of issues every day?
  - danek 10y ago
    In addition to that, I would also worry about interactions between issues. I tend to lean towards spreading out the issues over time to make the eventual diagnosis easier. Occasionally we'll have a problem where we cannot deploy to production for several days (normally it's once a day). A massive inventory of ready-to-deploy features builds up. When we do finally deploy, this deluge of features and fixes creates new issues that force a rollback, delaying the deploy even longer...
    - pc86 10y ago
      Sounds like a testing/UAT issue.
    - cortesoft 10y ago
      Absolutely. Confounding issues are the biggest problem, even more so than sheer volume in a small time frame.
- msoad 10y ago
  You can roll back a small release that broke the world. A
- AYBABTME 10y ago
  Or the opposite: embrace failure, practice resiliency, work with it instead of against it!
- awj 10y ago
  Funny, I've taken it as justification for releasing often. If I have a hard time changing one thing without breaking the service, it's nearly impossible to change a hundred things without breaking something. Since it's a given that I will have to change things, I'll try to stick to a scope where I stand a chance of doing so successfully.
selckin 10y ago
Do they have the same load/users during the weekend?
- jweir 10y ago
  No, in the video he states that the weekend is their busiest period.
DuskStar 10y ago
Absolute numbers of alerts are probably a lot less useful than alerts/use, or alerts/users. After all, if people use the services PagerDuty covers less often on the weekend then you might see a lower alert volume even if issues are relatively more common.
ex_amazon_sde 10y ago
> most production issues are caused by people It's a well known fact, both for systems and networks.
Yhippa 10y ago
After working at various enterprises over the years (where deployments are slower in some cases) I've noticed you'd do a Thursday/Friday/weekend deployment, everything "looks good" and you'll still have a bunch of issues Monday morning due to users finally using the system en masse.
- jsprogrammer 10y ago
  The user experience is pleasant as well. Nothing better than your dependency breaking at 4PM on Friday with no support until Monday.
- dnautics 10y ago
  Pretty sure the user volume for Uber is higher over the weekends than during the week. Particularly system stressful times are 1:30-2:15am PT on Saturday and Sunday mornings.
  - kasparsklavins 10y ago
    There is less commuting on weeekends.
    - rsanek 10y ago
      In the talk, he specifically mentions that weekends are the busiest.
  - chejazi 10y ago
    While a lot of people go out on Friday and Saturday night, I don't think the total volume surpasses commute volume. The surge in pricing you experience late at night is largely due to the number of drivers on the road, which would be less given the time of day. Edited out consideration: traffic in your area might be a good proxy for Uber volume. Traffic late at night is generally low.
    - dnautics 10y ago
      Your statement is true in San Francisco, but Pacific time zone also encompasses Oakland, south bay, los Angeles, and san Diego, where relatively few people commute using Uber compared to going out using Uber. From personal experience, having driven for Lyft and Uber I'm two cities (Sf, sd) surge in SF does get acutely high in the morning, more broadly in the evening (work departure times are spread out over a wide range of hours), and acute around 2am. In California, bar closures statewide are 2am at the latest, so that accounts for unified departure times in multiple markets.
anezvigin 10y ago
Would PagerDuty consider publishing some anonymized aggregate statistics?
employee8000 10y ago
90% of outages are caused by configuration changes which is why change management was so hot for enterprise software.
ChuckMcM 10y ago
That conclusion is well founded. We correlated issues at Blekko across a lot of different factors, the one that always held was code or configuration changes. Not too surprising in the large but definitely confirmed by the data.
- hinkley 10y ago
  So I should fire all my developers is what you're saying... Man, I'm gonna save so much money.
  - ryandrake 10y ago
    You laugh, but a lot of time the best thing for a software product is to not make so many damn changes. People tend to over-estimate the value of features and tweaks and under-estimate the risk of things going wrong.
    - hinkley 10y ago
      Oh I know. I've been in a meeting with several bosses where I tell them flat out "don't give me more developers, give me more hardware and tools". They usually look like I have an extra arm growing out of the top of my head.
  - ChuckMcM 10y ago
    That does save a lot of money :-) The trick is managing the rate of change and the risk of disruption. If you manage it to no risk you end up changing too slowly, if you manage it to close to the risk you end up with unexpected downtime and other customer impacting events. Understanding where you are between no risk and certain doom really only comes with experience.
hinkley 10y ago
I'm bad at optimism, but maybe the takeaway here is that we're finally at the point where it's not the hardware or systems that are the biggest problem. The automation is actually working well enough that it's not the tall tent pole.
Aeolun 10y ago
That doesn't surprise me at all. If you're not changing software, you can't create any additional bugs.
- pbhjpbhj 10y ago
  Bet I can!;o)
di4na 10y ago
Question is : people at each level. Here most of the alerts happens at night... due to batchs... Most of the other alerts are due to network issues, moving servers due to hardware intervention that change the topology of the network, etc etc.
mathattack 10y ago
Couldn't this also just as easily be a change in usage patterns?

gjolund 10y ago

"Move fast and break things" is the worst thing to happen to software development that I can remember.

enraged_camel 10y ago
I think it's OK to move fast and break things when you're in the initial product development stage, where you need to develop features quickly and try lots of new stuff to see what sticks. Once you have paying customers though, it may be time to slow down and start caring about stability, at least for your main branch.
- chetanahuja 10y ago
  It's also ok to "move fast and break things" when the most critical thing you're breaking is your annoying high school "friend"s ability to share the latest racist meme with you. There's a reason facebook made this phrase popular.

adekok 10y ago

I suspect that the issue isn't the engineers. It's the changes. A system running just fine will usually continue to run just fine. Until it's changed.

fail2fail2ban 10y ago
Or until the power is cycled. That's why it's best to do the crazy monkey or whatever it's called, walk into the production offline datacenter, online for testing (you do have geographically redundant datacenters right?) and pull out a half dozen random NIC cables. You can simulate with software tools but nothing beats the real test.
- softawre 10y ago
  > crazy monkey Literally lol'd. It's "chaos monkey".
  - jsprogrammer 10y ago
    Chaos monkey is a simulation, I believe.
    - bch 10y ago
      It's not a simulation, it's real-world production technology. https://en.wikipedia.org/wiki/Technical_details_of_Netflix https://en.wikipedia.org/wiki/Technical_details_of_Netflix
      - rrdharan 10y ago
        And it's OSS: https://github.com/Netflix/SimianArmy/wiki/Chaos-Monkey https://github.com/Netflix/SimianArmy/wiki/Chaos-Monkey
      - s_kilk 10y ago
        I think they meant that Netflix Chaos Monkey is a "simulation" of the real-deal, which is sending a shaved-ape into a physical server room and pulling out physical network cables. I didn't read it as derogatory.

mshenfield 10y ago

Facebook noticed the same thing. http://www.darkcoding.net/software/facebooks-code-quality-problem http://www.darkcoding.net/software/facebooks-code-quality-pr... - "Exhibit C: Our site works when the engineers go on holiday"

jackweirdy 10y ago
Hospital mortality rates in each department are also lowest when there's a conference for that specialty nearby. The doctors all go there, few/no routine surgeries are done that day, far fewer people die.
- dsacco 10y ago
  This is interesting. Do you have a source for this?
  - jackweirdy 10y ago
    I believe I read it here, though there are several similar studies and this might not be the one I originally read. https://www.ncbi.nlm.nih.gov/pubmed/25531231 https://www.ncbi.nlm.nih.gov/pubmed/25531231
- huac 10y ago
  That study gave no causal reasons. In particular, there was no effect on number of surgeries done. It's just as possible that research-oriented doctors go to the conference, and those doctors are worse at performing surgeries.
- SilasX 10y ago
  Isn't that because a surgery, if it fails, will result in the patient dying immediately, rather than some random time later? If you do more surgeries, you will increase both the failed and the successful surgeries, whether your success rate is 10 or 90 percent. Compare: "bomb explosions tend to increase around the time when we send in the bomb squad. I guess bomb defusing is pointless." IOW: Surgeries and bomb defusing tend to move forward a lot of the death-probability-mass (while, in theory, destroying some of it).

samstokes 10y ago

"A ship in harbor is safe — but that is not what ships are built for."

crpatino 10y ago
Are you implying that software purpose is to provide developers with puzzles to tinker with... in detriment of their paying customers?
- samstokes 10y ago
  I see how one could interpret it that way. I meant to imply rather that software generally needs to be regularly changed in order to continue providing value to its paying customers. At minimum, you've got keeping up with security patches, library/framework deprecations etc. Software which has literally not been changed in years is often an insecure timebomb, with unpatched vulnerabilities, and as soon as you do need to change it, you're stuck because all its dependencies are deprecated. Besides, you also need to keep up with the market, competitors, customers' usage patterns changing, etc.
  - hueving 10y ago
    It's a bad analogy because they don't upgrade ships while they are in use. People aren't saying software is most stable when it's not used, they are saying it's most stable when people stop changing it.
  - crpatino 10y ago
    Ok, that's a reasonable position, though not one I completely agree with. It would be nice if we as customers had the freedom to pick up which upgrades to install, and to limit ourselves to security patches and (maybe, some) library deprecations. Windows upgrades let you do just that, even if it is a pain to manage. In my previous job, we held monthly meetings to discuss which windows patches to install in our dozens of business critical Win2k3 servers. For most software, upgrades are opaque. In the best case, you are given a binary choice: install now or install later. In many cases you dont even get that, either the product stops working until you apply the patch or the patch gets automatically applied without your explicit consent. Which would itself not be a problem if most upgrades did what they are ment to do. Instead, as the GP suggest, patches introduce new (sometimes critical) bugs all the time. With pure repair patches, the balance is mostly positive siince they fix more bug than they break, but with every new feature (which usually is required by a minority of very vocal customers) comes a risk that some other more important feature is going to stop working as expected. Industry wide, we lack the discipline to change things in a responsible way. Change management is today what source version control was back in the 90s: something that most people has heard good things about, but most people is not doing correctly, and a significan minority not at all.

kaspm 10y ago

Does anyone who has worked in software for any period of time not realize this? Computers are dumb they (generally) repeat the same tasks reliably _compared to humans_. Occasionally there are system failures but most failure are caused by code or configuration changes, especially when they interact with inputs and systems in untested ways.