Transporting the CIA A-12 Blackbird to Area 51

http://www.roadrunnersinternationale.com/transporting_the_a-12.html?m=8

by jmonegro • 13 years ago

215 34 13 years ago

cstross• 13 years ago

The A-12 wasn't a bloody bomber!

(It was the single-seat predecessor version of the SR-71 Blackbird. While interceptor and bomber versions were proposed, only 3 prototype YF-12A interceptors were built; the bomber variant was a paper study. The A-12 itself was definitively unarmed, being a pure reconnaissance aircraft.)

jnazario• 13 years ago

to this point, given that eisenhower was pushing his open skies initiative, it was vital to ensure that the aircraft used in recon were distinguished from armed aircraft, lest they get shot down (or we think the soviets were invading, if they had taken up eisenhower on his offer under open skies). other considerations - space, weight, aerodynamics - are also key, but this policy angle is just as important.

philwelch• 13 years ago

People are probably confusing it with the abortive A-12 tactical naval bomber: http://en.m.wikipedia.org/wiki/McDonnell_Douglas_A-12_Avenge...

ck2• 13 years ago

Wouldn't it have been cheaper to build a runway there and fly them there?

LoganCale• 13 years ago

It was a heavily classified project, as evidenced by the enclosure to hide its shape. I don't think they would want to be flying it out of Burbank in plain view of everyone. Additionally, its first test flight occurred at Area 51, after this move, which is an ideal location for testing such things. Test flights near a city are probably not a good idea.

kpao• 13 years ago

I also doubt they would have long enough runways in Burbank to take off with that beast.

noonespecial• 13 years ago

All they have to do is issue a press release saying that it most definitely was not a UFO and the rest will take care of itself.

toomuchtodo• 13 years ago

Had this been a few years later, they could've transported it via helicopter:

http://en.wikipedia.org/wiki/Mil_Mi-12

dsl• 13 years ago

It was being moved to Nevada for test flights. They had a pretty good idea, but no evidence at that point, that it would even fly. Later "production" models were flown to the test site.

pcl• 13 years ago

Or alternately, to have built them in Area 51.

lolcraft• 13 years ago

A great part of the success of Skunk Works, or at least what I took it to be from Rich's book, was how coupled manufacture and design was done in the division. About a cardboard wall as separation, with design ideas and manufacturing troubleshooting going back and forth.

So that would've been counterproductive.

monokrome• 13 years ago

Is anyone else bothered by the fact that this site changes the color of all text on the page if you click any of it? O_O

Sniffnoy• 13 years ago

I certainly was. I could hardly read the page because of it; it was just too distracting.

MCompeau• 13 years ago

