Live data from Hacker News

Akin’s Laws of Spacecraft Design

spacecraft.ssl.umd.edu

61–70 of 159 posts

Re: Akin’s Laws of Spacecraft Design

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

Re: Akin’s Laws of Spacecraft Design

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

Re: Akin’s Laws of Spacecraft Design

#63
post #44
post #2

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.

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.

Re: Akin’s Laws of Spacecraft Design

#65

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.

Re: Akin’s Laws of Spacecraft Design

#67

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.

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.

Re: Akin’s Laws of Spacecraft Design

#68

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.

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

Re: Akin’s Laws of Spacecraft Design

#69

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/Apoll…

I think satellites count?
Post reply on HN