Akin’s Laws of Spacecraft Design(spacecraft.ssl.umd.edu) |
Akin’s Laws of Spacecraft Design(spacecraft.ssl.umd.edu) |
This one in particular was a big influence on me when I moved from engineering to design. It expressed what I'd felt but hadn't put into words. Not just the look, but nearly every aspect of a project is de facto path dependent, so you want to be as far upstream as possible. It's also why I volunteer to write a lot of documents I'm not strictly responsible for:
> 30. (von Tiesenhausen's Law of Engineering Design) If you want to have a maximum effect on the design of a new engineering system, learn to draw. Engineers always wind up designing the vehicle to look like the initial artist's concept.
This is a key truth that works in a number of contexts. If you want to make sure the new security policy won't break your workflows, offer to write the first draft. If you want to ensure the new automation system will work for your team's requirements - offer to chair the requirements meetings.
Humans are lazy, though some of them move around a lot in an attempt to mask this. If you get in early and set the parameters of an enterprise, you influence every iteration of that enterprise until its dying day.
This was illustrated in the movie "Galaxy Quest". The aliens saw the humans' TV show about space exploration, and designed a ship that exactly matched the fictional ship depicted. But they never saw a bathroom on the show, so they had to make up their own design...
I discovered this when my father would come up with some project me and my siblings had to do, such as scrape, sand, prime and paint the house (which thinking back very likely had lead paint).
It would inevitably take roughly 3 times longer than he wanted it to take. And of course being an adult he'd throw a tantrum about it.
better_time = estimated_time * 3;
better_cost = estimated_cost * 10;https://en.wikipedia.org/wiki/Hofstadter%27s_law
Hofstadter suggested doubling the scalar and incrementing the units by one. 3 hours -> 6 days, 2 weeks -> 4 months, etc...
As an engineer gone PM, this is one of my favorites.
39. (alternate formulation) The three keys to keeping a new human space
program affordable and on schedule:
1) No new launch vehicles.
2) No new launch vehicles.
3) Whatever you do, don't develop any new launch vehicles.
Nobody has the experience or ability to be able to say ‘trust me I’ve built a few spaceships, this is the hard won truth of how it is’. There are exactly nine spacecraft that humans have ever flown in. Only the Mercury/Gemini/Apollo programs really accumulated any kind of experience and that experience was extremely specific to a particular place and time and organization.
So sure, some general engineering truisms in here have the ring of wisdom to them and us non-spacecraft engineers can nod at them and quote them with the cachet they get from being associated with NASA.
But ‘trust me I have been teaching people to design spacecraft for decades’ doesn’t really count for much when during those decades no new spacecraft designs were actually getting made and launched.
The project was highly successful from an R&D perspective, but it never flew in space for a variety of reasons. SOme of those were related to a lack of funding and/or national commitment to spacecraft servicing, and some were due to us not executin the program as expeditiously as we probably should have.
If there are unclear boundaries between responsibilities, things will fall through the gaps when one group assumes another will take care of something.
https://www.darpa.mil/program/robotic-servicing-of-geosynchr...
Ah yes, unfortunately it's only halfway through the execution that you realize it wasn't a good plan, wasn't even an okay plan but a straight up terrible one.
This rings true in politics as well.
I'm going to agilely build a space craft! /S
> #36 Any run-of-the-mill engineer can design something which is elegant. A good engineer designs systems to be efficient. A great engineer designs them to be effective.
Make it work (elegant). Make it right (effective). Make it fast (efficient).
Also with a hint of law 40.
"boss, I have finished the task. But this time, I activated great engineer mode, hence the result is not only elegant, but efficient and effective."
I think there's some overlap with:
> 13. Design is based on requirements. There's no justification for designing something one bit "better" than the requirements dictate.
The same thing applies, I think, to anyone who works on a team. The beginner thinks of the problem by itself. The more experienced member thinks of how the system will influence what they are building or doing. The senior member will think about how the thing they are doing/building will in turn affect the whole (and weigh the consequences).
Isn't that the margin for error? I want to go up in a ship that's a little better than the absolute minimum.
Virgil wrote the Aeneid by following this rule!
Same for software!!!
It's just the right combo of truth and comedy.
I’m not sure the early Apollo astronauts would agree.
[0] https://web.archive.org/web/20230522164734im_/https://cdn.ge...
The R100 design was "competing" with the design for the R101; both design teams were simultaneously tasked with constructing a viable airship to make a long-range trip (in the case of R100, crossing the Atlantic in 78 hours, which was a remarkable achievement for the time). The difference was that the R101 project was state-owned whereas the R100 was privately-owned.
R101 crashed and burned in France, en route to India on 5th of October, 1930, likely due to structural issues damaging the airships gasbags, of which the only survivors were those lucky enough to be in the engine cars.
In the autobiography, Norway describes how the difference in program management led to the disaster. There are a lot of factors that led to the crash, as you might imagine, but one of the points he makes is that the publically-owned project was not held to strict requirements in its design process. The privately-owned R101 had a strict contract that they needed to complete, with a tight budget to complete it. They had constraints. Whereas the public-sector project was allowed to continually revise their design as they went, making many successive rewrites and changes without much structure. In particular, they cut the ship in half and rebuilt it at one point in it's development. And when they arrived at the end of their development cycle, they had no leeway to maneuver because they had a lot of public money wrapped up in the project, along with a lot of public visibility and responsibility, pressuring them into rushing the launch without complete trust in their design, and into terrible weather conditions.
*13. Design is based on requirements. There's no justification for designing something one bit "better" than the requirements dictate.*
Decide/envision your outcome, and set your constraints correspondingly early on in development, aligned with realistic expectations of resources, folks.
To underline my point, here's a quote from the Wikipedia page.
"Shortly before R101's flights in June 1930, the Cardington [R101] engineers tentatively suggested that the long flights to Canada and India might be postponed until 1931 on the grounds that neither of the two airships was fit to make a lengthy flight at their current developmental stage. The R100 team replied that their airship was perfectly capable of flying to Canada, and that the Canadian flight was a part of their contract."
R101 did not have a contractual obligation to meet, but did not want to outright state they needed more time, lest admit defeat. R100 had requirements that they needed to meet, which they were ready to meet, as they had them written from the start in clear. R100 launched successfully. R101 was forced to launch to compete before it was ready, due to this "spontaneous requirement". R101 burned for it.
SpaceX still faces large costs and delays in developing new launch vehicles, including starship, which is delayed and unfinished btw, so no matter how you try to spin it, Starship is not (currently) a good example of SpaceX being an exception to the adage. Artermis 3 isn't exactly cheap afterall, and if you don't know what that is but know what Starship is, that proves the adage this one is refering to:
> 39[a]. Any exploration program which "just happens" to include a new launch vehicle is, de facto, a launch vehicle program.
The whole point of these two adages is that reusing an existing design is better than a new one. SpaceX's REUSABLE rockets are great for a number of reasons yes, but by definition, those are not NEW launch vehicles. And when they were new, well, lots of delays and setbacks and costs as they kept accidentallying rockets trying to land them. Not a slight against SpaceX btw, that's part of rocket science and innovation, but again, not cheap or quick.
If anything, SpaceX's entire business model is EMBRACING that adage, not disproving it or an exception to it.
EDIT: clarified
They were launching just fine, it's just the landings where they blew up.
This wasn't any sort of delay or major cost. Nobody else was landing rockets at all, they were just blowing them up intentionally. This is still the case today for all production orbital rockets other than SpaceX.
Yes, and that's put in doubt. Starship aims to improve on previous designs - in terms of affordability, that is, making human flights cheaper. This cheapness can't be realized with existing designs, so a new design becomes better in that regard.
> SpaceX's REUSABLE rockets are great for a number of reasons yes, but by definition, those are not NEW launch vehicles.
I don't know how good definition can exclude reusable rockets from being new. Was Shuttle ever new? Delta Clipper? Reusable Falcon-9? Falcon Heavy? I think this is not a good definition, if, according to it, reusable rockets can't be new.
> And when they were new, well, lots of delays and setbacks and costs as they kept accidentallying rockets trying to land them.
Do you know the difference between designing and using? In software it's rather clear, and nobody would expect a half-written program to function according to specs. Neither it's the case in aerospace - while Falcon reusability was being designed and tested, nobody should expect it to perform flawlessly as when used "in production". Not cheap, agree (actually, quite cheap by aerospace standards, but still not some typical household-sized money), but I'd argue that was rather quick - just a few years to put reusable first stage into production starting from announcing the idea and building the first "Grasshopper". So, while 39[a] may stand here, your comment doesn't provide a good justification to it.
> If anything, SpaceX's entire business model is EMBRACING that adage, not disproving it or an exception to it.
SpaceX benefited immensely from using proven solutions, but the results they are showing are still disproving the idea of this law. The ambitions of SpaceX are high compared to the rest of the world launching industry, but so are the results, and we also have genuine "firsts", like putting the reusable first stage into production, or flying reusable spacecrafts to space station, TKSes and Shuttles notwithstanding.
Let me try to explain again my main point: SpaceX aims to make human spaceflight significantly cheaper, and the opinion is that it can't be done without radical redesign from scratch. It was attempted several times in the past, with e.g. Shuttle and Energiya, and it still isn't done today, but if you want to risk being put on the "you're currently here" list of SpaceX achievements(1), which were doubted and then happened, I'd at least propose you to think from the basic assumptions and find out why SpaceX won't actually achieve cheaper human spaceflight this time.
(1) In Russian that list looked like this before reusable Falcon: https://meduza.io/impro/0ZWeCgCXA4nsWv7dj7CHbSIrsURgOh-qpiUh...
Yeah, and will perennially be so
P.S. any engineer who counters my request to take perf into consideration with "premature optimization is the root of all evil" is immediately asked to complete the remainder of the quote. Failing to do so usually results in me ejecting the person from the meeting!
Furthermore, Starship is not a launch vehicle in the context of Artemis, it is to be used as a lander. The launcher that will launch humans is still SLS (which fits point 39 perfectly).
And SpaceX never was on schedule. Starship development is seriously impressive, but the planned first launch for "BFR" was 2022, and we only got an expectedly failed test flight in 2023. We have absolutely no idea about when it will launch its first payload. Probably not before 2024. The first manned mission (which is not a full manned launch) is planned for 2025 (2 manned launches originally planned for 2024), and is extremely unlikely to make it by that time.
Still excellent by space standards, but doesn't contradict point 39.
Crew Dragon is not a launch vehicle.
Still, given that Crew Dragon was developed by a private company and is quite modern judging by performance, I think it's a good result.
Over-budget - what's the planned budget? I suspect Elon Musk himself doesn't have pre-approved specific budget to develop Starship, which makes sense, as e.g. it's rather hard to pinpont. As for the overall idea for how much Starship development would cost - how do you know it's missed already or going to be missed?
That'd be like saying no one can talk about websites in the same way because we probably only have at the most 9-ish "successful" social media services. The list also mentions many things that are learned from non-human space flight programs, or non-successful programs.
Is everything in it true? Probably not. But from an outsider perspective it seems to contain some insights that most definitely are. I think of it sorta like https://www.stilldrinking.org/programming-sucks is for devs. Cynical humor that contains a lot insights.
The newspace paradigm is downstream of costs coming way down. Now you can afford to iterate a few times - it’s much faster and you learn more by flying and testing against nature instead of recreating the environment perfectly on the ground and refining your analysis to the n’th degree. In this world, a good number of these laws are dated and miss the mark.
The old way is still more true in human spaceflight, because there are people on board. But even there, humans are now passengers with computer pilots, so you can do unmanned test missions that chip away at the old delays.
> If you screw up the engineering, somebody dies
So, shouldn't something like cars get this level of diligence then? Coal-fired power plants maybe? Nursing home care??? Spaceflight deaths, even on a log scale graph, don't even make it on the chart vs any of those others.
It's far more about the perceptional impact to the program as a whole, if someone dies, many billions will have been wasted and many thousands will lose their jobs.
Still, it's fun and I've used it for a decade now. I really like #41.
> 41. There's never enough time to do it right, but somehow, there's always enough time to do it over.
Never mind that it's in direct contradiction to some of the other laws. I still love it.
They do. At least the, "engineering of the vehicle itself and then manufacturing it" part.
A lot of Aerospace designing, testing, and manufacturing is built off the foundation the automotive world laid down. Heck, one of the key standards, the SAE standard, is called such because it literally stands for Society of Automotive Engineers.
Cars may be involved in a lot of deaths every year. But rarely do people die because their car spontaneously combusted/fell apart while someone drove it.
That's an excellent point. Not until Space-X started launching Falcon-9 boosters was there a significant US advance since the Space Shuttle, for which design began in 1969. The Russians are still launching Soyuz. China has been developing and flying new boosters, and is now flying the Long March 7 and 8, with the Long March 9 in development. NASA, though...
From the "classic" era:
Mercury: 6 crewed flights. [1]
Gemini: 10 crewed flights. [2]
Apollo: 15 crewed flights (including Skylab and Apollo-Soyuz missions). [3][4][5]
Vostok: 6 crewed flights. [6]
Soyuz: 147 crewed missions (and counting). [7]
There have been four generations of Soyuz [8], so it's unclear whether it should be counted as one, four (or more?) spacecraft types. That doesn't include China's derivative,
Shenzhou: 11 crewed flights. [9]
Moving on to modern times, we have
STS: 135 crewed flights (counting orbital only). [10]
Dragon 2: 10 crewed flights and counting. [11]
Counting Apollo's LEM but not different Soyuz generations as a separate spacecraft gets us to 9, but out of those, it's STS and Soyuz which stand out as having accumulated most experience.
And all that's ignoring space stations, which arguably are spacecraft too and easily account for the bulk of time spent in space by humans [12][13]:
Salyut: 6 orbited, 34 crewed visits.
Skylab: 1 orbited, 3 crewed visits.
Mir: 1 orbited, 39 crewed visits.
Tiangong: 3 orbited, 10 crewed visits.
ISS: 1 orbited, 88 crewed visits.
[1] https://en.wikipedia.org/wiki/Project_Mercury#Crewed
[2] https://en.wikipedia.org/wiki/Project_Gemini#Missions
[3] https://en.wikipedia.org/wiki/List_of_Apollo_missions
[4] https://en.wikipedia.org/wiki/Skylab#Mission_designations
[5] https://en.wikipedia.org/wiki/Apollo%E2%80%93Soyuz
[6] https://en.wikipedia.org/wiki/Vostok_programme#Crewed_flight...
[7] https://en.wikipedia.org/wiki/List_of_Soyuz_missions
[8] https://en.wikipedia.org/wiki/Soyuz_(spacecraft)#Variants
[9] https://en.wikipedia.org/wiki/Shenzhou_(spacecraft)#Launch_r...
[10] https://en.wikipedia.org/wiki/List_of_Space_Shuttle_missions...
[11] https://en.wikipedia.org/wiki/SpaceX_Dragon_2#Crew_Dragon_fl...
[12] https://en.wikipedia.org/wiki/List_of_space_stations
[13] https://en.wikipedia.org/wiki/List_of_spaceflight_records#Du...
That being said, I work in aerospace and if a company aims to meet the above requirements but maximimize or minimize some aspect, e.g. make a light/cheap/competitive product, how do you do that? There's always a few engineers that will die on the hill of "but there is no requirement for mass of this particular component" or "you said I should minimize mass but that's not a real requirement" (many organizations reject anything but "shall requirements" when it comes to formal review). TBC or TBD values can be used, but then it's difficult for everyone to understand if the value is a target or just something to be updated later. On the other hand, there's always a few engineers who will happily work for an extra year to optimize something way too much.
Sometimes a requirement is flat-out incompatible with another requirement, too. Requirements are so important but they are just a tool, and also sometimes require iteration. Number 38 goes in the right direction, but I would personally want to add "46. Sometimes requirements are wrong".
[1] These are simplified examples
I’m kidding…
In any project, resources (time, money, etc) are limited so the most successful project will be one that uses resources most efficiently. So good explicit requirements allow you to determine the most efficient manner to achieve them as they codeify the problem and give you goalposts to optimize within.
This all relies on you being able to set good requirements from the outset, which can be done by understanding what you're setting out to achieve (the problem you're trying to solve).
I have a comment in this thread which discusses the consequences of this rule specifically. https://news.ycombinator.com/item?id=37069168
Continuous input is a tried and true method of blowing out both budgets and timelines on building anything physical.. hardware, rockets, chemical plants, etc.
In the "frictionless environment, ideal world" scenario - requirements should always be completed as close to the letter as possible and no further.
In the practical scenario, requirements should be written as close to perfect as can be achieved where perfect is defined as what is necessary to resolve your problem space, limited by your understanding of the problem space.
Are the Martian rovers outliers to this rule?
>I want to go up in a ship that's a little better than the absolute minimum.
This makes me think of the "this was built by the lowest bidding contractor" quote
Definitely not. There's very little need to 'maneuver flexibly in 3D space'. You are mostly interested in rotation. A slight amount of translation if you are trying to dock with something else.
You will likely still prefer to thrust mostly in a 'forward' (wherever forward is) direction. If, for some weird reason, you wanted to have thrusters equally powerful in all directions, just imagine the amount of weight (and plumbing) this would require.
In Sci-fi, it's generally understood that very fast crafts (0.1c and up) will need to reverse and apply thrust opposite their direction to slow down for a very large part of the voyage (up to more than half) - so could be a good idea to be able to flip around and apply thrust the other way too.
"at a project's beginning, define rules such as 'if component X explodes, it is team ABC's fault'".
context:
> 37. (Henshaw's Law) One key to success in a mission is establishing clear lines of blame.
> Well yeah almost everybody does on their first attempts.
The above poster I was responding to was saying the opposite. I was asserting that that's not true, that SpaceX is embracing the adage of not only "Don't reinvent the wheel" but "Hell, let's reuse the wheel".
Also, just because someone has the foresight to budget extra time and money for the inevitable failures/complications of an initial prototype, doesn't mean there weren't extra cost or time involved in the development of that product than if it had worked reliably like a mature, proven design would.
SpaceX has been killing it. I'm not criticizing. I'm just acknowledging these are some VERY basic tenants of engineering and product design PERIOD, no matter if you're making a stapler or a death star.
I do think maybe NASA shouldn't develop any more launch vehicles, but I'm sure glad SpaceX is doing it and so are a bunch of newer companies.
A better counterexample would be a crewed program that developed its own launch vehicle and still completed on time and within budget. If you treat the Falcon 9's development time as part of the overall project (which you should if you're maintaining it's a new vehicle per the adage), then you're looking at something like 15 years just to get a crew to orbit. Which is consistent with the rule.
Starship is likely to be similar. Super-Heavy (the launch portion of the combined vehicle) isn't likely to be scrapped for the crew version after the cargo Starship is ready.
rollsafe.jpg
- To try to compensate for the worst-case situations
- To try to compensate for the unknown-unknowns
If you made a Mars rover that experienced a worst-case re-entry burn, got blown off-course during landing by larger-than-ever-measured surface winds, had your solar panel etched by dust in said surface winds, and completed 89 of the 90 day mission, you should still very much feel like you’ve succeeded AND you’ve provided incredibly valuable input data for the next iteration. We then refine our mental model of the Martian atmospheric conditions and revise the worst-case scenario specs for next time.
Like Dragon, the Mercury capsule was (mostly) designed and (entirely) built by a private contractor, McDonnell Aircraft.
Like Mercury, Dragon was designed and built with input and strict oversight from NASA, including a contingent permanently on-site with the contractor. NASA always had total visibility and the final say on everything.
There are some important differences in the contracting models of the two programs, but a lot of the “private”/“commercial” framing of the ISS crew/cargo programs is just leftover vibes from the 2000s when ”harnessing the dynamic private sector” was the way to frame a new program that you wanted to get funded.
I think that's not a contradiction to the Dragon being designed by a private company in a different, organizationally, way than Mercury was designed by a private company.
Also, requirements tend to evolve as customers grow, so requirements will change over time and become less perfect, causing that investment to depreciate.
My general approach to this is to try to reasonably anticipate things that could be coming down the pipe and, if possible, do the bare minimum to cheaply support the next prototype. As an example, if the product has a GPS receiver and a microcontroller and could conceivably need to do dual-receiver down the road, I’ll have a quick look for spare Tx/Rx pins on the microcontroller and just route those out to blank pads. Two benefits:
- when product management asks, we have a way to build a prototype using existing parts
- if there aren’t any spare pins to break out like that, I can raise it as a potential design red flag early. It’s not necessarily a show stopper, but it contributes situational awareness for when the next big step cost might show up down the road.
What was the "determined" date to have them ready? How do you know they were late? Judging by Elon's estimates?
> I wouldn't say that Falcon was built expressly for humans
You know of course that requirements for the rocket to launch people are different from the rocket to launch only cargo? There were cases when non-human-rated rocket became human rated (at least Proton), but these days it's better to plan ahead, like teams working on Arian-5 (and also Dream Chaser, not a rocket) do. I'd assume Flacon-9 developed from the beginning in such a way so at least human-rating would be possible - if not built-in already.
> It spent a decade proving itself before it flew with people. That's not a _new_ launch vehicle.
I'd agree regarding Falcon-9. Starship is another story.
Crew Dragon was approximately 3 years late, from the original planned launch date of 2017 to the actual date of 2020. Given that the contract for the missions were awarded in 2014, it's a miracle that things have proceeded at the pace they have.
> You know of course that requirements for the rocket to launch people are different from the rocket to launch only cargo?
I'm well aware of the differences. I work in this industry. That said, SpaceX made the wise decision to cut their teeth and prove their design on cargo first. That's not a new launch vehicle by definition. They were launching rockets regularly for years before they put people on the pointy end. Most other human-rated rockets in recent history have _only_ launched humans. I'm neglecting older, converted ICBMs like Redstone and Titan. The only standout from this list is probably Soyuz (the R-7 derivative launch vehicle), which has been kept going through sheer inertia.
> I'd agree regarding Falcon-9. Starship is another story.
I suspect that Starship will be years behind schedule before it even launches cargo. I suspect that it will miss NASA's planned lunar landing date, but it won't be at fault because other parts of the program will suffer even worse schedule slips. I understand that people are hopeful that this really will revolutionize spaceflight, and I count myself in that group too! Reality has a way of intruding eventually though. I want SpaceX to build, fly, and trash as many unmanned Starships as it takes to make it reliable. That will cause some level of delay because they'll find something new in the testflights that will necessitate a redesign before it kills someone.
The advice isn't "no new launch vehicles should ever be invented ever", it's "if you want your human spaceflight program to be on time and on budget, don't include a new launch vehicle in the plan"
And that advice is being questioned. Starship aims at cost reduction which can't reasonably be achieved by incremental improvements to the status quo.
The "on time" part with Starship is what was formally promised to NASA with the Moon landing vehicle. This may - probably will - slip, but I currently doubt it will slip a lot. Other times regarding Starship are in the realm of estimates or wishful statements. The "on budget" part is something which I doubt even SpaceX accountants may answer - just as software engineers have troubles answering the time - and therefore budget - of a system to be delivered.
The law shows its age. On the other hand, it never claimed to be an absolute truth.
There's a reason military aircraft tend to have extreme service lives. It's far cheaper and effective to upgrade and refit/improve existing airframes with modern technology than it is to start from scratch - every single time.
Look at the F-35 program. It's not exactly fair because the design goals are vastly different - but upgrading aging F-15's has kept them on the battlefield for 47 years[1], and today they're still a seriously potent air superiority fighter. The F-15's of today are only similar in shape to the originals, however.
[1] https://en.wikipedia.org/wiki/McDonnell_Douglas_F-15_Eagle
Only during peacetime. During war (hot or cold) they often have a rather short service life before becoming obsolete.
That doesn’t mean we never need or want a new browser. It just means that developing a browser is a separate project and if your fancy websites requires a new browser, it is in fact a browser development project, not a website project.
Because you're hung up on trying to tell me that the concept of reusable rockets is new in a grand history since while I'm trying to convey to you that the original Falcon 9 reusable rockets development ended over a decade ago.
> Do you know the difference between designing and using
You're the one struggling with that concept and the semantics around it, because you yet again prove my point while trying to argue it.
> SpaceX benefited immensely from using proven solutions
I'm glad you agree with the core point of my idea. Weird that you're so combative about it.
> Let me try to explain again my main point:
Don't bother, you missed the point of my comment entirely. Have a nice day.
In software, I perceive there to be almost no separation whatsoever between design and use. I’m using windows 11 right now, and sometime in the next few days it will silently download software patches that were designed over the last few days to address situations not considered in the original design of windows 11. Software goes back and forth from the design process to active use pretty much continuously these days.
Just an alternate perspective to think about.
Windows might download patches and update components but the core OS design, is there for over 15 or more years, and ditto for most of the userland, when it doesn't go back to Windows NT times..
I’m not saying necessarily that it’s continuous design, simply that we might return to the design phase at any time.
Could you imagine if NASA mandated that SpaceX be the launch platform for Boeing's capsule?
>39. (alternate formulation) The three keys to keeping a new human space program affordable and on schedule:
> 1) No new launch vehicles.
> 2) No new launch vehicles.
> 3) Whatever you do, don't develop any new launch vehicles.
Given that SpaceX wanted to make a more affordable launch vehicle, they obviously needed to design one. But it certainly didn't make their human space flight programme go faster compared to past endeavours.