If you enjoyed this article, I highly recommend checking out the book Skunk Works by Ben R. Rich (director of Lockheed's Skunkworks). It covers the development of this aircraft and several others through some pretty gripping accounts of engineering during the Cold War.

SkyMarshal• 13 years ago

Definitely one of the best books about hacking I've ever read. Kelly Johnson and his team were the ultimate hardware hackers.

incision• 13 years ago

Absolutely.

Talk about working the bleeding edge of technology, they basically built something from the future - theirs and ours - by inventing what they needed along the way.

Skunk Works is an incredibly engaging book. I devoured it in a few days and genuinely look forward to re-reading eventually.

JunkDNA• 13 years ago

After seeing posts like this for a while I finally got around to reading the book this winter. Blew me away. If you're at all technically inclined and involved in engineering or science, read this book when you're feeling sorry for yourself and things aren't going your way. It will get your mind right.

I say that because many extraordinary things came from these incredibly smart but otherwise ordinary engineers. It reminds me of the quote from Steve Jobs about how once you realize all the stuff around you has been invented by people who are not that much smarter than you, it's very liberating.

I liked all the worrying and self-doubt that comes through in the book (especially since you know they pull most of it off eventually). There were daunting problems that they had to surmount one after another. They had to invent completely new ways of doing things: manufacturing, testing, materials, lubricants, etc... they were so far out in uncharted territory any one of those things could have been the end. But they pulled it all off not just once, but multiple times.

twistedpair• 13 years ago

I knew this was a long time ago, but I was surprised by the year on one of the photo's. They were testing that plane 51 years ago! And we have trouble getting a battery in an airplane these days. Sure makes it seem the rate of innovation in aviation has slowed way down.

tomarr• 13 years ago

I know a project manager tasked with moving one of the retired concordes from Heathrow to somewhere along the Thames for transport up to a museum in Scotland. This required removal of several traffic islands and signals temporarily (overnight), and was quite the logistical challenge, made for some cool pictures though!

Someone• 13 years ago

If you like such pictures, check out the pictures from moving "Bagger 288" (http://en.wikipedia.org/wiki/Bagger_288) over a mere 22 km in 2001 (https://www.google.nl/search?q=bagger+288+2001)

I remember seeing a nice writeup of what that move involved, but cannot find it anymore.

at-fates-hands• 13 years ago

Here's the story of Area 51 Nat Geo did a few years ago. I thought it was a pretty good documentary:

part 1 of 4: http://www.youtube.com/watch?v=jcJzDqxqmEc

It talks extensively about the A-12 project. I thought the most interesting part was how they shipped square parts in round boxes and round parts in square boxes to conceal what was inside.

Different time back then for sure.

randlet• 13 years ago

Cool article. In a similar vein, the time lapse video[1] of moving the shuttle Endeavour through LA to the California Science Center is wonderful!

[1] http://www.youtube.com/watch?v=JdqZyACCYZc

hrayr• 13 years ago

Reminds me of the recent move of Endeavour through the streets of LA. It was truly a magical sight to behold.

http://framework.latimes.com/2012/10/15/time-lapse-video-spa...

jordan0day• 13 years ago

I read this earlier today and have been thinking about it since then. This story seems like a great example of thinking hard but methodically about what you want to do. Then planning it out. Then just doing it.

Agile methodologies are really en vogue in software development right now, but this story, complete with its 100 foot long, 35 foot wide trailer seems to be very nearly the (literal?) antithesis of "agile".

Maybe I'm grasping at straws, maybe it really is a lot more complicated to build web sites or whatever we all do, but this story seems to illustrate a "waterfall" process, executed relatively successfully 50 years ago. Why then, are we so bad at it now?

sneak• 13 years ago

> but this story seems to illustrate a "waterfall" process, executed relatively successfully 50 years ago. Why then, are we so bad at it now?

We have much smaller budgets, and our budget sizes are not classified.

dfc• 13 years ago

Hthinking hard but methodically? As opposed to thinking hard and haphazardly about something?

learc83• 13 years ago

Mechanical and Civil engineering requires more up front design than software because of the physical processes involved (plus the consequences of mistakes are usually deadlier). There are more questions with definite yes or no answers in engineering, and engineering uses a more rigorous application of applied mathematics than software engineering.

If software engineering were more like civil engineering we'd spend a lot more time formally proving our algorithms before we implemented them.

joshAg• 13 years ago

There are quite a few projects that do formally prove the algorithm before its implementation, but most of them we don't have access to.

The closest we can easily see is the code JPL uses on their rovers and the associated C coding standard (http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf).

That, and the rest of NASA's software was pretty much done entirely using a waterfall approach.

gcv2• 13 years ago

1. Our customers almost never have such excellent and unchanging specs for us to work with.

2. There is no such thing as software "engineering". Engineering implies a degree of understanding of the processes involved which programming, a craft still in its infancy, has not yet evolved. As Alan Kay famously stated, programming does not have a fundamental building block comparable to an arch.

We have to wing it, every time, on every project. "Agile" is an attempt to add some structure to an inherently unstructrable process. NASA (cited in this thread) owes its relatively good software to good specs, rigorous testing, and letting its programmers go home at night than to following any particular methodology.

hnriot• 13 years ago

We have libc, besides the arch is probably a bad example for engineering. Maybe civil, but the wheel would seem like a better example of a fundamental engineering component.

I also think you are being disingenuous to software engineering. There's plenty of understanding of the process, 50 years of computer science counts for something.

NamTaf• 13 years ago

I've been giving this quite a bit of thought over the last few months as I've read more about agile development and trying to understand how some of its benefits could be applied to my job as a Mech Engineer.

I work, primarily, designing coal wagons for trains. Each wagon costs ~$200k and we have well north of 5000 almost-identical wagons of this sort in the fleet. As such, the up-front cost of design is incredible compared to developing software and changes to the design are incredibly inflexible compared to software.

If I want to modify something insignificant (even as small as bolting on something pre-fabricated), it takes at least 12 months to cover the entire fleet as the most minor scheduled maintenance cycle. Major modification work (e.g.: actually modifying the structure) becomes a $hundred-million, ~5 year affair.

A/B testing is a completely foreign concept not only because change is unwieldy but because individual wagons will not experience the exact same conditions (even if they're in the same train!). It's almost always impossible to control everything and vary only 1 condition.

In this and many other mechanical industries, you don't work 'agile'. You invest a lot of time and money up-front to get things right because the change cost is incredible. The whole thing is referred to as FEED [1] - Front-End Engineering Design.

The best analogy software guys might know is if you deploy a whole heap of disconnected embedded systems to difficult-to-reach locations. In this case, agile doesn't work. The quintessential example would be software on space systems e.g.: satellites, the shuttle, etc.

If you can get away with it, agile development brings a whole load of benefits. You can quickly iterate and test. You don't have to nail down your client with a specification then try to appease them when you inevitably tell them that it's too late to change stuff. Software is a great benefactor of this because duplication is literally a case of cloning software and spinning up another virtual machine. It's trivial to create a million identical copies where you can vary one specific factor and observe results over a statistically significant sample.

I don't think it's a case of agile being 'in vogue' rather than it being the better tool for the job of software development. Nor do I think it's a case of being 'bad' at waterfall approaches but rather spoiled by the luxuries that agile can bring - you don't truly commit to nailing down a scope exactly and sticking to it when it is common knowledge that change is so easy to execute.

Other industries can't afford these luxuries. Change costs heaps of time and money so you spend a great deal of pain on getting your client mentally prepared that once they press the go button, they are locked in. You have to really throw everything you have at getting it right the first time. One Kelly Johnson, of the same Skunk Works as the parent article, summed some of it up in his 14 rules of management [2] - well worth a read and note #10 in particular.

Unfortunately, I haven't yet really realised any great insights into how FEED-style design could benefit from lessons learned out of agile-style approaches. Maybe it's because I've not yet worked under the latter. It seems to me though that, perhaps as a result of how FEED works, it's a system that tends to attract oldschool, tried-and-true approaches rather than anything radical or new and that to me suggests that it's ripe for disruption and improvement.

[1] http://en.wikipedia.org/wiki/Front-end_loading

[2] http://en.wikipedia.org/wiki/Kelly_Johnson_%28engineer%29#Ke...

Transporting the CIA A-12 Blackbird to Area 51

Related Stories