9 ms·

I don't know how long that failure mode has been in place or if this is relevant, but it makes me think of analogous times I've encountered similar: When autom

I don't know how long that failure mode has been in place or if this is relevant, but it makes me think of analogous times I've encountered similar: When automated systems are first put in place, for something high risk, "just shut down if you see something that may be an error" is a totally reasonable plan. After all, literally yesterday they were all functioning without the automated system, if it doesn't seem to be working right better switch back to the manual process we were all using yesterday, instead of risk a catastrophe. In that situation, switching back to yesterday's workflow is something that won't interrupt much. A couple decades -- or honestly even just a couple years -- later, that same fault system, left in place without much consideration because it rarely is triggered -- is itself catastrophic, switching back to a rarely used and much more inefficient manual process is extremely disruptive, and even itself raises the risk of catastrophic mistakes. The general engineering challenge, is how we deal with little-used little-seen functionality (definitely thinking of fault-handling, but there may be other cases) that is totally reasonable when put in place, but has not aged well, and nobody has noticed or realized it, and even if they did it might be hard to convince anyone it's a priority to improve, and the longer you wait the more expensive.

telgareith 2y ago
Dig into the OpenZFS 2.2.0 data loss bug story. There was at least one ticket (in FreeBSD) where it cropped up almost a year prior and got labeled "look into layer," but it got closed. I'm aware closing tickets of "future investigation" tasks when it seems to not be an issue any longer is common. But, it shouldnt be.
- Arainach 2y ago
  >it shouldnt be Software can (maybe) be perfect, or it can be relevant to a large user base. It cannot be both. With an enormous budget and a strictly controlled scope (spacecraft) it may be possible to achieve defect-free software. In most cases it is not. There are always finite resources, and almost always more ideas than it takes time to implement. If you are trying to make money, is it worth chasing down issues that affect a miniscule fraction of users that take eng time which could be spent on architectural improvements, features, or bugs affecting more people? If you are an open source or passion project, is it worth your contributors' limited hours, and will trying to insist people chase down everything drive your contributors away? The reality in any sufficiently large project is that the bug database will only grow over time. If you leave open every old request and report at P3, users will grow just as disillusioned as if you were honest and closed them as "won't fix". Having thousands of open issues that will never be worked on pollutes the database and makes it harder to keep track of the issues which DO matter.
  - Shorel 2y ago
    I'm in total disagreement with your last paragraph. In fact, I can't see how it follows from the rest. Software can have defects, true. There are finite resources, true. So keep the tickets open. Eventually someone will fix them. Closing something for spurious psychological reasons seems detrimental to actual engineering and it doesn't actually avoid any real problem. Let me repeat that: ignoring a problem doesn't make it disappear. Keep the tickets open. Anything else is supporting a lie.
    - Arainach 2y ago
      It's not "spurious psychological reasons". It is being honest that issues will never, ever meet the bar to be fixed. Pretending otherwise by leaving them open and ranking them in the backlog is a waste of time and attention.
      - exe34 2y ago
        it's more fun/creative/CV-worthy to write new shiny features than to fix old problems.
        astrange 2y ago
        I think a more subtle issue is that fixing old bugs can cause new bugs. It's easier to fix something new, for instance because you understand it better. At some point it can be safest to just not touch something old. Also, old bugs can get fixed by accident / the environment changing / the whole subsystem getting replaced, and if most of your long tail of bugs is already fixed then it wastes people's time triaging it.
        wolrah 2y ago
        > I think a more subtle issue is that fixing old bugs can cause new bugs. Maybe it's years of reading The Old New Thing and similar, maybe it's a career spent supporting "enterprise" software, but my personal experience is that fixing old bugs causing new bugs happens occasionally, but far more often it's that fixing old bugs often reveals many more old bugs that always existed but were never previously triggered because the software was "bug compatible" with the host OS, assumptions were made that because old versions never went outside of a certain range no newer versions ever would, and/or software just straight up tinkered with internal structures it never should have been touching which were legitimately changed. Over my career I have chased down dozens of compatibility issues between software packages my clients used and new versions of their respective operating systems. Literally 100% of those, in the end, were the software vendor doing something that was not only wrong for the new OS but was well documented as wrong for multiple previous releases. A lot of blatant wrongness was unfortunately tolerated for far too long by far too many operating systems, browsers, and other software platforms. Windows Vista came out in 2006 and every single thing that triggered a UAC prompt was a thing that normal user-level applications were NEVER supposed to be doing on a NT system and for the most part shouldn't have been doing on a 9x system either. As recently as 2022 I have had a software vendor (I forget the name but it was a trucking load board app) tell me that I needed to disable UAC during installs and upgrades for their software to work properly. In reality, I just needed to mount the appropriate network drive from an admin command prompt so the admin session saw it the same way as the user session. I had been telling the vendor the actual solution for years, but they refused to acknowledge it and fix their installer. That client got bought out so I haven't seen how it works in 2024 but I'd be shocked if anything had changed. I have multiple other clients using a popular dental software package where the vendor (famous for suing security researchers) still insists that everyone needs local admin to run it properly. Obviously I'm not an idiot and they have NEVER had local admin in decades of me supporting this package but the vendor's support still gets annoyed about it half the time we report problems. As you might guess, I am not particularly favorable on Postel's Law w/r/t anything "big picture". I don't necessarily want XHTML style "a single missing close tag means the entire document is invalid" but I also don't want bad data or bad software to persist without everyone being aware of its badness. There is a middle ground where warnings are issued that make it clear that something is wrong and who's at fault without preventing the rest of the system from working. Call out the broken software aggressively. tl;dr: If software B depends on a bug or unenforced boundary in software A, and software A fixing that bug or enforcing that boundary causes software B to stop working, that is 100% software B's problem and software A should in no way ever be expected to care about it. Place the blame where it belongs, software B was broken from the beginning we just hadn't been able to notice it yet.
