In an LA Times interview with Ed Mango, he repeats a common fallacy in the aerospace industry:
Boeing has their design, which is also a capsule-type design, and is trying to work out the same kind of issues that Dragon has. The only difference is that they haven’t flown their stuff yet. But Boeing has 50 years of human spaceflight already. They have all the people who did Mercury, Gemini, Apollo and the space shuttle. They have all the trips and falls that have been made over those 50 years.
As I’ve said for years, companies don’t have experience — people do (this is a fallacy that government evaluators subscribe to, because every proposal we put in to NASA or the Air Force always included the past experience of the organization, regardless of whether or not the people who would be actually working it had such experience). Most of the people who actually worked on the development of those programs are retired or dead. At this point, I would say that when it comes to building reliable cost-effective space hardware, SpaceX has the best team in the country, with the most recent experience (though they got help from some key people at NASA, such as John Muratore). That is not to say that the people working CST at Boeing aren’t good, but it’s really meaningless to tout their historical experience as having any relevance to the current team.
Most of the people who actually worked on the development of those programs are retired or dead.
Or quit to go to the competitor’s company that valued the experience a bit more than the previous company.
There’s also the issue in which lessons learned were actually captured by the company, thus retaining some of the knowledge lost in personnel attrition. How many on the next project actually read those lessons before setting out on their design?
I’m sure many of us can list a variety of lessons supposedly learned from Mercury, Gemini, Apollo, Skylab, and Shuttle, yet actually have not been learned, particularly when one looks at the proposed SLS. I know from my experience that most of the lessons captured from Shuttle-Mir were identical to ones captured for Skylab, as if we learned them again a generation later.
Could you give some examples of lessons relearned from Shuttle-Mir that were first learned for Skylab? Thanks. (Not being argumentative.)
Here’s an IG report written around the same time I did my review. To avoid giving away what NASA paid me well to do; I’ll just use it and point to the section “Personnel Transition”, which both discusses Rand’s point and one of my favorite repeat lessons regarding stowage. Stowage was a big problem on Skylab, Mir, and now ISS. One of the important aspects of Dragon, overlooked by many, is the ability to bring things down and in one piece. Of course, it helps when you can easily sort what is and isn’t trash (see again the IG report).
Yes, it is at least possible for an organization to document experience in a way that is transferrable to new people, but so few organizations do a good job of that.
I worked for a company called PCS (programmed computer systems, how original?) on Williams St. in the shadow of the world trade towers many decades ago. I did a number of things, from installation, data conversion and training to closing sales. One of the things that was very important to the boss was ‘institutional knowledge.’ In practice, what this meant was I had to produce a written debriefing after every job. In theory, this could help others do my job.
But I still have to back Rand 100% – companies don’t have experience — people do. Even those people don’t if it’s not recent. Nobody is the person they used to be; they are the person they are today.
Their work on ISS and X-37b is more recent.
But that’s not what Mango cited.
Surely some of the people that worked on the last round of shuttle upgrades are still around.
Makes me think of the Dilbert “Dan the Illogical Scientist” series.
Dan: You can be assured that I’m right, because I’m a scientist, and scientists have done many wonderful things.
Dilbert: But, those were other scientists, not you.
Dan: Apparently, you don’t understand science.
While Muratore _will_ no doubt be a big contributor, he came in very late to have contributed much of anything to Dragon development.
I was introduced to the power of legacy knowledge back in 1986. My training to operate satellites was delayed so they loaned a bunch of us underutilized officers to various organizations. I was lucky. My Rent-a-lieutanent assignment was to the Director of Analysis at Space Command. While there, I got to work with Dr. Beat Wackernagel (sometimes called the Father of Space Surveillance) and some senior civil service types who’d been around forever. Whenever I had an idea, one of them would say, “Yeah, we studied that back in 1967” and would pull the study report from a filing cabinet. That was a great way to learn about previous lessons learned and could serve as a starting point for further analysis. The old work was usually of high quality. There was no need to reinvent that wheel but it made it easier to determine if newer technology could make the idea possible if it was deemed unworkable before.
You are so fortunate, that when you said, “I have an idea” and they said, “Wait, let’s pull that study from 1967 from the files and look at it.”
Too many other places would just say, “Been there, done, that, didn’t work, now shut up already and do what we told you.”
The studies may no longer exist. In many cases, archives have been purged over the years. Especially at companies that have gone through multiple reorganizations, mergers, departed (and reentered) various lines of business, etc.
When SGI acquired Cray Research, for example, they reportedly purged the source-code archives. Not a single line of code is left.
Boeing didn’t actually build Mercury, Gemini, Apollo, or the Space Shuttle — those were built by companies which Boeing later acquired. I’m sure Boeing was careful to keep all of the documentation for systems they were still supporting, like the Shuttle, but legacy systems like Mercury, Gemini, and Apollo? I wouldn’t bet on it. Much less studies of things that were never built.
And even if the studies weren’t thrown out, you might never find them. The Air Force (and Boeing) lost the DynaSoar prototype, which was reportedly 50% complete when the project was cancelled. It’s apparently in a warehouse somewhere next to the Ark of the Covenant. If you can lose something like that, imagine how easy it is to lose a 20-page report. (On the other hand, a missing report is much more likely to turn up in someone’s home office.)
I read some time ago that NASA has maintained microfiche files of all their early space projects. Searching those would be a pain, though, and I doubt if they have anything on the different design studies.
I remember using those microfiche machines. It was a painful experience. (Literally, if you stared at them long enough.)
The microfiches have now been digitized and are available online through the National Technical Information Service. Unless they’ve been, you know, lost.
Some of them were almost illegible when they were on film, and digitizing hasn’t improved them any.
At one time Kodak’s back-up primary mirror for the Hubble Space Telescope was said to be sitting outside of a Perkin-Elmer warehouse in a forgotten shipping crate. Fortunately it didn’t end up next to the Ark of the Covenant and was finally shipped to the National Air and Space Museum.
NASM link.
As an aside, the backup mirror is ready for aluminizing and a Falcon 9 can put a Hubble into orbit. If the James Webb Telescope gets cancelled, someone should push for the obvious Hubble II project that would mainly consist of assembling back-ups and upgrades to Hubble components (all of which are virtually useless for anything else). If done as a purely private-sector venture (so NASA doesn’t try to attach 5,000 jobs to the project) it probably wouldn’t cost much more than the Falcon 9 launch.
I guess you haven’t been following the news, George.
http://www.citizensinspace.org/2012/06/thoughts-on-telescopes/
I know what you mean, Rand. Whenever I get into a conversation with a bunch of space enthusiasts, someone always brings up the “experience” some old space company has over a new space company. I am so tired of making the point you stated about the people who did the work so long ago are gone.
I wonder how many people who are working for SpaceX once worked for P&W rocketdyne, Locheed Martin or Boeing? I bet a bunch of them. They brought their expierence with them.
I’ve never understood why some of the US Armies cavalry divisions don’t compete in the Kentucky Derby. They have such vast institutional experience operating horses, or have most of those officers retired?
You know what a Bradley would do to the track?
It’d be fun to see…
Comes to mind:
http://www.cnn.com/2011/10/06/us/afghanistan-horse-soldiers-memorial/index.html
They compete at the National Cavalry Competition.
http://www.uscavalry.org/events/current-events.html
I’ve had plenty of experiences where I was on a team that had to design something no one on the team had experience designing before. The first place we would go is to public knowledge reports and papers. On the one hand, even to find the relevant papers often required an outside consultant. On the other hand, that knowledge base meant we could do some very real trades. It was an approach of “take the 1950’s reference design, note how it differs from your application, find out if any 1970’s or 1980’s research solves some of the problems, then run some CFD on it, tweak it with input from the knowledge base, go to the wind tunnel, rinse, repeat.” At some point you rely far less on legacy, but that is because legacy got you to the point where you could identify your unique problems. So I would say institutional knowledge does exist and can be helpful but yeah, a guide is extremely advantageous.
What really bugged me was Boeing’s advertising campaign in the wake of its purchases of Rockwell and McDonnell Douglas. It was Boeing, in the revisionist eyes of its advertising department, who had built every American manned spacecraft, the Saturn V rocket, and all of the engines that powered the Saturn V to the moon.
If the Internet had been around at the time, I’d have been tempted to circulate parody ads about how Boeing killed the Apollo 1 crew…
The punchline is that most corporate cultures are especially immune to learning lessons from experience.
People do have experience, and the people who had experience at Boeing have long retired. But the whole point of written communication is to pass on that knowledge to following generations.
Reading a report by Wernher von Braun will not make you Wernher Von Braun.
Also, remember that NASA has copies of all the reports (at least in theory), and anyone else can get them under Freedom of Information. So, merely having the reports does not provide Boeing with a unique advantage.
Everyone here no doubt knows that NASA played more of an oversight role than in-the-trenches, getting-their-hands-dirty, grappling with practical problems. The big aerospace corporations do have a lot of legacy data and code which can at least steer one in the direction of something which has been tried and worked before. Whether they actually use it in a new program, or have anyone left who actually understands it, is another question.
Some of the older experience is invaluable. The main problem is sifting out the wheat from the chaff, the reams of reports written about how to get around the limitations of the day’s processors, for example, how to approximate a trig function with just four multiplies, versus the un-duplicatable except at-great-cost data taken with sounding rockets and drop tests, for others.
The AIAA website allows one to search out papers based on topic and keywords. That’s better than many corporation’s legacy material. Does anybody here work for a company which has made a systematic attempt to cull their historical internal docs into an accessible library?
I don’t work at such a company. Some of the newer document management systems could be very useful. They not only support version control for documents but free form (Google-like) searches that aren’t limited to keywords. Getting the original documents (in whatever form they exist) into the document management system is a non-trivial exercise, which is why I suspect most companies aren’t going to make the effort.
Maintaining legacy knowledge has its costs as well as benefits. I recall a news article from years ago about a government study (probably GAO or CBO) on how data acquired from early space probes is inaccessable. The investigators found old, poorly stored magnetic reels that were unreadable because the tape drives no longer existed and no one seemed to know the telemetry encoding scheme. While newer missions returned much higher quality data, it could still be useful for some researchers to go back to 1960s Mariner data to compare with current measurements.
Large companies are run by accountants, lawyers and salesmen. They see the older engineers as highly paid dinosaurs, unable to adapt to the “new” world of engineering. The seasoned engineer is a target for dismissal, especially if he is covered by a expensive pension and medical benefits.
Naturally, non of these corporate managers actually have any experience in anything, but their MBA credentials make them masters of all.
Reminds me of Comarco in NYC. They fired a third shift operator (because he was black and they didn’t hide the fact.) Then they fired his boss. It just happened that these were the only two people that implemented a backup procedure.
Yep, a few months later they needed those (now unavailable) backups.
I know everyone here wants to talk up SpaceX by putting down the legacy aerospace companies, but this is absolutely false. Organizations have both a corporate culture and an institutional knowledge that is in addition to that of its employees.
There’s a reason why one contractor can design a jet fighter in 3-1/2 years for $5 billion when another can’t do it in ten years for $50 billion. Or why the same contractor can take a 7-man reusable capsule from contract award through PDR for $130 million when it takes the other guy $5.1 billion to get a 4-man expendable capsule to the same spot in the design cycle.
It’s not the people. Both contractors have hired from the same talent pool for the last 50 years, and each year hundreds of engineers transfer from one contractor to the other.
It’s the knowledge and culture of the two organizations.
To think otherwise would be to suggest that Elon Musk and Tom Mueller could accomplish just as much working for NASA as SpaceX.
Would SpaceX have their culture if not for Musk and Mueller?
Ah but it is the people. Elon and Tom would probably not accomplish the same in NASA because other people would neither give them the budget nor allow them to work as they wanted to. This is why quite often large companies have small dedicated teams working outside their normal operating mode. i.e. LM Skunk Works and the ilk.
That’s not really what they call “institutional knowledge”. That involves stuff like hierarchy and “what’s the first thing you ask when…” sort of things. For instance, I work in a shop that is traditionally a Java shop, but we’re doing more and more with PHP-based systems like Drupal or Magento. When setting up a new project, our senior developers (like me) immediately set up a code-controlled project with a build tool, and it has wreaked havoc with the way our new-hires that are PHP developers develop code. It’s been a major learning experience for all of us.
Another example is a client I’m working for right now. They have one developer in the marketing department that is in charge of collecting analytics on their email campaigns. We are replacing their email system, so we have to work with their analytics system. We were working with the email team during our requirements gathering and didn’t know he was involved. He doesn’t share a supervisor with them for about 3 levels above all their heads. When our system didn’t allow him to gather the data he needed, he was able to halt the whole project because he didn’t know who read his reports, so it’s been difficult to get permission to short-cut that one metric for a few weeks until we get the situation sorted out. There are too many people that can fire him for not gathering the data that don’t made decisions based on that data. For important decisions that shouldn’t be easily malleable (“Should we launch the shuttle when it’s this cold out?”), that kind of inflexibility is exactly what you want.
So, there are some kinds of “institutional learning” that work much better than document repositories (which I also implemented for many years) and libraries of studies.