Transporting the CIA A-12 Blackbird to Area 51

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.

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

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

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.

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.

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.

> 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.

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

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.

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.

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...

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

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.

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.

Or alternately, to have built them in Area 51.

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.