Minimum Viable Answer
Two weeks ago, I was giving a lecture at the International Space Development Conference. There was a full day of programming related to the Space Elevator, and I was the wrap-up speaker. I gave my introductory talk on the Lunar Space Elevator Infrastructure. I’ve been thinking about that talk, since then, because something was different that time. I had a minor epiphany.
The audience was pretty typical. There were about 50-60 people, from a variety of technical and non-technical backgrounds. Notably there were several PhDs, but as is usual in a National Space Society public forum, the majority were non-technical space-hobbyists. I particularly like this kind of audience for a couple reasons:
During the long Q & A period – in an hour talk, my ratio is usually 20 minutes of prepared lecture, and 40 minutes of responding to audience questions – I delivered my well-worn reply: “we don’t even have all the questions, yet, let alone have all the answers…”
And that line got me to thinking about the kinds of answers we are beginning to develop. Because it is true, we are still developing the comprehensive list of questions, issues, and concerns which need to be addressed before we can build our Elevator on the Moon.
We are also beginning to generate ‘answers’ to some of the issues we’ve identified. But what kind of answers are they?
This project is a non-stop balancing act of trade-offs. If we spend X amount of money we can buy Y number of rockets/string/robots, and achieve Z results. Each Z result impacts and influences all the other variables and an ‘answer’ in one problem will inevitably impact all the other related problems.
In keeping with our Three Mandates (1. Single Launch Solution, 2. Current Technology, 3) Sputnik-like Simplicity) we are aiming for the simplest possible answer to the question – ‘how do we build an Elevator on the Moon?’ We don’t need feature-creep, or mission-creep. We don’t need to add complexity to what is arguably the most complicated system every designed. We don’t need the costs associated with add-on features. We do need a system which will work; a system which will survive its infancy and grow over time. And so, with ‘Sputnik-like Simplicity” in mind, I’m going with a new rule – Minimum Viable Answer. This is the answer which will ‘work’. It’s not the ‘best’, and it might not even be a ‘good’ answer. It’s merely ‘good enough’. That might mean that there are several preliminary answers which are ‘good enough’ – and which will plug into our models/simulations. And maybe ‘good enough’ will evolve into ‘good’ as we refine things. It is unlikely that we will ever get to a ‘best’ answer, because of the complexity of the trade-space.
So thanks, Silicon Valley. While I might loath your “minimum viable product” model, you did give me the language and the philosophy to develop this Occam’s Razor-esque tool for developing answers.
President, LiftPort Group
Your comment will be posted after it is approved.
Leave a Reply.