Hacker News Reader

Thinking about this a little more, I also see a failure here in terms of naming things, which I have noticed in my career can be scoffed at but is so important.

As the article says, the function of MCAS changed and its operational envelope was greatly expanded. What if, internally at least, the new system was referred to as MCAS2?

This is somewhere that things can get political, as was exactly the case with the Max, where they did not want anything to be considered a change to the aircraft type, let alone knowing the MCAS system existed in two majorly differing versions.

Admittedly I have 0 familiarity of the internals of a corporate electrical engineering environment, but this is a logically sound idea that in many other industries is standard. OS 10.02, Apache license v. 2, Archer router xyz Rev 02. What's the limiting factor here in the case of MCAS?

There are definitely different versions of software, each with unique identifiers, such as typical version numbers. There’s also the idea of “flight test ready” software, which is able to go onto a flight, vs software that is only to be used in a lab that is not truly flying in the air and controlling the plane.

Perhaps something entirely different than what you're talking about, but...

I believe changing the aircraft type would trigger regulatory events carrying rather gargantuan costs.

Avoiding those seem to be the entire reason for the existence of the 737 MAX.

Naming things and communicating changes are all core parts of the Systems Engineering process.

Failing to clearly communicate precisely how big this change was, and not making it extremely clear to all stakeholders what was happening and doing analyses of how these failure modes have changed, is really awful.

This is so true. Naming to me is one of the most important decisions. When I see someone who frets over naming decisions for hours, or will sit down with me and really think through what we're going to name something - I know they get the gravity of the situation. I trust those kinds of people much more for big picture architectural or project lead decisions.

Do you have examples off the top of your head of really great names that have come as a result of this process?

As a former Systems Engineer who worked on avionics, I would tend to agree; a major change to a system should have at least triggered the integration-level engineers (called the Platform team at my former job) to think hard about potential broad impacts.

It should have resulted in that team actively seeking buy-in, and clear communication that all subsystems comprehended precisely what was changing.

It likely should have triggered some kind of additional scrutiny from the safety organization.

That it didn’t is heartbreaking. It seems like either some common practices were not followed or were rushed.

I can’t see Boeing keeping their CMMI certification level after this news breaks. Certainly some major steps were skipped in the Systems Engineering process.

>Especially if as the article says a failure of the AOA sensor on the system would be Hazardous (looks like it was Catastrophic

From my understanding, this was an intentional decision, as the only way they could certify the airframe without simulator training being required was to feed the MCAS with only 1 sensor.

The only way they could do that is keeping the system overall rated as hazardous, as the Catastrophic rating would require multiple redundancy plus the training.

This can be corroborated from the Australian 60 minutes expose.

>For sure there may have been pressure from management to keep MCAS out of the manual but it’s not really up to he regulatory agency to be experts on the aircraft design, if things are being hidden by the company then I’d consider this bordering on professional misconduct on the parts of the engineers overseeing this work.

That is my conclusion as well.

Thanks for the tip on the AUS 60 Minutes expose. For anyone else interested: https://youtu.be/aO7_indbfME

engineers overseeing this work

There the thing: nobody wants to pay engineers on par with managers. Maybe one can not manage something he/she can not understand.

Given all the environments I've worked in, including midsize construction projects I'm willing to bet my hand on the fact that some engineers or third party planning bureaus actually did spot these flaws and reported them and then were turned down and ignored, but not before having been told that it's not their decision/problem.

That's always the moment when I'm happy to have documented the decisions.

It’s what happened at NASA...

Just to be clear, are you referring to https://en.wikipedia.org/wiki/Linda_Ham ?

> There the thing: nobody wants to pay engineers on par with managers

I used to think like that but I learned in time that the core issue is that engineers rarely know how to present their job in terms of monetary benefit during salary negotiations.

i.e. as an automation engineer I led an initiative that saved a previous employer more than 60k€ yearly using automation and optimizing other validation workflows. as principal engineer at my current job I saved them more than 30k€ yearly by replacing a licensed component with an open source one, filling the feature gaps myself outside of work hours.

these thing get noticed, not just the stuff done but the ability of thinking in money, and unlocks the full engineering potential in salary negotiations

I assume these must be small examples on a long list of accomplishments, because 30k/year doesn't seem like it's enough to offset your salary. I have to imagine the impact of a principal engineer should be measured in the 10-100x of their salary?

it was just a bunch of examples of stuff that was specifically done on top of my other job resps. also, not every place is the silicon valley and not every company is a fortune 500, plus some perspective about relative worth also applies - i.e. the automation stuff was calculated in time saved by the Indian based testing team, which reduces the raw impact.

That's some pretty impressive ingrained bias towards rent-seekers. Why not 1.1x or the board can try doing the work?

Consider a fast food business. Should the manager be satisfied with making 10% profit on french fries?

10% on raw materials would be losing money, but 10% on total expense, with the difference going to the workforce is fine to me. I don't see why fast foods shouldn't be cooperatives, they're not exactly capital intensive or high risk.

To be clear, I wasn't referring to the board having a choice in the matter.

Sorry I both agree with you but reckon 10x is about the correct ratio. It’s not rent-seeking, it’s “sharing wealth” and “diminishing inequalities”. A good engineer needs to pay for: - Administrative employees, - Office rental, - Junior members of the teams who are growing up towards seniority, - Women who are non productive but required to pass the diversity requirements and make the company look good.

You may claim it’s unfair that productive members are exploited to pay for nonproductive ones, but that’s the neo-conservatives’ argument, and has been rejected by most of the Silicon Valley. I honestly think that the currebt situation is already the middle ground betweeb “pay proportional to your added value” and “diversity, equality and social responsibility requires adjusting the salaries of highest-paid engineers.”

engineers rarely know how to present their job in terms of monetary benefit

The point is, they shouldn't have to. The managers should be handling that fairly. Otherwise, it's an adversarial game where only one team knows how to play.

Engineers should be experts in engineering. Holding them at a disadvantage because they are not good at the other feels wrong.

but even in such a scenario how a manager would know how to assign merit? they aren't expert in engineering either.

someone in between has to connect the dots, but there is no such figure and the incentives for doing that communication work are all on the engineers' side

addendum: I do however agree it sucks to have to compete with other fellows

I would think the manager would have a bigger picture view of the value added, but it probably varies with particular cases.

>>> by replacing a licensed component with an open source one, filling the feature gaps myself outside of work hours.

Your achievement is to save money by doing all the work for free in your spare time?

While I agree that engineers should negotiate better and keep track of their achievements, that is not one at all.

Sometimes an initial sacrifice for future mutually beneficial dividends is warranted, if it’s likely to be reciprocated. Keeping things purely transactional is better if you expect your counterpart to try to take advantage of you, of course, but I don’t think this is the case for all professional relationships, always.

> that is not one at all.

I'm significantly ahead of all my peers in job position and salary so I must have been doing something right.

I've a family now and such investment done prior are helping immensely.

all my peers know I'm dependable and all previous manager know I do get things done.

the large reference network is both a source of work opportunities and has been a safety net during times of need.

why would people choose the misery of strictly contractual relationship when you can build partnerships and friendship wherever you go with just very little effort.

Leaky systemic process abstraction.

I don't know if one could say a failure of the Systems Engineering process. One could also say it is a situation where management, regulatory and market constraints became so unwieldy that there was simply no way Systems Engineering could possibly satisfy the requirements. Sure, it's a failure to push back again this but that seems a bit different.

Management and "the market" were providing faulty feedback that engineering couldn't push back against, no matter how much force was applied.

Systems Engineering -- The art of working on the overall design while not overlooking any detail that later turns out to have been important.