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 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.
Where are those managers?
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.
Shouldn’t be. Very few engineers want to move to BA/PM/PO or management track.
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.
Why heartbreaking? That should make it easier for everybody to do their job, and to do it better.
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.
And you make damn sure that if either of you has questions or see something funny, you figure it out before you ship.
You'd hope you could communicate or document or something like that but exceptions are endless.
I have yet to meet one of those unicorns.
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.
So are the computers that have to actually implement the solution. So that seems like at least as much a blessing as a curse.
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 hear you, but I suspect aperocky was criticizing that exact approach.
I.e it felt like sarcasm.
Do you disagree with either part of my reasoning?
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.
MCAS interfaces with quite a few other systems on the airplane.
They don't need to redesign the wings to accommodate the newer, larger engines.
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.
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.
... 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.
Quite a process/management failure.
No, it would have more ground clearance, so it wouldn't need flat bottomed cowlings nor 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.
https://leehamnews.com/wp-content/uploads/2020/11/737NG-vs-M...
https://aerocorner.com/wp-content/uploads/2020/01/Aegean-Air...
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.
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.
The 737MAX should have gone through a new type certification, but didn't to allow for less pilot retraining.
FAA failed to properly serve the public.
New type cert finds flaws and saves lives.
The real issue was the reliance on one sensor coupled with too much authority give to MCAS and inadequate failure analysis.
And pilots who did not read, remember, or follow the 2 step recovery process in the Emergency Airworthiness Directive sent to all MAX pilots.
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."
https://theaircurrent.com/wp-content/uploads/2018/11/B737-MA...
For those who are skeptical of mainstream media fake news on the topic, here's the official final report on the Lion Air crash:
2018 - 035 - PK-LQP Final Report http://knkt.dephub.go.id/knkt/ntsc_aviation/baru/2018%20-%20...
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?
[1] https://www.faa.gov/regulations_policies/airworthiness_direc...
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?