16 ms·

Akin’s Laws of Spacecraft Design

317 points by filiph 3y ago

filiph 3y ago
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.
- Eduard 3y ago
  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."
  - dakr 3y ago
    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).
  - wmanley 3y ago
    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.
- belter 3y ago
  Good rules, despite the page background choice going against rule 20: "...A good design with a bad presentation is doomed immediately..."
- Archit3ch 3y ago
  > #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.
avmich 3y ago
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.
- idlewords 3y ago
  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.
  - bryanlarsen 3y ago
    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.
    - inamberclad 3y ago
      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.
      - avmich 3y ago
        > 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.
freitzkriesler2 3y ago
> 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
- datadrivenangel 3y ago
  It's the only way a spacecraft has ever really been built!
  - freitzkriesler2 3y ago
    Gotta test it one way or another. I love it to be honest because it makes the waterfall boomers seethe.
- carabiner 3y ago
  Funny thing is SpaceX is known for applying Agile to its aerospace engineering workflows. Boeing etc. are much slower because they use waterfall.
  - Balooga 3y ago
    Oh, I'm pretty sure someone(s) manages a massive GANTT chart over on the SpaceX side.
Razengan 3y ago
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?
- icegreentea2 3y ago
  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.
- carabiner 3y ago
  There are 1,000 other requirements that do not demand maximum 3D rotation efficiency.
- dmbche 3y ago
  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.
  - 0cf8612b2e1e 3y ago
    Plus, without deflector shield voodoo, a skinny tube design minimize your cross sectional area and how much debris you will impact.
- pdonis 3y ago
  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.
AnimalMuppet 3y ago
> 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.
- pdhborges 3y ago
  Isn't a Pareto optimal solution always at the edge of the feasible space?
  - lamchob 3y ago
    Yet, it is usually in middel of the repsective dimensions, not on the extreme ends of either.
- firewolf34 3y ago
  More succinctly stated as "Only the Sith deal in absolutes."
GlenTheMachine 3y ago
Hi. I'm Henshaw of Rule 37. AMA.
- carabiner 3y ago
  What work are you doing these days?
  - GlenTheMachine 3y ago
    I'm the lead roboticist on this: https://www.darpa.mil/program/robotic-servicing-of-geosynchronous-satellites https://www.darpa.mil/program/robotic-servicing-of-geosynchr...
- Rebelgecko 3y ago
  What's the backstory, was there a situation where you were the blamee (or the blamer?)
- xNeil 3y ago
  What's a line of blame?
  - e40 3y ago
    I take it to mean when blame is being aimed you are not in the line of fire.
    - Eduard 3y ago
      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.
      - bombcar 3y ago
        Blame is just another word for responsibility. If you don’t have clear lines of blame you don’t have clear responsibilities.
JoeAltmaier 3y ago
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.
- rahimnathwani 3y ago
  Then specify that in the requirements.
- imoreno 3y ago
  Margin of error should be calculated at the design stage, not as an afterthought during implementation.
- dylan604 3y ago
  >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
  - dclowd9901 3y ago
    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.
    - dylan604 3y ago
      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.
      - tonyarkles 3y ago
firewolf34 3y ago
In Shute Norway's autobiography, Slide Rule, he describes the design and construction of the [R100](https://en.m.wikipedia.org/wiki/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 3y ago
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.
- monkeydreams 3y ago
  > 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.
- midoridensha 3y ago
  > 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...
jameshart 3y ago
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.
- leashless 3y ago
  I think satellites count?
- SahAssar 3y ago
  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 https://www.stilldrinking.org/programming-sucks is for devs. Cynical humor that contains a lot insights.
- carabiner 3y ago
  The secret to success: work hard. Who said it? Albert Einstein.
- visviva 3y ago
  What makes you think this is limited to human-rated spacecraft?
moffkalast 3y ago
> 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.
iancmceachern 3y ago
Love this, it pops up on HN every few years. It's just the right combo of truth and comedy.
c_o_n_v_e_x 3y ago
>(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.
marmakoide 3y ago
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.
deleted 3y ago
[deleted]
Modified3019 3y ago
>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.
- roughly 3y ago
  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.
- bladewolf47 3y ago
  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.
  - Tuna-Fish 3y ago
    That's for the cost estimate, not time.
  - hibbelig 3y ago
    I understood it as: better_time = estimated_time * 3; better_cost = estimated_cost * 10;
    - bladewolf47 3y ago
      I missed that - this makes more sense
      - junon 3y ago
        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.
chasil 3y ago
> 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!
BubbleRings 3y ago
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!
tw04 3y ago
> 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.
- Shawnj2 3y ago
  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.
- sethrin 3y ago
  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.geekwire.com/wp-content/uploads/2015/11/151119-plate2-1240x823.jpg https://web.archive.org/web/20230522164734im_/https://cdn.ge...
edu 3y ago
> 41. There's never enough time to do it right, but somehow, there's always enough time to do it over Same for software!!!
- 2rsf 3y ago
  Most of them apply to software as well

317 points by filiph 3y ago

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.

Eduard 3y ago
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."
- dakr 3y ago
  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).
