111–120 of 124 posts
Earlier quoted context omitted.
>Your bank, or medical records, or even traffic light controls simply cannot move fast and break Don't tell the banks and financial industry that (looking at you, Equifax).
At least in finance it's more "move slowly and hope no one notices it's broken."
Earlier quoted context omitted.
They had no need to upgrade. If anything they had a massive need to downsize the inventory of weapons. Plus the security protection was shockingly irresponsible. The code was all zeros
The code hasn't been all zeros for 40 to 50 years. It was all zeros on some of the arsenal for about 15 years from ~1962 until ~1977.
Earlier quoted context omitted.
Yes, that would go under "cheaply" in my previous comment.
Sorry, I don’t follow. Are you saying it works well in safety critical software development? Cheaply in the case of adverse outcomes (whether cost, environmental impact, or impact on life) seems at odds with the very definition of software that has a high severity if it fails. I.e., to say safety critical software can be developed “cheaply” seems to ignore the costly consequences of that software failing
Earlier quoted context omitted.
Last October the U.S. Military replaced the eight 1970s floppy disks controlling all nuclear missiles. https://www.forbes.com/sites/zakdoffman/2019/10/19/us-milita...
They had no need to upgrade. If anything they had a massive need to downsize the inventory of weapons. Plus the security protection was shockingly irresponsible. The code was all zeros
Earlier quoted context omitted.
The problems that MBAs are trying to solve are not those at which your average engineer is particularly good. Also, these problems are usually ill defined and not easily testable. On top of that, to "deploy" your solution you need to show a schizophrenic amount of confidence for the amount of ambiguity and risk you plan to take, and you have to do it all in the form of a PowerPoint slide deck for people who are most…
So you're basically saying, MBA's are making decisions based on guesses and feelings, which would then be formalized in PowerPoint slides. I as an engineer like neither of those things. Research the market, create a product per spec, then write documents in markdown. The idea of business are not foreign to us, there are plenty of engineers who start business. And I think the balance is tipping over to the engineers.…
This statement seems to trivialize the skills necessary for good decision making. I would argue good risk based decisions and awareness of cognitive biases (not to mention more “science” based decisions from fields like operations research) probably should be based in formal mentoring/instruction.
Earlier quoted context omitted.
That is so mistaken I’m not sure where to start. I agree there should be accountability, but to say it should be commensurate with compensation is absurd. What happens around here is the engineers are never to blame and it’s always management. Even when it’s specifically an engineering problem it’s the managers’ fault for not preventing the engineers from making a mistake.
> That is so mistaken I’m not sure where to start. Then you disagree with practically every military on the planet. So, you're going to to have to provide at least a little bit of counterexample to support your position. > Even when it’s specifically an engineering problem it’s the managers’ fault for not preventing the engineers from making a mistake. There are VERY few times when engineering results in the failure…
I think one reason the original claim is weird is that leadership should own the blame irrespective of their compensation. (E.g., if a manager has $1 salary they aren’t magically off the hook). It’s one of the core tenets of good leadership.
I think engineers sometimes are quick to jump on management because of 1) a hindsight bias and 2) because engineers often have a myopic view of risk. For example, a software engineer tends to only focus on software risks, while management must balance software risks, hardware risks, customer risks, labor risks, etc.
Earlier quoted context omitted.
And here's another point where we may disagree: money is not a thing to be worshiped at the cost of everything else.
You may disagree, but where are you getting the resources to push your position?
Earlier quoted context omitted.
> That is so mistaken I’m not sure where to start. Then you disagree with practically every military on the planet. So, you're going to to have to provide at least a little bit of counterexample to support your position. > Even when it’s specifically an engineering problem it’s the managers’ fault for not preventing the engineers from making a mistake. There are VERY few times when engineering results in the failure…
I agree that management is generally to blame but also think many (most?) mishaps have engineering related proximate (and potentially root) causes. For example, I think I remember hearing part of the Fukushima disaster is attributed to the engineering decision to place the diesel pump batteries in an area that could flood. The fact that these engineering risks weren’t adequately managed is why people blame management…
You will note that I specifically chose the spraying of water at Fukushima as a management failure (we can argue about the lack of failsafe for the cooling ponds)--because some idiot counting dollars decided to try to "save the core" they caused a hydrogen explosion which made things orders of magnitude worse.
In both Fukushima and Three Mile Island, for example, if everybody had simply SAT ON THEIR HANDS AND DONE NOTHING, the situation would have turned out far better than it eventually did. Yes, the Fukushima core would have still melted down, but it wouldn't have sprayed radioactive material all over the place.
Earlier quoted context omitted.
I agree that management is generally to blame but also think many (most?) mishaps have engineering related proximate (and potentially root) causes. For example, I think I remember hearing part of the Fukushima disaster is attributed to the engineering decision to place the diesel pump batteries in an area that could flood. The fact that these engineering risks weren’t adequately managed is why people blame management…
Well, one thing that research into engineering disasters shows is that these things are almost always chains of things going wrong. Generally because managers do something with no engineering justification --either cutting safety margins, continuing in the face of evidence that is indicating operating outside normalcy, or doing something to "save money" with zero thought to the implications. You will note that I spec…
In my experience, the result of bad decisions is usually due to incomplete information and risk assessments, whether by an engineer or management. Management usually has more risks to balance than the engineer. Engineers are typically only concerned with technical risk while management has both technical and programmatic risks to balance. When the balance tips towards programmatic risks, it may be due to a poor understanding of the technical risks as well as a bad incentive structure. When the technical risks aren't well understood, it's generally not because management is too dumb to grasp it. It's more likely the culture and organizational structure don't foster good communication or accurate assessments of those risks. For example, if you look at the Challenger disaster, neither the engineering staff or management has great estimates about the risk. (However, the engineers were much closer to the true risk probabilities). It came down to a concrete schedule risk vs. a somewhat nebulous technical risk and the absolute risk won out in the management decision process. In your Fukushima example, I'd bet the "idiot" probably didn't have an assessment (in terms of a failure-modes-effects-analysis or hazards analysis) to properly gauge the risk of their action. (Or there were likely communication failures of that risk, or both.)
I think the important point is that to really fix these issues, they have to be addressed as part of a process failure rather than pointing fingers distilling it down to a simplified notion that it's somehow the fault of an "MBA mindset"