ronsor 2y ago
> The general engineering challenge, is how we deal with little-used little-seen functionality (definitely thinking of fault-handling, but there may be other cases) that is totally reasonable when put in place, but has not aged well, and nobody has noticed or realized it, and even if they did it might be hard to convince anyone it's a priority to improve, and the longer you wait the more expensive. The solution to this is to trigger all functionality periodically and randomly to ensure it remains tested. If you don't test your backups, you don't have any.
- ericjmorey 2y ago
  Which company deployed a chaos monkey deamon on their systems? Seemed to improve resiliency when I read about it.
  - theolivenbaum 2y ago
    Netflix did that many years ago, interesting idea even if a bit disruptive in the beginning https://netflix.github.io/chaosmonkey/ https://netflix.github.io/chaosmonkey/
    - e28eta 2y ago
      See also, the rest of the simian army: https://netflixtechblog.com/the-netflix-simian-army-16e57fbab116 https://netflixtechblog.com/the-netflix-simian-army-16e57fba...
  - amelius 2y ago
    "Your flight has been delayed due to Chaos Monkey."
    - deleted 2y ago
      [deleted]
    - bigiain 2y ago
      "My name is Susie and I'll be the purser on your flight today, and on behalf of the Captain Chaos Monkey and the First Officer Chaos Monkey... Oh. Shit..."
crtified 2y ago
Also, as codebases and systems get more (not less) complex over time, the potential for technical debt multiplies. There are more processing and outcome vectors, more (and different) branching paths. New logic maps. Every day/month/year/decade is a new operating environment.
- mithametacs 2y ago
  I don’t think it is exponential. In fact, one of the things that surprises me about software engineering is that it’s possible at all. Bugs seem to scale log-linearly with code complexity. If it’s exponential you’re doing it wrong.
sameoldtune 2y ago
> switching back to a rarely used and much more inefficient manual process is extremely disruptive, and even itself raises the risk of catastrophic mistakes. Catastrophe is most likely to strike when you try to fix a small mistake: pushing a hot-fix that takes down the server; burning yourself trying to take overdone cookies from the oven; offending someone you are trying to apologize to.
pj_mukh 2y ago
"When automated systems are first put in place, for something high risk, "just shut down if you see something that may be an error" is a totally reasonable plan" Pretty sure this is exactly what happened with Cruise in San Francisco, cars would just stop and await instructions causing traffic jams. City got mad so they added a "pullover" mechanism. Except now, the "pullover" mechanism ended up dragging someone who had been "flung" into the cars path by someone who had hit and run a pedestrian. The real world will break all your test cases.
wkat4242 2y ago
It's been in place for a while, it happens every few months.
InDubioProRubio 2y ago
Reminds me of the switches we used to put into production machines that could self destroy if -- well defined case else Scream while true do Sleep(forever) Same in switch- default Basically every known unknown its better to halt and let humans drive the fragile machine back into safe parameters- or expand the program. PS: Yes, the else- you know what the else is, its the set of !(-well defined conditions) And its ever changing, if the well-defined if condition changes.
agos 2y ago
Erlang was born out of a similar problem with signal towers: if a terminal sends bogus data or otherwise crashes it should not bring everything down because the subsequent reconnection storm would be catastrophic. so, "let it fail" would be a very reasonable approach to this challenge, at least for fault handling
akavel 2y ago
Take a look at the book: "Systemantics. How systems work and especially how they fail" - a classic, has more observations like this.

