<https://danielmiessler.com/blog/keep-the-robots-out-of-the-gym>
very respectfully,
kushal
ku on .NET
Mostly fun. Sometimes code. Maybe even dot NET
Against Must-Haves (Part Two) — Tom Dalling
The typical specifier does not understand the technical details and technical risks involved in building software. That's not their job. And if they did understand, engineers would become easily replaceable and their salaries would fall through the floor. For example, part of the job of marketing and sales people is to understand what the customers want, so they are able to provide great input when deciding what to build. It is not, however, part of their job to know how to build those things, which is why it's not uncommon for them to come up with ideas that are wildly expensive or literally impossible. And that's fine. Not every idea is feasible.
It's also often not specifiers' job to understand delivery risk, although it is highly desirable. Product people often don't have a good sense for whether building any given feature will be easy peasy lemon squeezy, or stressed depressed lemon zest. That's because there are knowns and unknowns that are deeply technical in nature, and only the people actually building the software have a hope of identifying where the landmines are. Product people with deep technical knowledge are incredible assets, but also exceedingly hard to find and probably outside of your price range.
So then who is actually responsible for the delivery of quality, working software? Whose job is it to deal with these deeply technical unknowns and the risks they pose? The most practical choice is engineering. Engineering is in the best position to understand and mitigate delivery risk — less so the individual engineers writing the code, and more so engineering management/leadership. Engineering management is the interface between the specifiers and the builders, and it is their job to ensure that delivery happens smoothly.
This is why I believe that non-technical engineering managers are generally a bad idea — but that's a topic for another time.
<https://www.tomdalling.com/blog/software-processes/against-must-haves-part-two/>
very respectfully,
kushal
It's also often not specifiers' job to understand delivery risk, although it is highly desirable. Product people often don't have a good sense for whether building any given feature will be easy peasy lemon squeezy, or stressed depressed lemon zest. That's because there are knowns and unknowns that are deeply technical in nature, and only the people actually building the software have a hope of identifying where the landmines are. Product people with deep technical knowledge are incredible assets, but also exceedingly hard to find and probably outside of your price range.
So then who is actually responsible for the delivery of quality, working software? Whose job is it to deal with these deeply technical unknowns and the risks they pose? The most practical choice is engineering. Engineering is in the best position to understand and mitigate delivery risk — less so the individual engineers writing the code, and more so engineering management/leadership. Engineering management is the interface between the specifiers and the builders, and it is their job to ensure that delivery happens smoothly.
This is why I believe that non-technical engineering managers are generally a bad idea — but that's a topic for another time.
<https://www.tomdalling.com/blog/software-processes/against-must-haves-part-two/>
very respectfully,
kushal
Whose fault is it anyway?
Could you say more about how these accidents were due to software issues stemming from outsourcing of development? Could you say more about how not outsourcing COULD have prevented the (2) accidents?
This is not what I understood to have happened.
The software developers writing the code 100% did not come up with or spec out how the MCAS should work. They're not aeronautical engineers, and they absolutely were not in the "system engineering" decision making change of the control system and how it should interface. They didn't decide to rely on one angle of attack sensor.
I know people like to shit on Boeing for outsourcing, but for FFS what do you think non-outsourced software developers were going to do? Fix the spec? Design it "right?" It WAS designed right to spec. The SPEC was bad.
"NO Billy, this is a bad control scheme. This is going to get people killed when the system forces action with 1oo1 voting on a key critical instrument. Especially when the methods and need to override such behavior is obfuscated from the pilot."
Non outsourced developers would have implemented it exactly as outsourced developers did because this is what they were TOLD to do. They didn't get to make ANY of those decisions. It would have still killed people.
Interestingly, my understanding is that Boeing maintains NONE of the production MCAS software was "outsourced" or written by "offshored" devs and was "effed up" in the good old US of A.
The software worked EXACTLY as intended. The system design was bad. The software developers did not do an iota of this system design.
<https://old.reddit.com/r/cscareerquestions/comments/1iuv5df/company_moving_to_only_prompting_no_coding/me2kt9m/>
very respectfully,
kushal
This is not what I understood to have happened.
The software developers writing the code 100% did not come up with or spec out how the MCAS should work. They're not aeronautical engineers, and they absolutely were not in the "system engineering" decision making change of the control system and how it should interface. They didn't decide to rely on one angle of attack sensor.
I know people like to shit on Boeing for outsourcing, but for FFS what do you think non-outsourced software developers were going to do? Fix the spec? Design it "right?" It WAS designed right to spec. The SPEC was bad.
"NO Billy, this is a bad control scheme. This is going to get people killed when the system forces action with 1oo1 voting on a key critical instrument. Especially when the methods and need to override such behavior is obfuscated from the pilot."
Non outsourced developers would have implemented it exactly as outsourced developers did because this is what they were TOLD to do. They didn't get to make ANY of those decisions. It would have still killed people.
Interestingly, my understanding is that Boeing maintains NONE of the production MCAS software was "outsourced" or written by "offshored" devs and was "effed up" in the good old US of A.
The software worked EXACTLY as intended. The system design was bad. The software developers did not do an iota of this system design.
<https://old.reddit.com/r/cscareerquestions/comments/1iuv5df/company_moving_to_only_prompting_no_coding/me2kt9m/>
very respectfully,
kushal
Subscribe to:
Comments (Atom)