Are you solving a NASA problem or a LEGO problem?
nateberkopec.com
nateberkopec.com
When I look at company like Dropbox, I don't really see a lego problem since building the infrastructure for what they are doing isn't easy. But it's not stopping people from competing with them as this article claims it would.
It's sad, because whatever exceeded customer expectations today (so that they think it's incredible, magic, they can't believe it, how did you do that man) won't work tomorrow, when their pesky expectations have habituated to it. "New" is intrinsically time-sensitive. What have you done lately?
Here's Joel essay Where there's muck, there's brass http://www.joelonsoftware.com/items/2007/12/06.html
Burt Rutan used to build small scale models of his concept planes and mount them to the roof of his car to test their aerodynamics. Last time I checked he managed to turn that "Lego" project into a manned space vehicle.
It would have been better to give us some idea of WHY we need to know what scale of problems we're solving, and what kind of problems we'll have if we don't know.
Solving a problem can be a lot easier the second time—what had been a tortuously long and painful process for you is often significantly easier for a competitor who had the benefit of watching.
You'll also also have this issue if you're the first to solve an easy problem, but I believe it's less exaggerated.
Think medical devices vs iphone apps. Problems in the medical field are not secret. But they typically require a novel solution, five or more years and a team of experts to implement. Potential competitors may well know exactly what you're doing but they'll have to overcome barriers on multiple levels: time, funds, patents (a big one), expertise, etc.
Another is that people in startups are delusional in thinking they are solving difficult problems. Maybe, but they are taking risks and it seems innocuous and may be even helpful to be slightly delusional on that point.
Finally the metaphor of a moon mission is telling. Landing on the moon, was hard, but it didn't create a sustainable business around space flight. In fact by some measures space flight went backward for some time. In the 90's I was at Draper Laboratories and remember a literal rocket scientist saying it would take more than 10 years to put a man on the moon again. (He was saying this while complaining about milspec components.)
I believe that if businesses focused more on customer service and solving one or two key problems really well, then they'll have a higher likelihood of succeeding.
Source?
But my comment wasn't even meant to highlight NASA's historically documented failures. Instead it was meant to illustrate what kind of project properties are not appropriate for software projects. I was making a statment to the effect that it should be considered a big warning sign if projects are structured like the space shuttle program.
On a final offtopic note about commenting style: you're complaining about deserving more than a witty one-word answer, yet you have no problem with making comments that consist of a passive-aggressive one-word question, do you? Let's keep it friendly, even if we disagree.
The only good argument is the direct one: it's something we want to do and something we should do for its own reasons and merits. Personally I believe that to be the strongest argument and also a perfectly adequate argument.
Now that the problem has been 'solved' by the pioneers, the follow-on players have it relatively easy.
Like being able to run multiple things on your computer without having the less-important tasks block more important tasks? Thank the Apollo computers.
The topic is taking a run at the perennial arguments about monolithic vs. incremental development and ad-hoc vs. recyclable solutions - but NASA isn't really a great whipping boy for this one.
Edit: Also offtopic, but I feel compelled to answer this:
[..] NASA tends to have a thousand little tidbits that
end up getting reused over and over.
I would go even further than that and assert that we shouldn't be aligning science and space exploration with the derivation of practical applications in mind at all. It should be done regardless. I'm not one of these "let's concentrate on terrestrial problems first" Earth-isolationists. Quite the opposite: my criticism of NASA is that there has been too little actual science and exploration.http://www.danshapiro.com/blog/2011/07/a-twitter-a-hoverboar...
It isn't about the competitors, it's about who come first with a viable solution.
PS: You not a scientist, you are not NASA, you will never be, you will never have the need to develop anything close to a space rocket in your life. And if you do, don't start a startup for god sake, do something more valuable to the human kind, please use you knowledge for much more important things.
I admire the notion, but I actually think the scale of the problem is irrelevant. There are some really "small" problems (that are hard, but could be solved by one person), throughout mathematics and computer science that could have profound impacts.
Hm, I think I need to go back to the drawing board with this post. There's something good here but I didn't quite get it across.
Also, his numbers seem to be off, both for years and number of missions.
Source: http://www.infoplease.com/year/1966.html http://en.wikipedia.org/wiki/Budget_of_NASA
And I feel you are downplaying the societal impact that going to the moon had on not just the US but the world. Without forgetting the technological advancement that had to be made to make it possible.