telgareith 2y ago

Dig into the OpenZFS 2.2.0 data loss bug story. There was at least one ticket (in FreeBSD) where it cropped up almost a year prior and got labeled "look into layer," but it got closed. I'm aware closing tickets of "future investigation" tasks when it seems to not be an issue any longer is common. But, it shouldnt be.

Arainach 2y ago
>it shouldnt be Software can (maybe) be perfect, or it can be relevant to a large user base. It cannot be both. With an enormous budget and a strictly controlled scope (spacecraft) it may be possible to achieve defect-free software. In most cases it is not. There are always finite resources, and almost always more ideas than it takes time to implement. If you are trying to make money, is it worth chasing down issues that affect a miniscule fraction of users that take eng time which could be spent on architectural improvements, features, or bugs affecting more people? If you are an open source or passion project, is it worth your contributors' limited hours, and will trying to insist people chase down everything drive your contributors away? The reality in any sufficiently large project is that the bug database will only grow over time. If you leave open every old request and report at P3, users will grow just as disillusioned as if you were honest and closed them as "won't fix". Having thousands of open issues that will never be worked on pollutes the database and makes it harder to keep track of the issues which DO matter.
- Shorel 2y ago
  I'm in total disagreement with your last paragraph. In fact, I can't see how it follows from the rest. Software can have defects, true. There are finite resources, true. So keep the tickets open. Eventually someone will fix them. Closing something for spurious psychological reasons seems detrimental to actual engineering and it doesn't actually avoid any real problem. Let me repeat that: ignoring a problem doesn't make it disappear. Keep the tickets open. Anything else is supporting a lie.
  - Arainach 2y ago
    It's not "spurious psychological reasons". It is being honest that issues will never, ever meet the bar to be fixed. Pretending otherwise by leaving them open and ranking them in the backlog is a waste of time and attention.
    - exe34 2y ago
      it's more fun/creative/CV-worthy to write new shiny features than to fix old problems.
      - astrange 2y ago
        I think a more subtle issue is that fixing old bugs can cause new bugs. It's easier to fix something new, for instance because you understand it better. At some point it can be safest to just not touch something old. Also, old bugs can get fixed by accident / the environment changing / the whole subsystem getting replaced, and if most of your long tail of bugs is already fixed then it wastes people's time triaging it.
        wolrah 2y ago
        > I think a more subtle issue is that fixing old bugs can cause new bugs. Maybe it's years of reading The Old New Thing and similar, maybe it's a career spent supporting "enterprise" software, but my personal experience is that fixing old bugs causing new bugs happens occasionally, but far more often it's that fixing old bugs often reveals many more old bugs that always existed but were never previously triggered because the software was "bug compatible" with the host OS, assumptions were made that because old versions never went outside of a certain range no newer versions ever would, and/or software just straight up tinkered with internal structures it never should have been touching which were legitimately changed. Over my career I have chased down dozens of compatibility issues between software packages my clients used and new versions of their respective operating systems. Literally 100% of those, in the end, were the software vendor doing something that was not only wrong for the new OS but was well documented as wrong for multiple previous releases. A lot of blatant wrongness was unfortunately tolerated for far too long by far too many operating systems, browsers, and other software platforms. Windows Vista came out in 2006 and every single thing that triggered a UAC prompt was a thing that normal user-level applications were NEVER supposed to be doing on a NT system and for the most part shouldn't have been doing on a 9x system either. As recently as 2022 I have had a software vendor (I forget the name but it was a trucking load board app) tell me that I needed to disable UAC during installs and upgrades for their software to work properly. In reality, I just needed to mount the appropriate network drive from an admin command prompt so the admin session saw it the same way as the user session. I had been telling the vendor the actual solution for years, but they refused to acknowledge it and fix their installer. That client got bought out so I haven't seen how it works in 2024 but I'd be shocked if anything had changed. I have multiple other clients using a popular dental software package where the vendor (famous for suing security researchers) still insists that everyone needs local admin to run it properly. Obviously I'm not an idiot and they have NEVER had local admin in decades of me supporting this package but the vendor's support still gets annoyed about it half the time we report problems. As you might guess, I am not particularly favorable on Postel's Law w/r/t anything "big picture". I don't necessarily want XHTML style "a single missing close tag means the entire document is invalid" but I also don't want bad data or bad software to persist without everyone being aware of its badness. There is a middle ground where warnings are issued that make it clear that something is wrong and who's at fault without preventing the rest of the system from working. Call out the broken software aggressively. tl;dr: If software B depends on a bug or unenforced boundary in software A, and software A fixing that bug or enforcing that boundary causes software B to stop working, that is 100% software B's problem and software A should in no way ever be expected to care about it. Place the blame where it belongs, software B was broken from the beginning we just hadn't been able to notice it yet.

