820 karma · joined December 27, 2020
Yes, but software skills are fairly fungible. Just because you currently work on ads doesn't mean that's all your skills are good for, or even that you need to work anywhere in ecommerce.
The way I look at it is like so:
I think most people want to bring a net positive value to society. One way of doing that is working on something whose intrinsic value to society is neutral or nebulous (or just not thinking about it too hard), and compensating for that giving the money we make to other organizations that are definitely contributing positively. While this is better than not doing so, I think it misses out on the leverage that exists in what we build vs. the money we're paid for it.
For example, despite making over $500k last year, we know your employer thinks you are producing more value than that, because otherwise they wouldn't pay you that much. You would be a drag on their income statement otherwise. What this means is that even if you donated 100% of your salary to charity, you still aren't taking advantage of the leverage of what you can build, vs. the fixed amount you can earn.
If instead, you choose to work on something which is inherently good for society, society at large benefits from that leverage. You might be paid less, say $200k instead of $500k. But since the positive value you produce is leveraged you could be contributing, let's say, $1M of positive value for society - $200k to pay you to live in the bay area ($800k net positive value).
Just something to think about.
Manufacturers absolutely are liable if there is a design problem. This is the entire reason recalls exist.
One could certainly argue that Tesla's laissez faire attitude toward autopilot safety constitutes a systems engineering design failure, making it grounds for a recall.
The Five Whys is a good start. It gets you thinking past the first cause you see. But it still suggests that there is a single causal chain with a single root issue. Something like STAMP is designed to find any possible contributing factors, whether they are related in a causal chain or only had an indirect impact on the loss.
> Moreover, robustness cannot emerge from a single event no matter how much you analyze it. It comes from continuous improvement processes, quality assurance, war games, service level analysis, etc. It's a multi-headed hydra of efforts to improve a system.
I don’t think I said anything which contradicts this, and I generally agree. The point I was, perhaps unclearly, trying to make is that by including any possible contributing factor in your analysis, you can fix many issues you learned about from a single event. Issues which may have been contributing factors to future, different events. One loss is not enough to fix all the holes, but you want to learn as much as you possibly can from each one when it happens.
To give you a more concrete example, it moves the analysis away from "Bob deleted the production database" into a more productive space of "we really shouldn't have a process that relies on any human logging into the production database and running SQL queries by hand, that's prone to human mistake".
Avoiding "root cause" thinking doesn't mean that there isn't something that can be found and fixed. The intent is to keep your mind open to the fact that these systems and the interaction of their components are phenomenally complex. There are many contributing factors to a loss, not just a single error.
Root cause analysis is harmful because it artificially limits your investigation to a predetermined "single" error or fault. Once the first or most salient error or fault is found (very commonly a human operator), the investigation stops because the "root cause" was found. Instead of stopping at the root cause, you keep digging in attempt to find all the possible contributing factors, no matter how big or small. You can prevent many future failures of the system, not just the same one, by learning about many places where your defenses and mitigations were weak.
NTSB reports are a great example of how useful this approach is. Instead of identifying a root cause, they list many contributing factors, all of which can be improved to raise the level of safety significantly rather the fixing a single root cause.
As a recent example, think of the Boeing 737 MAX. What was the "root cause"? Was it:
* A software bug in the MCAS system? * The removal of a redundant method for sensing angle of attack? * The decision to make the "AoA Disagree" light an optional upgrade? * Making substantially unstable changes to the existing airframe? * The desire for it be be "another 737 variant" for pilot classification? * The insufficient pilot training w.r.t. to the new MCAS system? * Organizational pressures to not lose the AA contract to Airbus? * Executive leadership that prioritized business over safety?
The answer is all of the above, and more! By identifying all of these past "a software bug in the MCAS system" we have the opportunity to fix many safety issues which could be contributing factors to future failures.
There is an even more in depth example of this in Chapter 5 of Nancy Leveson's book Engineering a Safer World. She spends over 60 pages describing the environment and circumstances that lead to a US Air Force F-15 shooting down a friendly US Army Black Hawk over northern Iraq in 1994.