The thruster map error should have been detected in simulation. If it wasn't, the simulator is also faulty.
I'll assume the thruster map was only slightly wrong and that whatever simulator runs they did with it were very subtly off.
Still... What a mess...
What in the world are you talking about? There’s been no reporting of anything like that. The MAX engineers failed all by themselves. No management told them to design MCAS in a brain dead fashion. Nobody “weakened” engineering leadership.
The problem is that Boeing management never said that. Moreover, the fired CEO was an engineer.
As an engineer, he was accountable to reality. As a CEO, he was accountable to the board and the financials.
Guess which won.
Moreover, the 737 Max program ran from 2011-2015. The CEO at the time was an MBA.
Traditional engineering companies don't respect software. You can tell by the fact that they pay well below market rates.
I suspect Boeing maybe treats software the same way as they've always done, just one of many boxes that need to be ticked in a long waterfall like process. They just throw more people at it hoping it gets done on whatever time line they imagine it needs to be done. They are likely to be very conservative with respect to tools, technologies, and practices (i.e. not much has changed there in decades).
The fact that SpaceX is able to come up with a new design for Starship and can then get it and the software working for several successful hovers & hops in around 9 months, tells me they are able to iterate quickly and adapt to quite major design changes. They launch a lot of rockets and they seem to be learning a lot every time they do this. I don't see how they'd be able to do this without very solid software development practices. I'd expect lots of CI & test harnasses, probably lots of emulators and other tools, and I have a hunch they probably use a lot of static code analysis etc. to prevent preventable bugs from happening.
Any engineer or tech at SpaceX is likely worth their weight in gold at any other company due to the company's perceived high bar. Additionally, I don't hear complaints about their pay either, which is likely extremely good.
No one is locking them into cages and telling them they can't leave. I would bet most everyone who is there strongly believes in the mission.
EDIT: Eh. They aren't paid fantastically but not slave wages either. Additionally this is spread out over three very different cities.
https://www.glassdoor.com/Salary/SpaceX-Engineering-Salaries...
That's true for a lot of other companies where people here have advocated the employees would benefit from unionization.
For the record, I am conflicted on engineer unionization, and my original statement was intended to be neutral.
As to this specific example, on one hand I understand the drive that comes from having a real mission (as opposed to an MBA-concocted "mission") and how a team who share that drive can execute with amazing speed; conversely, I have seen how poorly teams of clock-punchers putting in the bare minimum can perform.
On the other hand, I have also seen "the mission" used as a means to guilt trip people into overwork or accepting substandard compensation.
Of the two, I lean towards the SpaceX approach being the better one. In the absolute I don't particularly like either of them.
> EDIT: Eh. They aren't paid fantastically but not slave wages either. Additionally this is spread out over three very different cities.
> https://www.glassdoor.com/Salary/SpaceX-Engineering-Salaries....
Those salaries look to be in line with what equivalent engineers at Raytheon, Lockheed, and Boeing are making in those same locations, maybe a bit higher. Thus, if the WLB reports from SpaceX are to be believed, their per-hour pay is much lower. It's hard to tell, though, without a proper breakdown by years of experience. Also, there are certainly teams within those companies where the engineers put in just as much time and effort as SpaceX engineers. Boeing is the only one I am aware of that has unionized engineers, though.
Not that it's impossible, but you'll need tooling that prevents you from making the mistakes you'll unavoidably make when tired.
Einstein would certainly not have solved relativity by saying "Uh I guess from 9 to 5 I will work on this with a one hour break in between and then I am heading off to the fun stuff called leisure time".
No... Only if you think about these problems day in and day out you can work at in the top percentiles and this is the kind of people that get hired there.
People want to work on cool stuff (in the sense of rockets or in the sense of making the world better, or both). They will accept lower pay (per hour) to do that. Therefore, working on cool stuff demands longer hours and lower pay compared to less glamorous things. It's not an inherent requirement of the field; it's a side effect of human preferences.
I don't want a rock star anywhere near the software that operates a complex machine where a malfunction can kill people.
It can be quite common in the space industry to load non-flight or old versions late in the AIT phase in order to test on other modules, or even just to officially close old actions. But before delivering everything we would check all the versions, and make sure that everything is as expected and most importantly, as described. If that step was screwed up, it is bad news for the QA, but that would explain why the errors could be found and fixed quickly: it meant just going through all the non-conformances and change logs and understand what was different between the version used, and the version that should have been used.
You can do a pretty decent simulation of a space mission on a powerful cluster. You then plug in your simulated spacecraft and run the real flight software. Reentry is easily the most critical phase of flight for a crewed spacecraft, and they should have absolutely tested and caught this flaw in simulation. Ground testing could have also checked on the actual spacecraft that the correct valves were actuated when commanded to.
If I were to speculate, this suggests a pretty large disconnect between the software and hardware engineering teams. The software team should have been able to identify that the wrong valves were being actuated.
>How can that even be "reviewed" in any way but superficially in a time frame less than 5 years?
If it can be written then it can be reviewed, you just need to pay for more engineers to do that.
I guess I’m spoiled working on a (mostly) Ruby project with ~100K-ish lines of code with a team of 25
We're about to start our next hiring spree in case you're looking for a new challenge ;)
Software is hard. Embedded software doubly so, but... Come on... This should not be happening to Boeing.