Yay Boeing

Ouch!

There was a recent article in the Seattle Times about a brain drain of experienced engineers out of the company. Maybe they can get Ron W. to come out of retirement?
 
Ouch!

There was a recent article in the Seattle Times about a brain drain of experienced engineers out of the company. Maybe they can get Ron W. to come out of retirement?
What, back to my old job as Space Relay Designer? :)

Ron Wanttaja
 
There was a joke that Starship would reach orbit sooner than this Starliner. Now it's no so much of a joke.
 
Making valves out of a material that don’t corrode in the presence of Water and rocket fuel doesn’t seem to be a major challenge……..but I’m not a Rocket Scientist, just a plane old aircraft and engine engineer:cool:

Cheers
 
What, back to my old job as Space Relay Designer? :)
I thought you worked on the Illudium Q-36 Explosive Space Modulator?
"It blocked my view of Venus!"

Boeing is still highly Balkanized in the Space arena. Old MacDac space/rocket folks are still operating on their own, old North American rocket folks are operating on their own, old Hughes folks are operating on their own, and heritage Boeing space groups are operating on their own. Very little cross-polenization. So don't blame my old group.

Ron Wanttaja
 
Making valves out of a material that don’t corrode in the presence of Water and rocket fuel doesn’t seem to be a major challenge……..but I’m not a Rocket Scientist, just a plane old aircraft and engine engineer:cool:
We have a biweekly Zoom meeting of retired space guys from my particular area. One of the theories bandied about is that an umbilical took a lightning hit and scrambled the electronics.

Ron Wanttaja
 
This sums it up nicely… too many players

“The SpaceX success seems even more impressive considering that SpaceX’s Dragon capsule sits atop SpaceX rockets with engines built by SpaceX.

The Boeing Starliner capsule sits atop a United Launch Alliance, or ULA, rocket. Some of the engines are made in Russia, while others come from suppliers such as Aerojet Rocketdyne (AJRD).”
 
This sums it up nicely… too many players

“The SpaceX success seems even more impressive considering that SpaceX’s Dragon capsule sits atop SpaceX rockets with engines built by SpaceX.

The Boeing Starliner capsule sits atop a United Launch Alliance, or ULA, rocket. Some of the engines are made in Russia, while others come from suppliers such as Aerojet Rocketdyne (AJRD).”

Mercury, Gemini, Apollo, Skylab, and the Space Shuttle all were developed using multiple players, usually running in the thousands. My own specialty area, Space Systems Engineering, comes from the need to coordinate efforts and successfully integrate hardware from a number of sources. You have a complex enough system, it is not efficient or cost-effective to do 100% of the work in-house. Aerojet has been developing space hardware since the '50s or earlier.

However, problems can arise when political considerations bypass engineering control. Boeing found that out when they subcontracted a ton of 787 parts to companies in other countries, and found these companies did not implement the rigid discipline that Boeing was used to.

Working in the Black areas for most of my career, I didn't have much of a direct experience with this. But I did see it on one program, where the customer (non-governmental) spread the subcontracts over multiple international companies to get their governments to provide licensing support. In this case, they actually spent ten times as much for some parts, just to be able to provide business to these foreign companies. They also decided to believe one set of vendors, despite Boeing engineer's experience on an earlier program that indicated the vendors could not be trusted.

Best example of this I've heard of was on the Airbus A380. One of the Airbus concerns developed the Catia software used to design the aircraft. All the subcontractors were required to use Catia.

However, the German and Spanish partners didn't have the most up-to-date version, and they were loath to spend the money to upgrade. The two versions weren't completely compatible. They brought political pressure... the German president contacted the French president, and the pressure was applied to Airbus. They didn't HAVE to upgrade.

And, of course, the electrical interfaces were messed up.....

Ron Wanttaja
 
