Slashdot Mirror
X Prize and John Carmack
Anonymous Coward writes "ABC News is running a story ostensibly about the X Prize but in reality they only talk about John Carmack and his teams efforts to win the prize (or at least compete). Quote: 'Some people have commented that I am trying very hard to make aerospace like software, and that's the truth," he says. "If we looked at what we do in software, if we could only compile and test our program once a year, we'd never get anything done. But that's the mode of aerospace.' "
I read the internet for the articles.
While mass-producing a learjet probably doesn't cost much at all, building the first prototype probably cost many 10s of millions in development costs. If this team is building a prototype for $1-2 million and that includes all material, development and testing costs, I'm definitely not buying a house in its flight-path.
Yeah, there's a world of difference between buying a personal jet from a private company that must be flightworthy for dozens or hundreds of flights a year and comply with acres of FAA regulations before they even get off the ground. Not to mention the high markup on those jets.
These rockets are being built with more or less volunteer time and by people who are willing to scrounge for parts and look long and hard for bargains. I think you'd find that the raw materials that go into a Learjet aren't all that expensive (steel by the pound, etc...), but the labor costs, health plans, salespeople comissions, buildings, paperclips, etc... add considerably to the cost of the final product.
I read the internet for the articles.
Duh.
.sigs are for post^Hers.
The last time I checked, bottled water costs a whole lot more than water from the tap. And the markup is far more excessive than the cost of the plastic bottle. Brand name T-shirts may cost pennies to produce in a third-world country, but still will cost you $20 to purchase at the mall. Our world is full of inconsistencies.
"Right now, somewhere in this world, Scott Baio is plowing a woman he doesn't love," - Peter Griffin, *Family Guy*
I see alot of people pointing out buggy software releases but I don't think it's applicable.
Making software to run on a platform that can have almost unfathomable perumutations is not the same as writing software for one set of components.
-William Shatner can be neither created nor destroyed.
If you can afford to test your hardware as often as you can, do it. A test is worth a million analysis plots.
Making mistakes in a test environment is the best way to learn about your design and your own limitations.
Mode (3) smart-aleck mode. Press * to return to main menu.
If you know how, and count your time as "valueless," you can build a hang glider for. . . nothing.
You can build a sports car that rivals a Corvette and get it road certified for only a few grand, even though a new Corvette costs a damned sight more than that.
Most of the expense of doing things, even making video games, comes from doing things in a standard way inside of a standardize buearacratic system.
Throw out the red tape, open your mind to alternative ways of accomplishing the same goals, work for the joy of it and eliminate the market as motivator and you might surprised at how much you can accomplish with relatively little cash.
Watch a few episodes of Rough Science.
KFG
For spaceflight, we need people who think like the old school programmers. The ones that actually planned their programs before they wrote them. When it took twenty-four hours (or more) between when you submitted your card deck and when you got your output (or a core dump) you learned to be damned careful with your code. The modern attitude of "keep tweaking it until it compiles; we'll fix the bugs in 2.0" won't wash in spaceflight.
~Idarubicin
While I agree, that is funny, I do want to point something out. Software is NOT like the above statement. The software business is like the above statement. Real software is produced with a real process, including design, development and testing. It's just a sad state of affairs when most of the software industry doesn't even follow a minimal of best practises.
Since most people are more than happy to pay for complete crap, including bugs, being incomplete, and any number of other odd problems, there isn't any justification for people to want to change the software industry because people are not speaking with their dollar.
Just because software is buggy doesn't mean it has to be that way...it's just that too many people writing checks are far too stupid.
This will spur private research and investment in space technology. That's a good thing. We can't count on NASA to do it, they just don't have the budget to do much anymore.
Early development should be done by private groups since they're more flexible and agile. Then once a technology is established, larger bodies (NASA perhaps) could use their vast experience to manage/maintain. Despite the failings of NASA, they are still quite good at what they do. I doubt there are many other groups that can manage end-to-end some of the space applications that NASA does.
Of course, if the contest were to see who could make portable, inconspicuous nukes, that would be a different story.
.sigs are for post^Hers.
The tricky part is that I don't think tests done with small rockets will necessarily give you a good idea of how the big rocket will perform. If that were the case, all we'd really need is to buy a model rocket kit from Wal-Mart and just build it 20x bigger.
You call it a holy war, I call it English. The English language is being eroded gradually by ignorance.
There's a reason for having two words, then and than. It's preferrable to have exact words that aren't dependent upon context. If we just toss out "than", and exclusively use "then", our language will become even less precise.
Some other common mistakes that really suck:
confusing "your" with "you're"
confusing "their" with "they're"
adding unnecessary apostrophes to plural words - Dog's and Cat's...
Just because some people have forgotten or were never taught how to write the language they speak doesn't mean that we should just dumb it down completely. Taken to the extreme, we could just back all the way up to grunts and growls.
.sigs are for post^Hers.
Software developers have learned that the Waterfall model *doesn't work* because it's too slow, expensive, and inflexible. Sound like any space programs you know?
There is a continum between experimentation and analysis. So long as space is dominated by risk-averse govt. bureaucracies, your vision of space exploration will continue to slowly plod along. But remember when the real progress happened: in the 60s, when rockets blew up quite often. The consequence of a failed unmanned flight is only financial, and that means failure can be justified by overall savings.
You probably mean "Burt Rutan", the aircraft designer at Scaled. Dick Rutan is his brother, who piloted the voyager, and was the test pilot for XCOR's EZ-Rocket, but doesn't have anything to do with Space Ship One, the X-Prize vehicle.
I have always maintained that Burt is the odds-on favorite to win the X-Prize, but it isn't over yet. His design requires a pilot on board for all tests, so there is a non-negligable chance that there could be a fatality, which would almost certainly end the effort in the X-Prize timeframe.
John Carmack
In the early (pre-WW II) days of aviation, most of the innovations did not come from a large team spending years doing calculations, then building a single prototype that incorporated dozens of new ideas. Most advancments (such as leading edge slats, Fowler flaps, super-charged engines, etc.), were made in single small steps, often by a small team or single inventor.
Only later, once most of the kinks were worked out, did we get the famous "revolutionary" aircraft that incorporated several new features at once to produce major breakthroughs. By working out the bugs in his rocket systems one at time, through frequent iterations of design-build-test, Carmack is closer to the traditions of the "seat of the pants" engineers and flyers who started the aviation industry.
I once read an article by the famous race pilot and engineer Steve Whittman on how he tested a new wing tip design. To get the fastest results on whether it was better than his old design, he only built one new tip and installed on the left wing of his plane. As soon as he took off, the plane started yawing to the right, telling him that his new, larger wing tip had lower drag. sounds like Carmack has a similar mind-set...
Most historians think the Russian model of aerospace development was more successful than the American model. The Russians built fully functional rockets and did virtually no testing. That led to very fast improvements and now they're the only nation still launching humans into space. The Americans did incremental testing, only building full test flights in the final stages and you know where their human space flight ended up.
Aerospace problems are a lot harder than software problems, but unlike software, you can't share aerospace. You can't make a web page, have your achievements downloaded, and leave a lasting impression on people by building a rocket prototype. It ends up being done for yourself, isolated. Except for one or two blog articles no-one thinks about it.
I see a lot of skeptics replying, "Carmack is wrong headed, if you screw up a rocket, it crashes, it's not just a compile bug". Many of these comments seem to be suggesting that we should go back to the "old school" style of programmer that thought & planned his code before submitting, instead of relying on the feedback of a compiler.
This is based on the completely false assertion that code will be better / more bug free if you "think harder". It ignores that in the past 30 years of programming we have learned the value of feedback in the software development thought process.
The idea that somehow if I spend more time in a chair planning the solution that the solution will be better if I evolve my way to it is some sort of romantic vision of how solutions to tough problems are actually solved. This could be seen as a version the "prove the code works" vs. "test the code" debate. Or that proofs follow from the axioms. I counter that usually it's a process of some rather messy creativity, trial, and error.
In programming in the large, we have generally learned that "phased" approaches to software development (known as waterfall) tend not to work very well because they de-emphasize the feedback that occurs downstream in the development process. To contrast, an incremental approach enables smaller steps to be delivered , and minimizes the impact of erroneous assumptions discovered downstream in the development.
In programming in the small, development is a form of communication between the computer and the developer. The computer is designed to tell us where we are wrong, we just need to tell it exactly what to expect: for this we have compilers and test cases. Compilers can't catch everything.
Now, this is not suggesting that today's style of "let's see if it compiles!" development is appropriate for aerospace. That is the unfortunate effect of feedback & incremental approaches - it makes programming easier, even for people that shouldn't be doing it. These people "program by accident", and just meander through their code until it does the job, sort of. This is not a reflection of the incremental approach in the hands of an experienced developer that "programs on purpose", that understands what he or she is doing at every step of the way.
Aerospace development isn't "amateur hour", and the incremental approach will just make professionals all the more productive.
-Stu
Do you write an entire program before compiling it and testing it? Of course not, no one does. That's what J.C. is suggesting, that incremental development can be done in Aerospace.