AM Stereo

Having been generally interested in space exploration for many years, when a friend of mine suggested a road trip to go to the X-Prize Cup, how could I turn it down? Six of us went and had a blast at the competition itself talking to the various groups and watching the competitions going on, including Armadillo‘s heartbreaking third try at the Lunar Lander Challenge.  Even after the failures, though, the guys with Armadillo were very approachable and willing to chat about what worked, what didn’t, and how they had gotten this far.  While I think next year they’ll definitely nail at least the first level challenge and quite possibly the second, they’ll more than likely have some serious competition (they were the only ones trying this year).

One of the things that I found really interesting about Armadillo’s approach is how they’ve adapted several of the principles of Agile software development to building a rocket vehicle — their development process is characterized by multiple short iterations, heavily emphasizes testing, and focuses on a process where in each iteration you attempt to get some piece of incremental functionality working before moving on to the next. In a software project, these would be unit and integration tests and would result in working applications… here, it’s static engine firings and tethered test flights, and it’s more than likely to result in the first winner of the Lunar Lander challenge.
So why hasn’t this been done before, and how did they accomplish in months and hundreds of thousands what took NASA years and millions?
I think it’s entirely due to the cost of change.  A critical way in which software development differs from most traditional forms of engineering is the cost of revising your design.  No structural engineer would consider completely revising what the framework of a building looks like when it was halfway done, but this is something that often happens (for better or worse)  in software projects.  The whole concept of agility and refactoring is enabled by the fact that the cost of implementing a change can be as low as recompiling and re-running the test suite — and agile methodologies take advantage of that to “embrace change”, and believe that by slowly developing the design as you build, instead of attempting to get everything right up-front (before you’ve even started developing), that you can take advantage of lessons learned along the way.

The problem in adapting agile methodologies to traditional engineering is that in most cases you can’t afford to take your half-built building, tear it down, and rebuild it in a new manner. It’s just too expensive, both in terms of materials and in time.  With smaller projects, however, ones that are cheaper and take less time, you can afford to do this — as any shade-tree mechanic or Sunday carpenter knows, sometimes you get halfway into a project and realize there’s a better way.  When NASA built Gemini and Apollo, everything was hugely expensive.  Many if not most parts were being custom-developed and some of the materials were either completely new
or being used in completely new ways (although not Velco, that’d been invented shortly after WW2). The cost of changing the design was huge.  Team Armadillo, on the other hand, can take advantage of the huge advances in miniaturization and cost that have been made in the past 40 years. Many of their items are either low-cost and home-built, or are simple off-the-shelf parts (like the ‘brain’ of the system, a commercially-available PC104 board running Linux). The fact that they can quickly and cheaply replace parts when they break, or can even redesign (to a certain degree) entire systems means that their cost of change is low.

With a low cost of change, agile practices become practical, and I believe that being able to take advantage of that tight feedback loop — Try, Test, Fix — had a lot to do with Armadillo’s success so far. And, after all, I want them and others to succeed — they’re getting me closer to my vacation on the moon!

Read Full Post »