However, the German and Spanish partners didn't have the most up-to-date version, and they were loath to spend the money to upgrade. The two versions weren't completely compatible. They brought political pressure... the German president contacted the French president, and the pressure was applied to Airbus. They didn't HAVE to upgrade.
On the other hand, we were frequently locked into antiquated releases of vendor software supporting legacy programs so that we didn't have to revalidate tools and legacy code, which was particularly important with a vendor that like to change intrinsic functionality drastically between releases. Imagine calling vendor tech support(*):
"I'm getting strange results from the XX function."
"What version are you using?"
"v2000.1"
"Dude, it's 2016! That was 20 releases ago!"

(*)Paraphrased to protect the guilty.

It's frustrating, but configuration management, including tools, is absolutely critical - as your case illustrates as well.

Nauga,
dated
 
I remember when I worked as a rocket scientist (well, engineer for Martin Marietta Denver Aerospace) in the early 1980s. We'd go to a meeting and the Rockwell guys were all puffed up because they built the shuttle orbiter. We'd just look at them and ask how many they got to build. Then we'd remind them that we built the external tank, and NASA needed a new one for every flight. That's where the money was in space flight - the expendables. :D
 
Growing up in the JSC community and even the reason my family was able to immigrate to the U.S. was the fact my father was a rocket guy working on the blue streak in the UK. My friends dads were all Rocket scientists from all around the world as NASA reached out to find any engineer that could help put Apollo on the moon. Contractors build everything. NASA acts as a administration…sort of like the FAA…never built an airplane…but throw enough money at it it might happen…but building stuff for the government is good business as it’s easy money with no downside once you get the contract.
 
Musk has a few simple rules..
These are the elements: (1) Make requirement less dumb, (2) delete parts or processes, (3) simplify, (4) accelerate cycle times, or “go faster,” and (5) automate.

Worst thing is an over engineered solution to a simple problem.

All companies should follow the 5 points.
 
Worst thing is an over engineered solution to a simple problem.
Yup. An answer to many E-AB newbies that want to design their own homebuilts with fly-by-wire and other such stuff. Or hydraulic controls. Somehow, cables and pulleys, or push-pull tubes, are SO old-school.
 
...Worst thing is an over engineered solution to a simple problem....

Yup. An answer to many E-AB newbies that want to design their own homebuilts with fly-by-wire and other such stuff. Or hydraulic controls. Somehow, cables and pulleys, or push-pull tubes, are SO old-school.
I contend that an under-engineered solution is just as bad. EAB is a good source of examples there, too.

Nauga,
from where TLAR doesn't always mean it is
 
There was a joke that Starship would reach orbit sooner than this Starliner. Now it's no so much of a joke.
At times, it seems like Jefferson Starship will reach orbit sooner than any post-Shuttle US program.
 
Worst thing is an over engineered solution to a simple problem.
Saw a great example of that about 25 years ago. Company we were working with needed a mechanism to open a solar array. They had all these snubbers and energy absorbers and this and that to make the opening as gentle as possible. Our chief designer maligned it as "something suitable to open the trunk of a British car."

He had a similar problem about the same time, opening a large metal cover. He deliberately tweeked the hinge line of the cover so that it had trouble staying shut, put two horking big springs to drive it open, a trojan-head clasp to decelerate and latch the cover, and kept it closed using a large explosive bolt.

We'd show our Government customers videos of ground testing, and they would outright gasp. It slammed open, with the metal cover actually shivering after being caught. The audio was a KA-SLAMM WOGGA WOGGA Wogga wogga."

But you know, it worked EVERY time on orbit.....

Ron Wanttaja
 
Most great designs come from small teams, where the goal is consistent and the design is gradually tweaked. As a mechanical example of that, John Browning. Software, lots of examples, one being Linus Torvalds. What companies today seem to do is have really large teams, and continually change the goals, calling it "rapid development" or some nonsense. And they wonder why the quality sucks. Imagine doing something so simple as planning a football offense, where they completely re-write all the rules between games. We're doing things backwards. Or maybe trying to hurry up and do things ever badly.
 
Most great designs come from small teams, where the goal is consistent and the design is gradually tweaked. As a mechanical example of that, John Browning. Software, lots of examples, one being Linus Torvalds. What companies today seem to do is have really large teams, and continually change the goals, calling it "rapid development" or some nonsense.

