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.
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?
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.
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...
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...
Isn't that the margin for error? I want to go up in a ship that's a little better than the absolute minimum.
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
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...
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.
> #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).
I'm going to agilely build a space craft! /S
This rings true in politics as well.
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’m not sure the early Apollo astronauts would agree.
[0] https://web.archive.org/web/20230522164734im_/https://cdn.ge...
Same for software!!!
As an engineer gone PM, this is one of my favorites.
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.
Virgil wrote the Aeneid by following this rule!
It's just the right combo of truth and comedy.
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.
