> I'm retired now but did propulsion and systems engineering on the Transfer Orbit Stage (TOS) developed by Orbital Sciences and Lockheed Martin for NASA/MSFC in the 1990's. [...] I'll make a few comments on how/where things might have gone off the rails with the RCS thruster thermal problem.
[1] https://forum.nasaspaceflight.com/index.php?topic=60593.msg2...
This is obviously a well-known phenomenon in software engineering and I don't think anyone here is going to be be particularly surprised that it occurs in the aerospace setting. What is a little more surprising, to me at least, is that the systems people over there don't have procedures in place to minimise risks stemming from lack of communication.
It isn't realistic for any sub-team to be fully familiar with the overall system but surely, for instance, if a team is working on component X which interfaces with components Y and Z, then it should be standard practice for the X team to spend at least some time with the Y and Z teams during development?
Stopping outsourcing doesn’t change the fundamental problem of accountability, people just find different ways to avoid it.
Having worked on the public sector (Air Force), there's enormous pressure on groups like NASA to outsource because voters perceive government work as wasteful and expensive, and contracted work as efficient because free market.
And, those contracts end up being the most wasteful and expensive of all.
> "Spend some time with the other team"
How about design documents? Is that truly a lost art among the latter-day geeks?
This is why you have to get the humans to talk to the other humans. If that communication happens via a collaborative design document then yes, that's a process, and it's one that can work.
In my current role (high-assurance deterministic code for self-driving cars, one of the top-tier players, a company who claims to be "safety obsessed"), we have close to zero documentation. Every team or department has their own standards for documentation. Documentation is always back-written after coding is complete. Requirements are written after code is complete. For the past year, I've been given tons of praise at department meetings, "look at so and so, they've written so much really good documentation, their docs are the standard everyone else needs to follow", and then when it comes time for promotions my managers tell me "well, you haven't shipped as much code as other people on the team .... absolutely you've done a terrific job with documentation and we totally recognize you caught a ton of problems before they became problems, but promotions are really based on 'results', and 'results' means how much code you wrote ....". So I'm job hunting.
A team was tasked with modernizing their multi-million dollar decades old test stand. The entire time they were cursing previous engineers for their lack of documentation that made reverse engineering difficult. Then when it came time for them to produce the documentation on their own design, they balked at the idea. I had a conversation with them about how they are screwing over the future engineers just like they were screwed over, but they still maintained cost/schedule pressure was too much to comply. We settled on them being allowed to go forward as long as they set aside a fund source and a date to have the documentation complete. When that date came and went, the documentation wasn't done and the excuse was the funding was used up by other projects. I feel like I owe those future engineers and apology.
I don't think I'd be so trusting/naïve today and would push back harder that if they couldn't get their documentation in order when the design was fresh in their mind, they're even less likely to do so in the future.
Until the moment it doesn't.
The Mythical Man Month surely applies.
/s
The Mythical Man Month applies when you task more people to work on the same job with the expectation of faster results.
He is proposing to task more people to work on different jobs with the expectation of higher quality results.
They did test firings of individual thrusters, and even did some with multiple thrusters, but with many of the systems in the doghouse missing and the insulation taken off.
Having read a good amount about their methods, it really seems like Boeing has relied heavily on component level tests and analysis rather than integrated tests. And it has bitten them many times so far.
I'm curious where you're getting this? I've read speculation, but I've never seen any authoritative source claim the test hardware configuration was different than the flight configuration. The better sources I've seen tend to indicate it was an inadequate thruster profile in the tests, rather than a configuration issue.
So we coded to the specs. I spent a lot of time reading those and trying to figure out what they meant. It was a little challenging but usually all the information was there. It worked (mostly) and we tested alot. Some stuff was strange, I still remember seeing angles in BAMs (Binary Angle Mesurements)
SpaceX works "hardware rich", building lots of prototypes early in the development process. When Boeing and ULA launch their first "production" launch, the previous test articles generally haven't been anywhere near complete.
Are there full-stack engineers? or are the individual domains too complex compared to coding?
Some of them were for getting more detailed information about the Moon prior to sending the Apollo missions there. But most of them were general solar system exploration.
> That's like saying Starliner's Demo flights don't count as human-rated because they were uncrewed.
No, it isn't. The counterpart in the 1960s to these missions would be the uncrewed flights of the Mercury, Gemini, and Apollo spacecraft that were done prior to the first crewed missions. I did not include those in the unmanned missions I listed.
- They sent 4 rovers to Mars, a freaking helicopter, and confirmed water presence.
- They launched 2 telescopes, with Webb forcing us to rethink our model of the universe.
- They made New Horizons do a flyby... of Pluto.
- And they collected samples from the near-Earth asteroid Bennu!
If that's not the demonstration of anything but drastically high competence to you, nothing is.
At this stage, I have to believe you are a troll.
What's the other telescope you have in mind?
And those two free telescopes from NRO are still sitting idle. One of them is supposed to finally launch after 15 years, though apparently it's in such a complex and high budget mission it might not be saving any money to use it there.
> Curious if the root is someone at Boeing accidentally not relaying vehicle updates to vendors, or if it was a conscious decision to avoid paying for change requests.
Seeing how Boeing "incidents" have piled up in recent years, and reading how most (or perhaps all) of those issues were due to "cost saving" measures, I wouldn't put it past them to have made that decision consciously, lives be damned.
From the comments it can be pretty succinct:
>Yes, I know the aircraft and space divisions are separate. Doesn't matter. Shit always runs down hill if Corporate is squatting.
I've mistaken them for the official nasa webcast more than once before realizing that the two casual dudes talking can't possibly be official commentators. Isn't this some sort of trademark infringement they're doing?
NSF is not affiliated with and does not represent the National Aeronautics and Space Administration (NASA). NASA initials are used with NASA’s permission.
"NSF is not affiliated with and does not represent the National Aeronautics and Space Administration (NASA)."
I’m shocked they’re able to keep operating like this. Can I walk around Seattle video recording bicycle thieves and call it “Seattle Police Department Video”?