I 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.
>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.
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.
Recent SpaceX developments, Starship in particular, put some doubts on this one.
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.
> 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.
> 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 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 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".
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).
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
> 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.
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.
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.
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.
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.
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.
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.
[+] [-] karaterobot|2 years ago|reply
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.
[+] [-] Modified3019|2 years ago|reply
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.
[+] [-] c_o_n_v_e_x|2 years ago|reply
As an engineer gone PM, this is one of my favorites.
[+] [-] avmich|2 years ago|reply
[+] [-] jameshart|2 years ago|reply
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.
[+] [-] SahAssar|2 years ago|reply
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.
[+] [-] themadturk|2 years ago|reply
[+] [-] visviva|2 years ago|reply
[+] [-] GlenTheMachine|2 years ago|reply
[+] [-] aredox|2 years ago|reply
[+] [-] mmaunder|2 years ago|reply
[+] [-] throwawaylinux|2 years ago|reply
[+] [-] xNeil|2 years ago|reply
[+] [-] moffkalast|2 years ago|reply
[+] [-] carabiner|2 years ago|reply
[+] [-] Rebelgecko|2 years ago|reply
[+] [-] starkparker|2 years ago|reply
[+] [-] moffkalast|2 years ago|reply
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.
[+] [-] AnimalMuppet|2 years ago|reply
This rings true in politics as well.
[+] [-] pdhborges|2 years ago|reply
[+] [-] firewolf34|2 years ago|reply
[+] [-] freitzkriesler2|2 years ago|reply
I'm going to agilely build a space craft! /S
[+] [-] datadrivenangel|2 years ago|reply
[+] [-] carabiner|2 years ago|reply
[+] [-] filiph|2 years ago|reply
> #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.
[+] [-] JoeAltmaier|2 years ago|reply
Isn't that the margin for error? I want to go up in a ship that's a little better than the absolute minimum.
[+] [-] johnwalkr|2 years ago|reply
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
[+] [-] rahimnathwani|2 years ago|reply
[+] [-] firewolf34|2 years ago|reply
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
[+] [-] imoreno|2 years ago|reply
[+] [-] whats_a_quasar|2 years ago|reply
[+] [-] dylan604|2 years ago|reply
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
[+] [-] chasil|2 years ago|reply
Virgil wrote the Aeneid by following this rule!
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] edu|2 years ago|reply
Same for software!!!
[+] [-] 2rsf|2 years ago|reply
[+] [-] marmakoide|2 years ago|reply
[+] [-] iancmceachern|2 years ago|reply
It's just the right combo of truth and comedy.
[+] [-] Razengan|2 years ago|reply
[+] [-] outworlder|2 years ago|reply
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.
[+] [-] icegreentea2|2 years ago|reply
[+] [-] pdonis|2 years ago|reply
[+] [-] dmbche|2 years ago|reply
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.
[+] [-] tonyarkles|2 years ago|reply
[+] [-] carabiner|2 years ago|reply
[+] [-] tw04|2 years ago|reply
I’m not sure the early Apollo astronauts would agree.
[+] [-] sethrin|2 years ago|reply
[0] https://web.archive.org/web/20230522164734im_/https://cdn.ge...
[+] [-] Shawnj2|2 years ago|reply
[+] [-] BubbleRings|2 years ago|reply
[+] [-] firewolf34|2 years ago|reply
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.