In a sense, having low resources can be seen as a good thing. You don’t end investing a huge amount of effort into some architecture, approach or solution, which proves to be a dog, but which you can’t then get rid of since you have so much money sunk into it, people doing it as a job or it has otherwise started a life and advocacy of its own. These effects can be seen in relatively small projects already, but get worse as projects grow.
Organizations (nowadays companies) like Armadillo Aerospace have done tremendously fast advances, then dumped a lot of them to the wayside (tip propelled rotors, high grade peroxide, mixed monoprop, preburners, etc etc) and seemingly repeatedly started from scratch. John Carmack said this in April:
We have built and flown so many different vehicles now that I don’t even count, but lessons are learned from each one.
What they have learned also is a process of developing new stuff. They have not learned one solution. They have learned finding solutions in general.
The whole existence of Carmack’s personal wealth has been one enabling factor behind this. No bucks, no Buck Rogers. But at the same time, since the team has been small enough and probably mostly centrally controlled in the main directions, they have been able to do quick decisions and moves. If Carmack is the leader and controls most of the money (and in the earlier days controlled it all, as, as far as I know, Armadillo Aerospace didn’t have any sources of income), there is less possibility of factions forming wanting to keep carrying on doing something when the leader decides it’s time to do something else. It is very much simpler decision making.
I have witnessed at times, in organizations, sports, or companies how a leader can make a huge difference, by just picking what to do. It doesn’t matter that much if it’s alternative a, b or c, just that one alternative is picked and everyone believes and accepts it as good enough, and starts working on it.
In the fast moving computer game technology world, where id software has been in the leading edge for about a decade and a half, John Carmack learned quick result making early on in his career when doing cover disk games for magazines. Absolute deadlines were set by the regular magazine publishing intervals.
So, what do we have as good examples from following Armadillo?
- Taking results oriented approaches from other avenues where they have been successful
- Having small teams
- Being unafraid to ditch old solutions and to take new approaches
- Having consistent funding
I don’t have a good view inside the Armadillo world. It is clear, by watching what they have done and listening to their people, that they have a lot of talented folks there and a good culture. It is certainly not a one man show. They have a lot of good approaches, like trying to train at least two persons for every rocket operations job.
So, had a bigger group been involved in a government operation with similar aims, with much more money, would the routes taken have been the same? Would it have been possible to ditch so many technologies in search for a better one? Would progress have been much faster?
I don’t really know. It might be that it could have been much slower in some ways.
In a sense, there is an optimum size for developing technology. You want to keep it small so it is fast to develop and failures are not too costly, so you actually are not afraid to risk hardware. You can do many many iterations with small and simple hardware in the time it takes to build a full size prototype. Why did DC-X have to be so big? When it crashed, there was no other vehicle ready by because all the money had gone to the one, expensive prototype.
So, taking my words somewhat back from the earlier fed up commentary, maybe it is good for the future of rocketry and RLV:s that the teams making the most advances at the moment are small and not very well funded. They actually make *more* progress that way! (If they are not absolutely starved.)
Turbopumps and real first stages can come later. Right now we are still basic operations development where even stuff like tanking has to be developed to work easily and reliably, nevermind more advanced problems landing.
Good pumps and real performance will come later, when it’s time for that. It’s not yet time for them, although of course it’s smart to keep developing them in the labs and on test stands. Just not worth risking them in flight when so much lessons can be learned with the pressure fed “trainers”.
P.S. This blog turned one year today. Total visitor amount slightly below 10,000, and it’s been rising. Thanks to all the readers, linkers, commenters and other people, and thanks to the friendly, smart, visionary and open Newspace community! It’s been exhilarating being a part of all this so far.
Happy Birthday Gravity Loss Blog!
I agree somewhat with your overall take, but I’m a little conflicted on one of your points. I think that while being able to do so is good, actually *having to* ditch everything and start all over again can sometimes be a result of less-than adequate analysis up-front. Of course, we’ve ended up changing a lot at Masten as we’ve gone along as well (going from distributed computing to more centralized, planning to go from large numbers of single-axis engines to a smaller number of deeper-throttling dual-axis engines, going with an in-sourced GN&C system instead of outsourcing it, etc). You have to be able to learn from past experience if you want to get anywhere.
So, I guess I’m just saying that one has to be careful with that point. I think the balance between analysis and trial-and-error should probably be much closer to Armadillo than DC-X, but having to change directions constantly can slow progress down a lot.
I fully agree with the other points though, especially point number 4. Especially if you have payroll to meet, funding crunches can really slow things down.
Big thanks, Jon. You’re one of the great nice friendly visible guys in the whole community.
One big thing about practically all avenues is that negative results are not often reported and are not appreciated as much as they should be.
Maybe if you had gone for central control at first and then had the idea of distributing it much later – that would lead in total to much more problems. It’s good that you discovered it with a small vehicle and small motors.
You live and learn. And you *must* learn. That includes trying a lot of things that don’t work very well. You learn not only not to do those things again (at least not in the same way), but also more general stuff. (Just don’t overlearn / get traumatized.) 🙂
So all good to you. It’s funny how you have seemed to have good engines early on but now many guys have been doing pretty good tethered tests with very simple engines. That doesn’t mean they are ahead of you in total. Just that you’ve explored different paths. Once you get your vehicles flying, I assume they could have very good performance…or wherever else your engines and expertise may end up also. That I don’t know myself, and those are business secrets, right? 🙂