- wmanley 3y ago
  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.
belter 3y ago
Good rules, despite the page background choice going against rule 20: "...A good design with a bad presentation is doomed immediately..."
Archit3ch 3y ago
> #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.

avmich 3y ago

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.

idlewords 3y ago
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.
- bryanlarsen 3y ago
  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.
  - inamberclad 3y ago
    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.
    - avmich 3y ago
      > 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.

freitzkriesler2 3y ago

> 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

datadrivenangel 3y ago
It's the only way a spacecraft has ever really been built!
- freitzkriesler2 3y ago
  Gotta test it one way or another. I love it to be honest because it makes the waterfall boomers seethe.
carabiner 3y ago
Funny thing is SpaceX is known for applying Agile to its aerospace engineering workflows. Boeing etc. are much slower because they use waterfall.
- Balooga 3y ago
  Oh, I'm pretty sure someone(s) manages a massive GANTT chart over on the SpaceX side.

Razengan 3y ago

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?

icegreentea2 3y ago
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.
carabiner 3y ago
There are 1,000 other requirements that do not demand maximum 3D rotation efficiency.
dmbche 3y ago
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.
- 0cf8612b2e1e 3y ago
  Plus, without deflector shield voodoo, a skinny tube design minimize your cross sectional area and how much debris you will impact.
pdonis 3y ago
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.

AnimalMuppet 3y ago

> 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.

pdhborges 3y ago
Isn't a Pareto optimal solution always at the edge of the feasible space?
- lamchob 3y ago
  Yet, it is usually in middel of the repsective dimensions, not on the extreme ends of either.
firewolf34 3y ago
More succinctly stated as "Only the Sith deal in absolutes."

GlenTheMachine 3y ago

Hi. I'm Henshaw of Rule 37. AMA.

carabiner 3y ago
What work are you doing these days?
- GlenTheMachine 3y ago
  I'm the lead roboticist on this: https://www.darpa.mil/program/robotic-servicing-of-geosynchronous-satellites https://www.darpa.mil/program/robotic-servicing-of-geosynchr...
Rebelgecko 3y ago
What's the backstory, was there a situation where you were the blamee (or the blamer?)
xNeil 3y ago
What's a line of blame?
- e40 3y ago
  I take it to mean when blame is being aimed you are not in the line of fire.
  - Eduard 3y ago
    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.
    - bombcar 3y ago
      Blame is just another word for responsibility. If you don’t have clear lines of blame you don’t have clear responsibilities.

JoeAltmaier 3y ago

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.

rahimnathwani 3y ago
Then specify that in the requirements.
imoreno 3y ago
Margin of error should be calculated at the design stage, not as an afterthought during implementation.
dylan604 3y ago
>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
- dclowd9901 3y ago
  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.
  - dylan604 3y ago
    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.
    - tonyarkles 3y ago

firewolf34 3y ago

In Shute Norway's autobiography, Slide Rule, he describes the design and construction of the [R100](https://en.m.wikipedia.org/wiki/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 3y ago

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.

monkeydreams 3y ago
> 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.
midoridensha 3y ago
> 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...

jameshart 3y ago

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.

leashless 3y ago
I think satellites count?
SahAssar 3y ago
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 https://www.stilldrinking.org/programming-sucks is for devs. Cynical humor that contains a lot insights.
carabiner 3y ago
The secret to success: work hard. Who said it? Albert Einstein.
visviva 3y ago
What makes you think this is limited to human-rated spacecraft?

moffkalast 3y ago

> 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.

iancmceachern 3y ago

Love this, it pops up on HN every few years. It's just the right combo of truth and comedy.

c_o_n_v_e_x 3y ago

>(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.

marmakoide 3y ago

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.

deleted 3y ago

[deleted]

Modified3019 3y ago

>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.

roughly 3y ago
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.
bladewolf47 3y ago
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.
- Tuna-Fish 3y ago
  That's for the cost estimate, not time.
- hibbelig 3y ago
  I understood it as: better_time = estimated_time * 3; better_cost = estimated_cost * 10;
  - bladewolf47 3y ago
    I missed that - this makes more sense
    - junon 3y ago
      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.

chasil 3y ago

> 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!

BubbleRings 3y ago

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!

tw04 3y ago

> 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.

Shawnj2 3y ago
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.
sethrin 3y ago
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.geekwire.com/wp-content/uploads/2015/11/151119-plate2-1240x823.jpg https://web.archive.org/web/20230522164734im_/https://cdn.ge...

edu 3y ago

> 41. There's never enough time to do it right, but somehow, there's always enough time to do it over Same for software!!!

2rsf 3y ago
Most of them apply to software as well