Money saved by firing experienced engs and outsourcing the development << money lost because they can't sell planes.
Why is that so hard to understand? Massive fail at risk management maybe?
Why is that so hard to understand? Massive fail at risk management maybe?
And they were probably regularly reassured by various internal and external entities that the code was high-quality and thoroughly tested and very safe. Obviously they're not going to outsource if they think it's likely to cause a safety hazard; they just didn't place the odds of this outcome anywhere near what the actual odds ended up being.
The end product may be, but not the design problem process nor the manufacturing process.
The world is changing fast enough that old style management won't get investment after some time.
But in the long term the MBA manager has been likely been promoted and is working elsewhere, killing another company, while his or her CV boasts of "reducing inefficiencies".
The main issue was that there was only one AOA sensor connected in standard packages and the hardware for it failed.
The pitot tubes failed for the doomed Air France incident which caused the software to read incorrectly and stall.
For what it's worth AirBus has a huge engineering department in India: https://www.airbus.com/careers/search-and-apply/opportunitie...
Articles like this are just drummed up to stir negative emotions about "others" (with "struggling to understand English" and "unable to code fizzbuzz") as is evidenced in the rest of the comments below.
Firstly, no the software did not do exactly as it's supposed to. It crashed the plane by rendering it unflyable. It's not supposed to do that. And your description of the MCAS specification is vastly over-simplified - it is not an autopilot and its job is to gradually change the behaviour of the plane in different flight modes (which it must detect), not to directly fly the plane as you suggest (and even two AOA sensors would be insufficient for the type of functionality you describe). The behaviour of the MCAS is absolutely in question, in particular the way it kept "re-adding" the correction, with cumulative effect, ending up fully pitched down.
Secondly, if by "the doomed Air France incident" you mean AF447, your description of it is flat-out wrong. The pilot, not software, stalled and crashed the plane by manually holding the stick back for 15 minutes. The pitot tubes briefly iced over (they didn't "fail") which is not an uncommon occurrence, and the only consequence of this was that the software guardrails that would have prevented the pilot from crashing the plane were removed. All instrumentation systems were fully operational at the time of the crash.
This belongs in the true-but-trite category. The decision to depend on a single, unverified AofA input was not a programming error, and neither was the increase in power in the second version. These decisions were made by Boeing, and endorsed by the FAA (to the extent that Boeing informed the FAA of them.)
Boeing management did not add a second sensor to some planes and also pilots were not aware of how to switch off mcas.
If you worked in large scale project you would know that most devs are assigned components to work on and usually have no idea what other components are or how they will interact.
The negativity seems more targeted at the leaders who arranged this than at the developers. Both the examples you cite are from the same comment, and even that comment is more about resentment towards management corruption than about the incompetence of the developers hired as a result of the corruption.
> The software did exactly as it's supposed to do
I gather new issues with the software have come to light since the accidents, as a result of the heightened scrutiny, and they seem likely to keep the planes grounded for longer than Boeing hoped.
It seems like you’re saying that outsourced devs should have as much accountability as home-based devs or the entity Boeing itself. I don’t agree with this. The salary does not reflect that. The work that’s assigned does not reflect that. Anecdotally working with outsourced devs and based from the comments here, no one honestly thinks that.
It seems like you were triggered by the “excuses” part of the post. But what about the rest of it? He made a valid point (which I think you proved) about people using the article to discriminate.
I guess I’m just wondering why you’re making generalizations. I’ve worked with many devs (who weren’t outsourced) who blame everyone else but themselves. I learned to use ‘git blame’ very early on.
You’re right in that the primary focus of the article was not the outsourced devs being Indian. The issue comes from how people respond to such articles, no matter the article’s intention.
I’m not saying that outsourced devs shouldn’t be held accountable for any faults. The point is that there are different degrees of accountability for all parties involved.
The article only chose to focus on one of these groups, which is fine. What’s not fine is HN comments that seem to not realize this.
No matter the salary or experience or contract, outsourced devs/companies shouldn’t be in a position of power to break critical systems on an airplane. (I’m not saying this is what happened with the Max.)
It would be disturbing if the coders on aircraft control systems were modifying the specifications on the fly, and on the basis of misconceptions like that displayed here.
Responsibility for the dangerous capabilities of MCAS lies with Boeing, which chose to fix an aerodynamic problem this way, and the FAA, which endorsed it.
In this case, the lack of redundancy should have been a red-flagged.
This is why domain knowledge is at least as important as coding skills.
I think southwest airlines had multiple sensors
A second AOA sensor is an option.
Which means code was written to account for both configurations.
Many, many things must happen and change to avoid allowing management to make decisions unchecked.
Because this is a case of bargain-bin engineering and tunnel-visioned management ruining a once-reputable company.
Ask Boeing management your question wrt to the hardware failure. Not pile up on software devs
I have to wonder if seeing SV startups go to multi-billion dollar companies on a regular basis, has given CEOs in other industries a case of envy. But more likely, it's just that pathological optimism works, really well, right up until that moment when it doesn't. Taking risks in order to lower costs makes the bottom line better, which seems to call for more of the same, right up until the moment when the risk explodes in your face.
It is not unlike the attitude towards software security, in many industries. People harping about security risks seems like just all cost and no benefit, right up until the point where you have a big problem.
If so, they're learning the wrong lessons. SV unicorns become valuable because of explosive growth, not because they underpay their engineers. Just the opposite; a lot of engineers at SV startups are paid quite handsomely (especially the early ones at successful unicorns). SV startups don't win on cost-cutting.
Olkiluoto (Finland)
> In May 2006, construction delays of about one year were announced, following quality control problems across the construction. In part the delays were due to the lack of oversight of subcontractors inexperienced in nuclear construction.
> At the end of June 2007, it was reported that Säteilyturvakeskus (STUK), the Finnish Radiation and Nuclear Safety Authority, had found a number of safety-related design and manufacturing 'deficiencies'.
> Initial cost estimates were about €3.7 billion, but the project has since seen several severe cost increments and delays, with latest cost estimates (from 2012) of more than €8 billion.
Flamanville (France)
> In April 2008, the French nuclear safety agency (Autorité de sûreté nucléaire, ASN) reported that a quarter of the welds inspected in the secondary containment steel liner are not in accordance with norms, and that cracks have been found in the concrete base.
> In April 2015, Areva informed the French nuclear regulator ASN that anomalies had been detected in the reactor vessel steel, causing "lower than expected mechanical toughness values". Further tests are underway.[64] In July 2015 The Daily Telegraph reported that Areva had been aware of this problem since 2006.[65] In June 2015, multiple faults in cooling system safety valves were discovered by ASN.
Managerial bonus or promotion for saving money this quarter >> money lost more quarters out than I'll be around