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?
If software engineering were more like civil engineering we'd spend a lot more time formally proving our algorithms before we implemented them.
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.
We have much smaller budgets, and our budget sizes are not classified.
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 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.
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...
So that would've been counterproductive.
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.
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.
(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.)
I remember seeing a nice writeup of what that move involved, but cannot find it anymore.
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.
http://framework.latimes.com/2012/10/15/time-lapse-video-spa...