Hey, it worked for the Klingons... :)

http://www.wanttaja.com/rapid.html

We used the term "Rapid Prototyping" in our neck of the woods; did the first program in the '90s. I helped write a Boeing rapid prototyping guide. Used the process successfully for several sequential programs, with a number of satellites deployed. Last one put multiple satellites on orbit for less than $10M (not including launch, but we got a free ride on an X-37B). Development time, from scratch, was one year (waited longer for the ride).

It's tough to do what's necessary to accomplish this in a big company like Boeing. The first program in the '90s, we were really, REALLY isolated from the company as a whole. Even our IT guys were independent. If we needed a new computer, the IT guys took the program credit card and went to Circuit City. While there was squawking within the company, we always had 100% buy-in from our Government customers.

Toward the end of my career, we were losing some of that kind of independence. Most of it was due to the Boeing/MacDac merger. Our upper management chain now terminated out of state, and hell hath no fury like a mid-level manager who is told, "Sorry, we're not going to tell you what we're doing..." Helped that they couldn't access our files/information from California (no network connection at the appropriate security levels).

The only way we got this done, as Thought-Captain K'anttiah says, was due to secrecy. We had legitimate reasons we couldn't tell manager so-and-so what we were up to. The Government was doling out access with an eyedropper, and we needed more engineers, not managers.

Best thing about it is that we worked *with*, not against, our Government customers. We set up a small area right in our work zone, and always had Government reps on-site who were welcome in ANY meeting, any testing, knew the same time we did when a problem occurred, etc. Not only did this foster a sense of teamwork, but it was an outstanding opportunity for young lieutenants and captains to get hands-on experience actually BUILDING something, rather than evaluating quarterly reports.

Now, Starliner is a lot bigger, and I suspect many of our techniques wouldn't be applicable.

Ron "Get off my lawn" Wanttaja
 
Hey, it worked for the Klingons... :)

http://www.wanttaja.com/rapid.html

We used the term "Rapid Prototyping" in our neck of the woods; did the first program in the '90s. I helped write a Boeing rapid prototyping guide. Used the process successfully for several sequential programs, with a number of satellites deployed. Last one put multiple satellites on orbit for less than $10M (not including launch, but we got a free ride on an X-37B). Development time, from scratch, was one year (waited longer for the ride).

It's tough to do what's necessary to accomplish this in a big company like Boeing. The first program in the '90s, we were really, REALLY isolated from the company as a whole. Even our IT guys were independent. If we needed a new computer, the IT guys took the program credit card and went to Circuit City. While there was squawking within the company, we always had 100% buy-in from our Government customers.

Toward the end of my career, we were losing some of that kind of independence. Most of it was due to the Boeing/MacDac merger. Our upper management chain now terminated out of state, and hell hath no fury like a mid-level manager who is told, "Sorry, we're not going to tell you what we're doing..." Helped that they couldn't access our files/information from California (no network connection at the appropriate security levels).

The only way we got this done, as Thought-Captain K'anttiah says, was due to secrecy. We had legitimate reasons we couldn't tell manager so-and-so what we were up to. The Government was doling out access with an eyedropper, and we needed more engineers, not managers.

Best thing about it is that we worked *with*, not against, our Government customers. We set up a small area right in our work zone, and always had Government reps on-site who were welcome in ANY meeting, any testing, knew the same time we did when a problem occurred, etc. Not only did this foster a sense of teamwork, but it was an outstanding opportunity for young lieutenants and captains to get hands-on experience actually BUILDING something, rather than evaluating quarterly reports.

Now, Starliner is a lot bigger, and I suspect many of our techniques wouldn't be applicable.

Ron "Get off my lawn" Wanttaja
Reminds me of my days on Senior Trend (F-117), Tacit Blue and other things unnamed. I demanded the same thing on the YF-22/YF-23 Program when I had the stick.

Cheers
 
Back
Top