ronsor 2y ago

> The general engineering challenge, is how we deal with little-used little-seen functionality (definitely thinking of fault-handling, but there may be other cases) that is totally reasonable when put in place, but has not aged well, and nobody has noticed or realized it, and even if they did it might be hard to convince anyone it's a priority to improve, and the longer you wait the more expensive. The solution to this is to trigger all functionality periodically and randomly to ensure it remains tested. If you don't test your backups, you don't have any.

ericjmorey 2y ago
Which company deployed a chaos monkey deamon on their systems? Seemed to improve resiliency when I read about it.
- theolivenbaum 2y ago
  Netflix did that many years ago, interesting idea even if a bit disruptive in the beginning https://netflix.github.io/chaosmonkey/ https://netflix.github.io/chaosmonkey/
  - e28eta 2y ago
    See also, the rest of the simian army: https://netflixtechblog.com/the-netflix-simian-army-16e57fbab116 https://netflixtechblog.com/the-netflix-simian-army-16e57fba...
- amelius 2y ago
  "Your flight has been delayed due to Chaos Monkey."
  - deleted 2y ago
    [deleted]
  - bigiain 2y ago
    "My name is Susie and I'll be the purser on your flight today, and on behalf of the Captain Chaos Monkey and the First Officer Chaos Monkey... Oh. Shit..."

crtified 2y ago

Also, as codebases and systems get more (not less) complex over time, the potential for technical debt multiplies. There are more processing and outcome vectors, more (and different) branching paths. New logic maps. Every day/month/year/decade is a new operating environment.

mithametacs 2y ago
I don’t think it is exponential. In fact, one of the things that surprises me about software engineering is that it’s possible at all. Bugs seem to scale log-linearly with code complexity. If it’s exponential you’re doing it wrong.

sameoldtune 2y ago

> switching back to a rarely used and much more inefficient manual process is extremely disruptive, and even itself raises the risk of catastrophic mistakes. Catastrophe is most likely to strike when you try to fix a small mistake: pushing a hot-fix that takes down the server; burning yourself trying to take overdone cookies from the oven; offending someone you are trying to apologize to.

pj_mukh 2y ago

"When automated systems are first put in place, for something high risk, "just shut down if you see something that may be an error" is a totally reasonable plan" Pretty sure this is exactly what happened with Cruise in San Francisco, cars would just stop and await instructions causing traffic jams. City got mad so they added a "pullover" mechanism. Except now, the "pullover" mechanism ended up dragging someone who had been "flung" into the cars path by someone who had hit and run a pedestrian. The real world will break all your test cases.

wkat4242 2y ago

It's been in place for a while, it happens every few months.

InDubioProRubio 2y ago

Reminds me of the switches we used to put into production machines that could self destroy if -- well defined case else Scream while true do Sleep(forever) Same in switch- default Basically every known unknown its better to halt and let humans drive the fragile machine back into safe parameters- or expand the program. PS: Yes, the else- you know what the else is, its the set of !(-well defined conditions) And its ever changing, if the well-defined if condition changes.

agos 2y ago

Erlang was born out of a similar problem with signal towers: if a terminal sends bogus data or otherwise crashes it should not bring everything down because the subsequent reconnection storm would be catastrophic. so, "let it fail" would be a very reasonable approach to this challenge, at least for fault handling

akavel 2y ago

Take a look at the book: "Systemantics. How systems work and especially how they fail" - a classic, has more observations like this.