3 ms·

It's extremely hard to engineer a situation in which no one ever experiences a negative outcome True; nevertheless: good engineering practice dictates that you

It's extremely hard to engineer a situation in which no one ever experiences a negative outcome True; nevertheless: good engineering practice dictates that you design a product, service or component in a way that it gracefully fails. A good example is the regulator for scuba diving (the thing that enables you to breathe and which contains the main valve, through which you breathe and the second stage, referred to as octopus, which is conneted to the bottle and the gauges). Any of those components could fail. The device, however, is designed in a way that if this happens it fails "safely" meaning that it's almost not possible that air flow is completely blocked, but that it flows unrestricted. Meaning you can still breathe, alas for a short time since the bottle empties rapidly and the flow is unrestricted. This gives you a fighting chance and a way out by signalling the distress to your buddy so you can safely mount to the surface using techniques such as buddy breathing. Training for such emergencies is arguably the most important part of scuba diving training. There's still the possibilty that the thing blocks completely, but that's extremely rare and the base design of this equipment part is done in a way to minimize this possibility. [1] Another example is a dead man's switch [2]. You don't anticipate that a train conductor is rendered incommunicado by, say, a heart attack. But this fail safe mechanism is nevertheless there in the extremely rare case when it happens. If the switch is not engaged, when it signals the conductor the train is stopped automatically. I think that when you create something like a dog walking service it's almost rekless not to design your process flows with the consideration that an accident may happen and how to handle it. The question is not if, but when. Wag's panic mode and the waving around of NDAs signals quite loudly that they obviously never thought about it and thus cannot be trusted to care for your animal. And this is actually the most charitable assessment of how they handled this disaster. Chances that one of your consignees is hurt or killed are probably much greater than that your regulator malfunctions or that a train conductor is suddenly dropping dead [1] https://en.wikipedia.org/wiki/Diving_regulator#Malfunctions_and_failure_modes https://en.wikipedia.org/wiki/Diving_regulator#Malfunctions_... [2] https://en.wikipedia.org/wiki/Dead_man%27s_switch https://en.wikipedia.org/wiki/Dead_man%27s_switch

james_s_tayler 8y ago
I love this comment and I think it's right on the money to say that we ought to engineer things in the best possible way we can. I have a couple of thoughts... There is a sort of dialectic that unfolds with regards to what fail-safes should be engineered and how to engineer them. It perhaps might be possible in some cases to compute a priori what fail-safe mechanisms a system needs to include, but for the most part it seems that a catastrophe (or a string of them) first unfolds which then gives you the necessary information as to what the requirements are for the fail-safe. I think this is a very important point worth stressing. As it relates to this incident, I'll grant you they probably could have done better from the outset, but I stand by the comment that sometimes it's not possible to compute ahead of time what fail-safes you need and experiencing these kind of PR disasters is just part of the journey towards a system that works better. Call it dialectical engineering if you will. If there is another, better, actual name that concept goes by I'd like to know if anyone can tell me. The other comment would be that I like to think about things from a control-theoretic and systems thinking point of a view and that this particular statement of "It's extremely hard to engineer a situation in which no one ever experiences a negative outcome" is a real core, axiomatic belief for me that I base a lot of my thinking and critiques of things around. I like what you have to say about engineering. It's very apt. I always couch my thoughts / analyses in the broadest possible context. So in the case of the regulator for scuba diving my mind flashes back to the terrifying stories I have read about people who let their concentration lapse at a critical juncture in a cave and panicked when they realised they couldn't find their way back and in that case it didn't matter that their regulator worked or not because it was their mind that had failed them. You mention training as being a crucial input to the system and I absolutely agree. I go so far as to include the cave itself as a constraint in the whole system design as well as all the pitfalls of the human mind. So it's not just the device but the entire context in which the device operates that's the important thing. Human engineered machines gracefully fail; humans do not. We have this deep need to play the blame game when things go wrong. We all do it and we all understand it, but it's not always justified and I think that matters. I like to try and get to the bottom of whether the moral outrage suffered by people is justified in situations where they were harmed but it wasn't necessarily the fault of someone. Well, it might be the fault of someone, but that also might just be a necessary part of the process a la my concept of dialectical engineering. It's a complicated topic. Of course you will be outraged or upset if your dog dies while in the care of somebody else and you aren't likely to sit and get all philosophical about it, but when you play the blame game you search for the most salient (to you) cause or potential cause of your effect and you attribute it to that. I think it's often stunningly likely you're making an error in judgement when you do this, because of the hard problem of delineation you can't necessarily compute what the actual cause is with any degree of accuracy so epistemology comes in to play. How do you know that what you're mad at is the appropriate thing to be mad at?

james_s_tayler 8y ago

I love this comment and I think it's right on the money to say that we ought to engineer things in the best possible way we can. I have a couple of thoughts... There is a sort of dialectic that unfolds with regards to what fail-safes should be engineered and how to engineer them. It perhaps might be possible in some cases to compute a priori what fail-safe mechanisms a system needs to include, but for the most part it seems that a catastrophe (or a string of them) first unfolds which then gives you the necessary information as to what the requirements are for the fail-safe. I think this is a very important point worth stressing. As it relates to this incident, I'll grant you they probably could have done better from the outset, but I stand by the comment that sometimes it's not possible to compute ahead of time what fail-safes you need and experiencing these kind of PR disasters is just part of the journey towards a system that works better. Call it dialectical engineering if you will. If there is another, better, actual name that concept goes by I'd like to know if anyone can tell me. The other comment would be that I like to think about things from a control-theoretic and systems thinking point of a view and that this particular statement of "It's extremely hard to engineer a situation in which no one ever experiences a negative outcome" is a real core, axiomatic belief for me that I base a lot of my thinking and critiques of things around. I like what you have to say about engineering. It's very apt. I always couch my thoughts / analyses in the broadest possible context. So in the case of the regulator for scuba diving my mind flashes back to the terrifying stories I have read about people who let their concentration lapse at a critical juncture in a cave and panicked when they realised they couldn't find their way back and in that case it didn't matter that their regulator worked or not because it was their mind that had failed them. You mention training as being a crucial input to the system and I absolutely agree. I go so far as to include the cave itself as a constraint in the whole system design as well as all the pitfalls of the human mind. So it's not just the device but the entire context in which the device operates that's the important thing. Human engineered machines gracefully fail; humans do not. We have this deep need to play the blame game when things go wrong. We all do it and we all understand it, but it's not always justified and I think that matters. I like to try and get to the bottom of whether the moral outrage suffered by people is justified in situations where they were harmed but it wasn't necessarily the fault of someone. Well, it might be the fault of someone, but that also might just be a necessary part of the process a la my concept of dialectical engineering. It's a complicated topic. Of course you will be outraged or upset if your dog dies while in the care of somebody else and you aren't likely to sit and get all philosophical about it, but when you play the blame game you search for the most salient (to you) cause or potential cause of your effect and you attribute it to that. I think it's often stunningly likely you're making an error in judgement when you do this, because of the hard problem of delineation you can't necessarily compute what the actual cause is with any degree of accuracy so epistemology comes in to play. How do you know that what you're mad at is the appropriate thing to be mad at?