Akin’s Laws of Spacecraft Design
spacecraft.ssl.umd.eduI have a subset of these printed out and tacked to a cork board in my office, and I refer to this website a few times a year. Very, very good stuff.
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.
> 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.
> Engineers always wind up designing the vehicle to look like the initial artist's concept.
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...
>29. (von Tiesenhausen's Law of Program Management) To get an accurate estimate of final program requirements, multiply the initial time estimates by pi...
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.
When you have your own kids you'll discover that the secret rule is that it takes 2 kids at least twice as long as it will take their dad (for a variety of reasons; experience, distractions, lack of focus, etc.). 3 kids even longer. A corollary is, "The more people in your group at dinner time at an event, the less likely you'll actually eat that night". ;)
A friend used to say “take your estimate, double it, and add 50%.” It’s almost weird that “3x” seems to just be the universal rule.
The later half of the rule also scales the estimate up by an order of magnitude, would imply tasks taking 30x longer. Guess that makes you quite optimal at those tasks.
I think you've misread it, though this is my first time encountering these laws so do correct me. It says to multiply the time by 3x and the costs by 10x
I understood it as:
better_time = estimated_time * 3; better_cost = estimated_cost * 10;I missed that - this makes more sense
For what it's worth, I also missed it the first time around. It's worded a little strangely if you're going through them quickly.
That's for the cost estimate, not time.
Maybe it should be e actually? At least I'd pattern-match e into such a relationship.
> Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
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...
>(Atkin's Law of Demonstrations) When the hardware is working perfectly, the really important visitors don't show up.
As an engineer gone PM, this is one of my favorites.
This is definitely the wisdom of ages, but some points do show some age.
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.
Err, what? Keyword there: "New".
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
> And when they were new, well, lots of delays and setbacks and costs as they kept accidentallying rockets trying to land them.
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.
If I recall correctly they had their experience of them blowing up on the go up part, but that is old history now
Well yeah almost everybody does on their first attempts. NASA tends to be an exception, but making sure you don't blow up the first time turns out to be way slower than just trying to launch and seeing what goes wrong.
I'm agreeing with the adage in question (#'s 39 in OP) that designing any new rocket is going to be difficult or expensive, and if viable, it's better to use an existing. You acknowledge as much later in this thread:
> 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 guess I'm misunderstanding how SpaceX follows #39 in the form of "Whatever you do, don't develop any new launch vehicles," since SpaceX developed the Falcon 1, Falcon 9, Falcon Heavy, and is now working on Starship. There's probably been no point in their history when they weren't working on their next launch vehicle. Sure it's difficult, but just saying it's difficult is not the same as "whatever you do, don't do it."
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.
> The whole point of these two adages is that reusing an existing design is better than a new one.
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...
None of this is put in doubt though. Your points about SpaceX's potential for future cost savings and efficiencies are hardly realized today - particularly when considering the length of time that has been spent without a capable manned vehicle. If, fast forward a decade or two and SpaceX is still using today's designs (albeit, upgraded) and actually realized massive savings - then we can talk. However, I'd bet they're going to re-design and build brand new models along the way...
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
> There's a reason military aircraft tend to have extreme service lives.
Only during peacetime. During war (hot or cold) they often have a rather short service life before becoming obsolete.
The “No new launch vehicles” adage reads to me as “Don’t develop a new browser when you make a website”
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.
I take it as similar to the “never do a massive rewrite” rule for coding. It’s not that it never should be done, it’s that it shouldn’t ever be assumed to be “the easy part”.
> I don't know how good definition can exclude reusable rockets from being new
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.
No understanding :) .
> In software it's rather clear
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.
I don't think that's the case, or all of the case.
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 completely agree with you insofaras parts of the design probably go back to NT. SBut some of the design won’t happen until next week. My interpretation of this is that the design process starts before use and continues until the end of the support lifecycle. I agree that there are some components that we think have been completely designed… but there might be a bug tomorrow in a “core” part of the OS that would require more design, and I don’t think this would surprise anyone if it happened.
I’m not saying necessarily that it’s continuous design, simply that we might return to the design phase at any time.
Let's put this comment in the comment cellar for a few years, to fully develop the tannins, and then see how it has aged. Starship progress is a little ways away from proving this adage wrong.
It could be argued that Dragon has already proven this wrong. Falcon 9 was developed in the form it was specifically to launch Dragon. SpaceX's original next rocket was going to be a Falcon 5 until they got the Dragon contract from NASA. Yes, the original Dragon was a cargo vehicle rather than a human spaceflight vehicle, but both Falcon 9 and Dragon were developed with the intention of eventually human rating.
Both were late, and I wouldn't say that Falcon was built expressly for humans. It spent a decade proving itself before it flew with people. That's not a _new_ launch vehicle.
> Both were late
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.
> What was the "determined" date to have them ready? How do you know they were late? Judging by Elon's estimates?
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.
Congress didn't pay SpaceX the agreed upon amounts for the first 3 years of the contract, and Crew Dragon was 3 years late. Coincidence?
If a manned spaceflight program proceeded to its first flight on time, the universe might just implode.
>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.
Could you imagine if NASA mandated that SpaceX be the launch platform for Boeing's capsule?
A decade is a short period of time by human-rated-spaceflight standards.
I mean… yes and no. The Apollo program started in 1961, had the first manned flight in 1968, and landed on the moon in 1969. Gemini started in 1961 and had two people in ‘65. Don’t get me wrong, I’m perpetually impressed by the things SpaceX is doing, but don’t let the fact that the rest of the industry has slowed down significantly convince you that SpaceX is moving faster than anyone ever has before.
For what it's worth, the Apollo program only had one bespoke launch vehicle, the Saturn V. Mercury used the Redstone (for sub-orbital flights) and Atlas, and Gemini the Titan, all of which were developed as ballistic missile platforms.
And that's kind of the point of the rule :).
>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.
Not counting Saturn-I AND Saturn-IB?
So? Falcon wasn't a human spaceflight program during that time, and it was also over-schedule and over-budget anyway.
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"
> 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.
>Starship progress is a little ways away from proving this adage wrong
Yeah, and will perennially be so
I think this comment is an artifact of its time, kind of like Knuth's "premature optimization" or Spolky's "never, ever rewrite from scratch". They are mostly valid under the circumstances the author uttered them, but by no means universally applicable, and certainly not to be turned into religious commandments.
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!
SpaceX never done a human space program, they are purely about making launch vehicles that, after they have seen substantial development, are taken into consideration by NASA for a human space program.
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.
> SpaceX never done a human space program, they are purely about making launch vehicles that, after they have seen substantial development, are taken into consideration by NASA for a human space program.
Crew Dragon is not a launch vehicle.
SpaceX is literally US's only domestic way to send humans to ISS right now
Falcon 9 (plus Dragon) is the definitive counterexample. The jury on Starship remains out.
Far from being a counterexample, Falcon 9 is a great example of the adage's truth. It flew for 10 years before being used for human missions.
Human-rating the then-new Falcon 9 launch vehicle was part of SpaceX’s award for Commercial Crew starting in 2011, and the launch vehicle did not delay the program, so I think it counts. Falcon 9 had flown twice when NASA made the initial award, it certainly wasn’t a proven launch vehicle and it’s easy to imagine it tanking the whole program if it went differently.
Flown twice is still pre-existing---the vehicle had been in development years before the award. If your point is that the Falcon was pre-existing and it still took a long time to get to crewed flight, that's true. But note that the adage doesn't say the launch vehicle is the only source of delay, only that it is generally the most significant one.
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.
Yep, they didn't develop a new booster or stage 2 for Crew Dragon. No new launch vehicle.
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.
I'd consider development of Crew Dragon to be rather fast - because, in the condition of a private development, it wasn't done before. Comparing to other spacecraft developments, in late 1950-s there was a race, USA vs. USSR, to put a man in space "soonest", and it took Soviets ~3.5 years from the launch of the Sputnik to send Gagarin to orbit. So, just a few short years... and a large government backing.
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.
Compare the budget of SpaceX to NASA's up to and through Mercury. NASA's experience was one of something never having been done before compared to the experience of SpaceX seeing many others doing it just needing to tweak the formula to make it affordable. Also, without NASA's burden of being a government pork/jobs program rather than being a streamlined process
You may underestimate the complexities and pace of development at SpaceX. And it can similarly be said that NASA's Mercury program was built on the shoulders of previous achievements in parachutes, heat shield, control etc. SpaceX does use the experience gained in the industry over half a century with a lot of efforts, but that doesn't mean they don't push the progress with their own work.
I think the difference between the “private” development of Dragon and the “government” development of Mercury is exaggerated.
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.
> 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.
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.
That's still going to be late and over-budget.
Late comparing to what? Maybe SpaceX will not make it ready for NASA's return to the Moon flights as it was planned. However those dates don't look too serious to me - what's the justification for them? I suspect they were specified fully understanding they can easily slip right.
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?
So, it's not late because the dates weren't serious to begin with?
Yes, there weren't a lot of "formal" dates so far with Starship, the agreement to use it for Artemis Moon landing is one of exceptions. No dates - not late.
You can't be behind schedule and over budget if you have neither a schedule nor a budget.
rollsafe.jpg
I don’t feel like a field that has in its entire history only produced a handful of actual successful designs at all can possibly rate this kind of ‘world weary cynicism’ style of writing.
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.
Setting the bar at "spacecraft that humans have ever flown in" seems very restrictive to what experience you count.
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.
"A handful of actual successful designs"? Perhaps we should get the definition clear: a spacecraft in this context is any human-built vehicle flying in space, not just those that carry humans. There are thousands of earth satellites, extra-terrestrial orbiters, landers, rovers, and now even interstellar spacecraft that are very successful. They all needed launch vehicles.
“If you screw up the engineering, somebody dies” does not apply to unmanned spacecraft. In fact, unmanned spacecraft generally operate further away from humans than anything else does. When they go wrong the last thing that’s likely to happen is a human getting hurt.
That’s the only thing on the list that applies specifically to human spaceflight. It certainly doesn’t invalidate my point.
What makes you think this is limited to human-rated spacecraft?
Hell, I work in unmanned small autonomous aircraft and almost all of these apply to my day-to-day.
The multiple references to human spaceflight?
As far as I can tell, only 1 out of the 45 laws (#45) potentially refers to human spaceflight.
Absolutely. A lot of back-patting and inside jokes about 40 years of building expensive space systems that often failed. Self-aggrandizing crap about how “space is hard”. Space was hard in the 60s when you had to invent microprocessors to get off the ground. It’s well understood and should be common and cheap now (at least for Earth orbiting systems). This old boys club nonsense might feel fun but space is changing, access is becoming easy, and anyone that tries to spend 10 years and a billion dollars on a project won’t last long.
Most of these are not "do it this way because it works", but "don't do this, because it doesn't work".
It’s written from a human spaceflight point of view for sure. Old space was (sometimes still is) extremely analysis heavy because everything was too expensive to have it not work. This is the environment in which NASA developed its culture.
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.
Yup. It especially rubs the wrong way for the last point, #45.
> 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.
>So, shouldn't something like cars get this level of diligence then?
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.
There was a joke running round the European car manufacturers a couple of decades ago that the European Space Agency literally couldn't hire rocket scientists because they'd all been poached to work on drive-by-wire systems. I don't know how true it actually was, but the point is that in a lot of cases it's not just going to be the same standards, it's literally the same individuals.
I think satellites count?
> 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'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...
> There are exactly nine spacecraft that humans have ever flown in. Only the Mercury/Gemini/Apollo programs really accumulated any kind of experience
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 secret to success: work hard. Who said it? Albert Einstein.
Hi. I'm Henshaw of Rule 37. AMA.
Well, you can tell us about the event/project that led you to coin that rule and how it panned out...
It's been long enough that my memories are fuzzy, but I believe it was this:
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.
Thanks for the clear line of blame.
Rule 46. They can ask you anything, but you don't have to answer.
What's a line of blame?
I took it to mean clearly delineated responsibilities (i.e. who gets blamed when a part / aspect doesn't work).
If there are unclear boundaries between responsibilities, things will fall through the gaps when one group assumes another will take care of something.
Furthermore, when people are held responsible for quality completion of a task, they are often more driven to achieve the task at-quality. This must be balanced with not over-taxing them, but that's a given.
Correct!
I take it to mean when blame is being aimed you are not in the line of fire.
interesting - I understand it differently, namely as in:
"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.
Blame is just another word for responsibility. If you don’t have clear lines of blame you don’t have clear responsibilities.
think org chart. now put your cynical hat on.
Ah, so now we know who to blame for making this list so long. Success won't escape us this time.
What work are you doing these days?
I'm the lead roboticist on this:
https://www.darpa.mil/program/robotic-servicing-of-geosynchr...
What's the backstory, was there a situation where you were the blamee (or the blamer?)
Who doesn't love grapplers?
> 33. (Patton's Law of Program Planning) A good plan violently executed now is better than a perfect plan next week.
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.
> 8. In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point.
This rings true in politics as well.
Isn't a Pareto optimal solution always at the edge of the feasible space?
Yet, it is usually in middel of the repsective dimensions, not on the extreme ends of either.
More succinctly stated as "Only the Sith deal in absolutes."
> 3. Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time.
I'm going to agilely build a space craft! /S
It's the only way a spacecraft has ever really been built!
Gotta test it one way or another. I love it to be honest because it makes the waterfall boomers seethe.
Funny thing is SpaceX is known for applying Agile to its aerospace engineering workflows. Boeing etc. are much slower because they use waterfall.
Oh, I'm pretty sure someone(s) manages a massive GANTT chart over on the SpaceX side.
I knew #36 and have used it in the context of software engineering. But much of the rest is similarly applicable.
> #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.
Good rules, despite the page background choice going against rule 20: "...A good design with a bad presentation is doomed immediately..."
> #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.
how is this rule meaningful beyond platitude?
"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 you've misunderstood the quote. The solution that the great engineer produces is effective, but may not be efficient nor elegant if it doesn't need to be. The point is that solving the problem (and maybe stopping there) is more important than producing something that is fast or beautiful that doesn't solve the problem.
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.
I take this progression to mean that the novice will design a part or subsystem that is good by itself. The more experienced engineer is thinking bigger by taking into account the effect of the larger design on the portion they are working on. The great engineer is thinking holistically and so also considers how the part affects the whole design.
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).
Number 13. Design is based on requirements. There's no justification for designing something one bit "better" than the requirements dictate.
Isn't that the margin for error? I want to go up in a ship that's a little better than the absolute minimum.
Good requirements include margins. In aerospace it's common to see[1] a system requirement that says "...shall supply a peak current of 1.0A for 1.0s", a general requirement somewhere else that says "...power supplies used for the purpose of X shall be designed to a margin of 1.5 for current and a margin of 2.0 for time", and a child of both that says "...shall supply a peak current of 1.5A for 2.0s, including margins".
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
A 1.5 factor of safety in aerospace? Outrageous. I’ll give you 1.1 and I’m being generous!
I’m kidding…
Then specify that in the requirements.
Requirements set constraints which guide the development process. Without them set early on, you risk not understanding completely what you're setting out to do, you risk differing expectations/assumptions between members of your team, and you risk creep as the project goes on which means you will diverge from your intended outcome.
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
Margin of error should be calculated at the design stage, not as an afterthought during implementation.
This is the only one I have reservations about. It is also part of the engineer's job to understand the customer, understand what they need, and negotiate the requirements (within reason). It's hard (impossible?) for the customer to fully design exactly what they need, and it works much better to the engineers to build something with continuous customer input than to build rigidly to a spec sheet
>and it works much better to the engineers to build something with continuous customer input than to build rigidly to a spec sheet
Continuous input is a tried and true method of blowing out both budgets and timelines on building anything physical.. hardware, rockets, chemical plants, etc.
Working at a hardware company with a software company founder (which I’ve done multiple times now) can be a frustrating experience. People used to being able to casually say “hey I want to add this new feature” and getting “$40,000 and 12-week shipping delay” as a response are generally not happy. One project I worked on shipped board v2.17; the requirements were changing so quickly that we often needed to do significant board redesigns before we’d even sent the current design to the prototyping shop. It was… fun.
You're describing the (albeit quite common) situation where requirements were not conclusive enough and need to be revised throughout lifetime of development, which can be natural as you begin to understand the problem space as you work within it. But the key is that the requirements should be as conclusive and accurate to resolving your problem as they possibly can be, at any given point in time.
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.
Except that requirements cost time to develop, so perfect requirements have significantly more cost than good enough requirements.
Also, requirements tend to evolve as customers grow, so requirements will change over time and become less perfect, causing that investment to depreciate.
I agree completely. In the physical goods world, though, it’s not a continuous function. At points along the way, there is a very clear cost step response. Requirements evolving is totally fine and expected, but you need to periodically say “The current set is good enough, let’s build it and ship it”. Trying to do continuous delivery on manufactured items is the road to madness.
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.
I love when you guys do that. Then when I'm hacking around w/ your machine, I can get ahold of those spare pads :)
>There's no justification for designing something one bit "better" than the requirements dictate.
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
The rovers likely are completely on spec but simply because of all of their redundancies and tolerances designed as they are, they exceeded on-paper minimum expectations.
The specs were decreased so that "success" was extremely likely, because failure is career ending.
at this point though, if I was on a team that made a $newShinyToy for a space mission that did not "over perform" like this, I would personally feel shame and have a sense of failure if it only performed to the papers and end of mission came exactly when the paper said.
I wouldn’t go quite that far. Generally speaking aerospace margins are there for two reasons:
- 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.
> 35. (de Saint-Exupery's Law of Design) A designer knows that they have achieved perfection not when there is nothing left to add, but when there is nothing left to take away.
Virgil wrote the Aeneid by following this rule!
> 41. There's never enough time to do it right, but somehow, there's always enough time to do it over
Same for software!!!
Most of them apply to software as well
I think that most of those points applies for most science and engineering projects, not merely spacecraft design. As many wise set of rules, a lot of rules contradict each others, so that it is universal and intemporal.
Love this, it pops up on HN every few years.
It's just the right combo of truth and comedy.
By the way, since you need to apply thrust from any direction to maneuver flexibly in 3D space (without wind or gravity), wouldn't spherical/disc(saucer) shaped spacecraft be the most efficient?
> By the way, since you need to apply thrust from any direction to maneuver flexibly in 3D space (without wind or gravity), wouldn't spherical/disc(saucer) shaped spacecraft be the most efficient?
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.
Only if instantaneous large accelerations in arbitrary directions is amongst your primary performance requirements. You'd need to have thrusters ready to fire in arbitrary directions as well. A spherical (specifically) spacecraft would also have more heat dissipation challenges.
No. Such a craft would either need to have full thrust engines pointing in every possible direction (way too costly and overbuilt) or would have to have some way of rotating its full thrust engines to be at any arbitrary angle relative to the ship (which then means you have to transfer all the thrust through gimbal mounts or whatever you're using to be able to rotate the engines, and those things won't be able to withstand that kind of stress). It's much easier and simpler to point your full thrust engines in one direction (out the back of the ship), so the thrust gets transferred through the entire ship's fixed structure, and then have smaller thrusters to rotate the ship to point in the direction you want to go.
The space between things in space is quite large, so you're going in a single direction for a while. The thrust from the spacecraft is also used to exploit gravitational energy (slingshoting around planets) for the most part, from my understanding.
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.
Plus, without deflector shield voodoo, a skinny tube design minimize your cross sectional area and how much debris you will impact.
I think one of the most interesting things about space flight is how inflexibly your maneuvering actually is compared to how it’s portrayed in TV and film. As an example, in a given orbital altitude you cannot really speed up or slow down without changing your altitude. You can’t really move side to side at all without completely changing your orbital trajectory.
There are 1,000 other requirements that do not demand maximum 3D rotation efficiency.
> Design is based on requirements. There's no justification for designing something one bit "better" than the requirements dictate.
I’m not sure the early Apollo astronauts would agree.
The phrase associated with Apollo was, "waste anything but time." Achieving arbitrarily high levels of quality takes time, for pretty much any process. Those F1 engines were mostly handmade, which you can see among other places in the imperfect machining of this F1 injector plate[0]. The attitude at NASA towards risk was not "avoid it at all costs": what they were doing was inherently risky. NASA's goal is to manage risk.
[0] https://web.archive.org/web/20230522164734im_/https://cdn.ge...
If you need a spacecraft better than the requirements state than the requirements are shit and need to be redone. For example every human rated spacecraft after Apollo 1 should have a door which opens outwards, an interior atmosphere composed of mostly nitrogen and some oxygen, be comprised of flame retardant materials and have adequate fire suppression systems.
Hi Doc! I read all the way through this and almost didn't recognize it was you. What a great piece, and what a great response you got here!
In Shute Norway's autobiography, Slide Rule, he describes the design and construction of the [R100](https://en.m.wikipedia.org/wiki/R100), an airship of which he was one of the leading engineers.
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.