This is really a crucial point. I am a software developer in an engineering company. What is essential for my job is not only my programming skills, but also a decent understanding of the engineering I deal with. This can only be achieved by working long enough in the job, be it an engineer who picks up programming or a software developer who learns the engineering involved.
This is of course much more expensive than picking up any contractor, who might be brilliant at programming, but lacks the domain knowledge that only grows over time, but it is a good way of having more eyes spotting potential spec issues.
I really fail to understand the logic that may make someone to think a software engineer, however brilliant, can write software for a domain they don’t understand.
I wrote calibration software for an instrument used to test airframes. You work very closely with somebody who is a domain expert (the analog guy, in my case) and you explain stuff back and forth until you reach a shared understanding of the problem at hand and how the software implements a solution.
And you make damn sure that if either of you has questions or see something funny, you figure it out before you ship.
If this brilliance can be translated to understanding in other fields, which usually it can. This requires studying, which firms simply tries to avoid.
I am a software engineer now, but my major was mechanical engineering, I can barely remember any of my coursework, but I understand how physics work in general, and a small bonus on how to disect a system. Nobody can know everything in today's world and that's why common engineering/sense training is so important IMO.
Similar. I used to design automation equipment, but I've switched to software development. I'm still closely connected to the mechanical side though. More than once I've had to explain to someone who is a competent programmer that they can't accelerate mass x at rate y.
Total guess, some of those managers probably do appreciate what software engineering is, and what it needs, but they're pressured by their managers to cut costs and expertise.
As a QA person, I have to fight with management to get time slotted for exploration, research, and learning work. There's no point crapping out automation for a domain you can't even hold a conversation with SME with.
Anyone just handing off software that you know well, or just having another new person work in it. The rate of "Yeah I thought of that too but it's actually a terrible idea." type discussions are somewhere near 100%.
You'd hope you could communicate or document or something like that but exceptions are endless.
> I really fail to understand the logic that may make someone to think a software engineer, however brilliant, can write software for a domain they don’t understand.
This misunderstanding arises out of necessity to compensate for the lack of understanding of the value of nontechnical roles.
It's heartbreaking for BAs, POs, PMs, and every other flavor of functionary when they realize that, after some* years of experience, the programmers understand the business just as well as they do. And the programmers have countless other invaluable skills that the functionary could never understand if he studied for a hundred years.
*This length of time is variable. Depending on the business domain, it could be anywhere between 1 and 10 years.
> after some* years of experience, the programmers understand the business just as well as they do.
I don't push back on the premise that there are some incredibly dumb non-engineers. But of all the people I've had to work with, engineers were among the best and the worst. The latter has to do with their dysfunctional level of focus and utter lack of creativity - not just in an artistic way, but also in terms of general imagination.
Here's a very common scenario:
- non-engineer: let's improve this by 10%.
- engineer: that will cost 40%.
- non-engineer: I get that. But our current 90% is not competitive.
- engineer: but it doesn't make sense to invest 40% to get 10%.
That's what separates great engineers from the high-IQ/low-EQ ones: they have taste, imagination, and common sense. Incidentally, the latter group tends to have less self-awareness than the former, and tends to think they are the only non-idiots in the world.
> It's heartbreaking for BAs, POs, PMs, and every other flavor of functionary when they realize that, after some* years of experience, the programmers understand the business just as well as they do.
Why heartbreaking? That should make it easier for everybody to do their job, and to do it better.
> It's heartbreaking for BAs, POs, PMs, and every other flavor of functionary when they realize that, after some* years of experience, the programmers understand the business just as well as they do.
Shouldn’t be. Very few engineers want to move to BA/PM/PO or management track.
Boeing management used to be grown from engineers. The person promoted would have been practicing "engineering in the large." I don't know if that's still true.
I think the point is there shouldn't be BA/PM/PO type people. It should just be engineers all the way.
Engineers who understand those roles exist and should be given the reins. Call them whatever but an engineer with domain knowledge is what you need for just about everything.
We’ve had quite a bit of success moving to a product model for internal services. One thing I’ve observed though is that teams lacking strong PM/PO support tend to start looking inward to develop their roadmap rather than outward.
This ends up building little silos in which they are doing something and it’s generally executed well but when you explore their plans it can be hard to see how it connects to the larger view.
I've been tackling the opposite. Product specs their thing which is completely disconnected from the reality of what is actually needed. This creates massive levels of frustration for the end user.
And you can't easily get them that domain knowledge when you're only communicating via story descriptions or software requirements documents. They are looking at the problem through a thousands-of-miles-long tunnel.
It takes time and investment for other engineers to get to know you and feel comfortable explaining their thought process, including parts of the design they are afraid need extra testing.
You can't outsource the essential give and take of a correctly functioning cross-domain team.
I knew one of those. He insisted on remaining a contractor, I think for his particular tax situation.
He would have to leave the company every so often because of company rules (or labor law?) about how long the company could employee a contractor. Eventually he'd get hired back in, as a contractor.
Not sure if you're being serious, and while it hasn't been tried AFAIK for the flight software specifically, but cost-minimization and outsourcing has been credited as the major sources of Boeing's safety problems for the last decade (737 MAX, 787 Dreamliner, 737NG). Doing more of it would be neither a change of course nor an improvement IMO.
> Not sure if you're being serious, and while it hasn't been tried AFAIK for the flight software specifically, but cost-minimization and outsourcing has been credited as the major sources of Boeing's safety problems for the last decade (737 MAX, 787 Dreamliner, 737NG). Doing more of it would be neither a change of course nor an improvement IMO.
I hear you, but I suspect aperocky was criticizing that exact approach.
Makes sense, I was genuinely 50/50 about it being sarcastic, but I probably should have been more confident of it, and at the very least should have given more credence to that interpretation than "not sure if...".
I'm honestly confused that you give it 50/50. Even ignoring the context, the "we" in "what could go wrong if we" only works if it's a rhetorical question. And from there, analyzing it as a rhetorical question, it seems obvious to me that the implied answer isn't "nothing".
On HN, especially if there's talk of labor (or god forbid, unions), there are often some pretty extreme opinions. And I said I shouldn't have given it just 50/50 odds. I don't see the point in continuing this postmortem.
I just feel like the sentence structure doesn't make sense if they were suggesting that opinion. I'm not basing it on whether I think someone might actually have that sort of opinion. But if you don't want to elaborate on your thoughts then that's fine, have a nice day.
I suddenly became afraid of flying when I started working for one of the companies known for having some of the best software engineers in the world and seeing how many bugs made it into prod. I can't imagine who is programming the flight computers for Boeing and what they're being paid. It's gotten bad enough that I refuse to fly on any plane that was released in the last decade. At least the older planes have some decent trip statistics to back up their safety.
Of course, but the specifications are normally written by Boeing, and the implementation is outsourced. The reason is the system as a whole has to function, meaning the spec has to be written by the team that has knowledge of the whole system.
MCAS interfaces with quite a few other systems on the airplane.
Even a good team can convince itself, that it is right. It would have added a "second set of eyes", if the implementors of MCAS had their own expertise in aviation. No guarantee, but a chance of spotting the problems with the spec.
The programmers are just trying to patch what once again is likely a hardware problem. If it's like the MAX the real issue is the flight characteristics
Basically every modern jet aircraft with relatively large engines has some sort of MCAS system. If you raise the nose of such a plane the balance does shift. This isn't a form of an aerodynamic error, it is a consequence of having large engines hanging off your wings (a lot of classic airplanes have the engines in or very close to their central axis). If you want the appropriate feedback in the steering column, you have to compensate for the shift. Airbus does it as well.
Yes, it's the aerodynamic lift from the big engine fans that was the 737 Max issue, according to Aviation Week.
Fans have gotten bigger as engines have improved and the bypass ratios and fuel efficiency has gotten better.
Think of the engines as a big horizontal stabilizer but it's at the front, in front of the center of gravity. Normally it doesn't do much anything since the angle of attack is zero. But if you increase pitch, it will increase nose-up momentum.
For some reasons it's not common to put the engines further back. DC-9 style, on the sides of the rear fuselage might work. Or maybe over the wing and slightly to the rear, like Hondajet.
MCAS-like systems exist elsewhere, but MCAS specifically is worthy of criticism, as both an engineering failure and more importantly IMO a management failure.
Specifically with regard to the flight characteristics, MCAS is a band-aid on a problem created by cost-minimization -- the desire to avoid a hardware redesign (to properly accommodate the larger engines) and/or a re-certification.
Of course, the actual implementation of MCAS was a disaster. Especially, that they didn't deactivate it automatically on AOA disagree, that on top of that the screen signal for AOA disagree was not shown due to a separate issue and of course that late in development MCAS was given more control authority than initially planned.
My point just was, a complete redesign of the 737 still would have to deal with the same aerodynamic issues as the 737 MAX, as they are rather fundamental to this kind of jets. But indeed, it would have been easier to deal with it with a new design.
It is less mentioned, that shortly after the MAX crashes, Airbus mandated that in some planes the last rows were kept empty until some software updates were deployed. So they seem to have discovered some boundary conditions they were not happy with and decided to be rather safe till they augmented the software.
> late in development MCAS was given more control authority than initially planned
... without triggering re-evaluation of the seriousness/consequences of failure. That meant that failures of MCAS were considered unproblematic, which meant that lower levels of redundancy were deemed acceptable.
Well, technically the failures of MCAS should be unproblematic, as the stabilizer runaway protocol is well trained for any 737 pilot and would cope with a MCAS misfunction. The problem is: in the two crashes the pilots either completely failed to follow the protocol (Lion Air) or to late and failed to recover (Ethiopian Airlines).
That is wrong. First of all, the 737 MAX doesn't have flat bottomed cowlings, that was its predecessor, which did not have MCAS.
And the effect is fundamental to large engines. The effect which required MCAS would also happen if the machine had larger ground clearance and would be mounted more under the wings. Actually the way the engines are mounted on the MAX moves them closer to the longitudinal axis of the airplane and thus reduces and thrust-related tendency to pitch up.
The MAX does have flattened cowlings, though the effect is less pronounced than on the NG. Compare the MAX (right) to the completely round cowling on the A320neo's LEAP-1A:
The bonkers thing seemed to me to be having the notification and/or override as an opt-in feature you could buy. Southwest didn't want to train pilots and newly visible behavior requires new training. No surprise that airlines elsewhere in the world also skimped on the "optional" features to the doom of the passengers and crew.
The opt-in feature you mention was for a disagree alert for the plane’s angle of attack sensors.
But, MCAS was only ever using a single angle of attack sensor as its source of truth, so if there was a fault in that single sensor, MCAS could activate at normal attitudes.
But the real problem was that Boeing hadn’t documented MCAS, to avoid the requirement for pilots to obtain type certification for the MAX (so any existing 737 pilot could to fly it without additional training - and it wasn’t just Southwest objecting to this training), and to avoid a full FAA certification process for the MAX.
So on an MCAS activation, even if they had had an AoA alert, pilots would not know how to instinctively deal with it. (I don’t doubt an AOA disagree alert would give invaluable information allowing the pilots to rule out most failures, which when only a few thousand feet high would maybe have saved both planes.)
On the previous day to the Lion 610 crash, the incident aircraft suffered an MCAS activation and fortunately a pilot in the jump seat realised what was happening and what was needed to deactivate it.
It seems being sat behind the trim wheels (so he could see they were moving) and not wrestling to keep the plane in the sky at the same time was needed for that to happen. It must have been terrifying.
The difference is that all Airbus planes since the 1980's A320 are built around computerized flight commands, so the code paths involved are exercised constantly. MCAS only triggers occasionally, meaning if it has a bug, it only shows up at the worst possible time. Airbus planes also have double redundancy (three inputs and computers) for all those systems, where MCAS had none by default.
The main driver is the desire to make engines bigger, thus more fuel-efficient. The fuel savings of the newest engine generations are significant. If you hang engines from your wings (I assume that has practical reasons, it is easier to hang the engine than include it into the wing, it is also easier to maintain), larger engines mean engines further from the axis. That applies to all modern airplanes which share this configuration. A complete redesign of the 737 wouldn't have made this go away either. However the goal of keeping the same type rating made the especial design of MCAS necessary.
In 737 case, it means redesign of the landing gear system, fuselage modifications, recertification, retraining, new support system requirements eg. Higher stairs, cargo support equipment etc.
You also can't put longer main gear: as they fold inward, they have to attached at points separated by over twice the height. If you move them apart, you have to make the center fuselage as well as the root of the wings much stronger. That's a much bigger change than anything else.
I believe they altered the landing gear so it extends upon deployment, giving it a bit more height, but that's not enough. They can't just put longer legs, there isn't enough room. There's stuff there (cables, devices, bulkheads ...) and moving them requires a significant redesign. For the main gears, they would have to be attached further away from the center lest they bump into each other, which means the wings and fuselage would have to be stronger to accommodate for it. Very quickly you're just designing a new plane.
The thing is, this wouldn't have magically solved the issue. Larger engines hanging from your wing fundamentally affect the balance of an airplane. Take the thrust vector for example. The further you move the engine from the longitudinal axis of the plane, the stronger the angular momentum is, that is exercised from the engines onto the plane, especially when pitching up.
There's only so much room for the landing gear. Larger diameter engines require longer landing gear. Increasing the space given to landing gear requires changes to the wing box. Changes to the wing box is fundamentally a wing redesign.
Which is why the A320 is designed to be loaded with conveyors. This means it has no problem accommodating an even larger nacelle than the 737 in a regular position instead of the up and forward the 737 Max resorted to. Even the previous generation 737 was running into this issue and that's why they went with the distinct oval nacelles.
I always get a negative reaction for mentioning the Emergency Airworthiness Directive sent to all MAX pilots. Media accounts never mention it, either.
The Boeing Emergency Airworthiness Directive says:
"Initially, higher control forces may be needed to overcome any stabilizer nose down trim already applied. Electric stabilizer trim can be used to neutralize control column pitch forces before moving the STAB TRIM CUTOUT switches to CUTOUT. Manual stabilizer trim can be used before and after the STAB TRIM CUTOUT switches are moved to CUTOUT."
I also recommend the recent Aviation Disasters episode on it. While shallow, because it has to fit in 40 minutes, I was shocked that it was surprisingly accurate. Kudos to the Smithsonian channel. I wouldn't be surprised if AD waited until that report was released before doing the episode, so it would be using verifiable facts.
One out of 313 active AD's [1], 12 with no effective dates that seems to signify a different class of AD's because their issue dates are all over the map. I'm okay with 313 patches that I apply and the computer executes it from then onwards. Above a certain limit of number of AD's that should be memorized by pilots at all times, instead of entered into maintenance tracking systems for example, I'd like to hear from pilots why safety-wise that doesn't trigger a type re-certification.
I know that is expensive and time-consuming, but I certainly don't expect for example, my most senior ops team members to recall off the top of their heads more than a handful of critical procedures to execute on-the-spot without referring to the runbooks. Why does it appear that AD's are expecting pilots to apply a seemingly unbounded number of these "patches" like computers without re-training?
Your link is to Airworthiness Directives. The one I linked to is an EMERGENCY Airworthiness Directive.
This EMERGENCY AD was about an actual crash of the same airplane, and contained a 2 step procedure from recovering from the MCAS malfunction.
It's a whole two steps:
1. trim back to normal with the electric trim switches
2. turn off the trim system
Not only that, this is what they're supposed to know anyway. Recovering from stab trim runaway is supposed to be a memory item, meaning memorized.
If you were a MAX pilot, wouldn't you pay attention to this?
Are you saying the pilots should have been able to handle it? Training wasn't needed? Obviously you're trying to make a point but you aren't saying it, you're just presenting supporting details. So I'm asking you to clearly state what the take away from all that is supposed to be.
