[OT]: How to succeed in a pioneering enterprise The title is mine. I thought some may appreciate this advice from someone who SHOULD know what they are talking about. The advice relates to how to build rockets that will take people to orbit BUT it is written by John Carmack, a man who has already "made his fortune" as one of the founders of ID Software (Doom and family) and MAY translate into electronic entrepreneurial activities.. John is now attempting to do the above while still not quitting his day job. I believe he has budgeted $US1M for this project AND hopes to make money from it AND expects to have 3 people flying to 100 km within the next few years. So far he has unmanned "rocket-ships" flying round the ID Software car-park under better control than almost anything rocket powered I've heard of. Makes making a revolutionary PIC project sound like a doddle :-) RM _____________________________________________________________ At 09:16 PM 7/11/2002 -0500, you wrote: >For John Carmack and many others: > >How does one go about setting up a development program for a complex >task like getting to orbit? I know about how things work (or don't, >often as not) in the commercial and government sector (I work for a >major aerospace manufacturer), but entrepreneurial aerospace is almost >an oxymoron. > >Where do you begin ? > >Don McCorvey >Houston, Tx While I currently theorize that many of the things that led to my success in software can also be moved to aerospace, the point is certainly open to contention without an existence proof, so you might want to weight the advice from people on the list with "real" entrepreneurial aerospace companies a little heavier. I have the enviable freedom to say "I'm not going to make any money off of this for at least three years", which allows me to focus on the goals, rather than little things like paying the rent... I am a bad person to ask about how to raise money, because I have bootstrapped my way up without having to ever borrow money or court investors. Still, I do have a thing or two to say about complex development projects that I feel have some general relevance. There is a huge benefit to keeping a project's scope small enough so that at least one person can have all of it available in their head. This limit will vary from person to person, but at some point, complexity gets to the point where specialization and compartmentalization is necessary. If at all possible, you want to stay below this point! The ability to do global, system wide thinking and optimization is what is going to enable dramatic, rather than incremental, improvements in the status quo. An "improvement" that complicates the design may push you into a local optimum that prevents you from reaching a more global optimum. I do think that even orbital vehicles can be made simple enough to be kept in one person's head. As someone else said, "just do it" is damn good advice. Lots of people spend all their time looking for a silver bullet that will make the hard things easy, and when it turns out that there isn't one, they have absolutely nothing to show for it. Want to go to space? Build a rocket. Then, build a better one. Repeat until in orbit. :-) I'm almost completely serious -- building a few generations of HPR rockets with an eye on the engineering is a better step than writing an AIAA paper. Always be aware of the critical path and the field of options. If you are working on something that isn't on the critical path, be prepared to justify why you aren't working on a critical path item. Take personal responsibility for the progress, or lack thereof, of the entire project. Groups can easily fall into "he was supposed to do that" sort of problems. It is best to lead by example, rather than by fiat. I wanted to expand on some of those points, but, well, I have to follow my own advice, and do some work on the Armadillo project... John Carmack -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.