6 ms·

Akin's Laws of Spacecraft Design

132 points by MikeCapone 14y ago

wlesieutre 14y ago
> In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point. This one caught my eye as being only half right. As you increase something, you may get better performance up to a point but then see it level off and decrease. For instance, you could increase the fuel capacity by a factor of 10, but then you'd need a larger engine, more powerful thrusters to maneuver it, etc. On the other hand, the lower bound of "don't do that at all" is frequently optimal. A lot of these cases are things that you'd intuitively see as stupid ideas (ie "how many lead weights should we bolt on to the fins"), but in other cases they aren't. Like a fish that evolved away its eyes because they were no longer useful. (https://en.wikipedia.org/wiki/Amblyopsidae https://en.wikipedia.org/wiki/Amblyopsidae) If you took the "law" too literally, you'd be distrustful of saying "These eyes aren't doing anything, let's have 0 of them." Don't be afraid to remove wasteful features.
- pacaro 14y ago
  I'm sure that I'm going to be caught out for mis-remembering this... but I recall something from Richard Feynman's auto-biography where he's describing a piece of advice from when he was working on a mechanical analog computer (for ack-ack aiming) you pick the gears from nearer the middle of the range if you possibly can. I've worked on projects that were burned by incorporating too many bleeding edge components, when things are too new, you often don't know what you don't know. I'm sure if I had this list to point to on my last project, I'd either have been shown the door sooner, or we might have had a better chance of success...
  - andrewflnr 14y ago
    I remember that about the gears, too. IIRC, the big ones were too expensive and the small ones' teeth broke.
- dredmorbius 14y ago
  The rule works best where there's an established range and some testing behind it (e.g.: not when you're proving new ground). Hence the Feynman gear-selection rule. Zero should be a valid number (there are many systems with no gears, also describable as gears with no teeth). But once you decide that you need a gear, it's got to have some teeth, or some number of eyes, etc. Also, wouldn't a fish with no eyes be a fsh?
hcarvalhoalves 14y 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. > 7. At the start of any design effort, the person who most wants to be team leader is least likely to be capable of it. Some of these adages are universal.
- StuieK 14y ago
  So good leaders aren't allowed to want to lead?
  - hayksaakian 14y ago
    Pick a good leader who doesn't brown nose his way into leadership positions
  - hcarvalhoalves 14y ago
    The keyword here is want.
  - lwat 14y ago
    People who want to lead are not good leaders.
  - happimess 14y ago
    I think that the qualifier "At the start" is important, here. I've known many good leaders who, at some point, got frustrated and took charge. I've also known a lot of jerks who wanted to be in charge of things as soon as they heard that there was going to be something to be in charge of.
  - arethuza 14y ago
    Where does it say "good" in that rule? In my experience, people who want to lead for the sake of leading, that is to get status or rewards that often come with that role or because they simply enjoy power, are often by far the worst leaders. However, those who reluctantly come to leadership because they want to achieve something often make the best leaders but that is quite different to people who regard leadership (power) as an end in itself.
ColinDabritz 14y ago
These are fantastic, and many apply to general engineering and design, including software systems. Thanks for sharing! By the way, I believe a more up to date URL is: http://spacecraft.ssl.umd.edu/akins_laws.html http://spacecraft.ssl.umd.edu/akins_laws.html
- TeMPOraL 14y ago
  Somehow the added ones don't seem as insightful as the rest.
6ren 14y ago
15. (Shea's Law) The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up. So true. Parnas' paper on information hiding and decomposing into modules is of course also about choosing the interfaces https://docs.google.com/viewer?url=http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf https://docs.google.com/viewer?url=http://www.cs.umd.edu/cla... (bonus: he describes the genesis of the paper, see the "quick view" of the top of this google search https://www.google.com/search?q=filetype%3Apdf+parna+on+the+criterion+for+decomposing+into+modules https://www.google.com/search?q=filetype%3Apdf+parna+on+the+...) Unfortunately, once you've chosen interfaces that hide the details and things likely to change, it becomes harder to change the interfaces, in case you were wrong in your predictions of what will change in the future... Or, if you just didn't understand the best way to approach the system... (how could that happen?) It's hard to change because other modules depend on this interface. Unit tests operate on the interfaces between modules, so they need to change too... and you won't have the safety net they provide. Documentation must change. etc. Therefore, in practice, interfaces are not changed.
- wsc981 14y ago
  I thought it was an interesting point and it reminded me of something. I've worked on an iOS project with a really ugly web API. I could improve the project internally quite a bit by making a native iOS API that I would talk to, which would hide lots (but not all) of the uglyness of the web API. So I guess if one deals with ugly interfaces it may be wise to wrap the ugly interface in a cleaner one. As an added benefit, the project is decoupled more from the ugly interface, perhaps permitting to replace it with something better in the future.
  - rosser 14y ago
    "All problems in computer science can be solved by another level of indirection." — David Wheeler [1] [1] https://en.wikipedia.org/wiki/David_Wheeler_(computer_scientist) https://en.wikipedia.org/wiki/David_Wheeler_(computer_scient...
btilly 14y ago
I love #6. (Mar's Law) Everything is linear if plotted log-log with a fat magic marker. People say lol a lot when they didn't really. But I really did at that one. Because I know exactly why it is true. What's going on is that you have a high order term that dominates the big-O. As long as that is anything of the form x^k it will be linear, and the lower order terms will show up as minor deviations, which the magic marker smoothes out. Since big-O scaling terms of that form arise in a lot of different equations, it is very common that real data DOES show up as a (reasonably) straight line on a log-log graph. And the slope of that approximate line tends to be very useful to know. But if you see data set after data set plotted on log-log with magic marker lines drawn, it is easy to ridicule the phenomena. :-)
jpxxx 14y ago
#41: The bridge must have kicky furniture that is stuffed with fragile explosives and easily ruptured fog vents
deleted 14y ago
[deleted]
zandor 14y ago
Kelly Johnson's 14 Rules of Management are also great. http://en.wikipedia.org/wiki/Clarence_Johnson#Kelly_Johnson.27s_14_Rules_of_Management http://en.wikipedia.org/wiki/Clarence_Johnson#Kelly_Johnson.... Note the unwritten 15th rule: "Starve before doing business with the damned Navy. They don't know what the hell they want and will drive you up a wall before they break either your heart or a more exposed part of your anatomy."
nazgulnarsil 14y ago
Number 20 describes much of the world.
Fice 14y ago
(Tupolev-Bartini law) An ugly plane won't fly.
dredmorbius 14y ago
Very early in my career, early enough that I could fully appreciate its relevance for another few decades, I stumbled across a copy of Arthur Boch's Murphey's Law and other reasons things go wrong. The fundamental truth of the astute, or more often, pained, observations of engineers continues to impress me. The 26th anniversary edition was released (or escaped) in 2003. http://www.amazon.com/Murphys-Law-26th-Anniversary-Edition/dp/0399529306 http://www.amazon.com/Murphys-Law-26th-Anniversary-Edition/d...
nnq 14y ago
> 11. Sometimes, the fastest way to get to the end is to throw everything out and start over. ...for all the people saying that a software rewrite is never worth it :)
- simonh 14y ago
  I think there are stages during preliminary development when this can be true, but once you ship to customers you cross a threshold it's hard to pull back from. Twice now I've seen whole companies brought to their knees and sold off for scrap because rewrites of successful products failed.
sspiff 14y ago
It's depressing how much of these are perfectly applicable to software development for large companies. At least most of them are valid in my current job.

132 points by MikeCapone 14y ago

> In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point. This one caught my eye as being only half right. As you increase something, you may get better performance up to a point but then see it level off and decrease. For instance, you could increase the fuel capacity by a factor of 10, but then you'd need a larger engine, more powerful thrusters to maneuver it, etc. On the other hand, the lower bound of "don't do that at all" is frequently optimal. A lot of these cases are things that you'd intuitively see as stupid ideas (ie "how many lead weights should we bolt on to the fins"), but in other cases they aren't. Like a fish that evolved away its eyes because they were no longer useful. (https://en.wikipedia.org/wiki/Amblyopsidae https://en.wikipedia.org/wiki/Amblyopsidae) If you took the "law" too literally, you'd be distrustful of saying "These eyes aren't doing anything, let's have 0 of them." Don't be afraid to remove wasteful features.

pacaro 14y ago
I'm sure that I'm going to be caught out for mis-remembering this... but I recall something from Richard Feynman's auto-biography where he's describing a piece of advice from when he was working on a mechanical analog computer (for ack-ack aiming) you pick the gears from nearer the middle of the range if you possibly can. I've worked on projects that were burned by incorporating too many bleeding edge components, when things are too new, you often don't know what you don't know. I'm sure if I had this list to point to on my last project, I'd either have been shown the door sooner, or we might have had a better chance of success...
- andrewflnr 14y ago
  I remember that about the gears, too. IIRC, the big ones were too expensive and the small ones' teeth broke.
dredmorbius 14y ago
The rule works best where there's an established range and some testing behind it (e.g.: not when you're proving new ground). Hence the Feynman gear-selection rule. Zero should be a valid number (there are many systems with no gears, also describable as gears with no teeth). But once you decide that you need a gear, it's got to have some teeth, or some number of eyes, etc. Also, wouldn't a fish with no eyes be a fsh?

hcarvalhoalves 14y 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. > 7. At the start of any design effort, the person who most wants to be team leader is least likely to be capable of it. Some of these adages are universal.

StuieK 14y ago
So good leaders aren't allowed to want to lead?
- hayksaakian 14y ago
  Pick a good leader who doesn't brown nose his way into leadership positions
- hcarvalhoalves 14y ago
  The keyword here is want.
- lwat 14y ago
  People who want to lead are not good leaders.
- happimess 14y ago
  I think that the qualifier "At the start" is important, here. I've known many good leaders who, at some point, got frustrated and took charge. I've also known a lot of jerks who wanted to be in charge of things as soon as they heard that there was going to be something to be in charge of.
- arethuza 14y ago
  Where does it say "good" in that rule? In my experience, people who want to lead for the sake of leading, that is to get status or rewards that often come with that role or because they simply enjoy power, are often by far the worst leaders. However, those who reluctantly come to leadership because they want to achieve something often make the best leaders but that is quite different to people who regard leadership (power) as an end in itself.

ColinDabritz 14y ago

These are fantastic, and many apply to general engineering and design, including software systems. Thanks for sharing! By the way, I believe a more up to date URL is: http://spacecraft.ssl.umd.edu/akins_laws.html http://spacecraft.ssl.umd.edu/akins_laws.html

TeMPOraL 14y ago
Somehow the added ones don't seem as insightful as the rest.

6ren 14y ago

15. (Shea's Law) The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up. So true. Parnas' paper on information hiding and decomposing into modules is of course also about choosing the interfaces https://docs.google.com/viewer?url=http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf https://docs.google.com/viewer?url=http://www.cs.umd.edu/cla... (bonus: he describes the genesis of the paper, see the "quick view" of the top of this google search https://www.google.com/search?q=filetype%3Apdf+parna+on+the+criterion+for+decomposing+into+modules https://www.google.com/search?q=filetype%3Apdf+parna+on+the+...) Unfortunately, once you've chosen interfaces that hide the details and things likely to change, it becomes harder to change the interfaces, in case you were wrong in your predictions of what will change in the future... Or, if you just didn't understand the best way to approach the system... (how could that happen?) It's hard to change because other modules depend on this interface. Unit tests operate on the interfaces between modules, so they need to change too... and you won't have the safety net they provide. Documentation must change. etc. Therefore, in practice, interfaces are not changed.

wsc981 14y ago
I thought it was an interesting point and it reminded me of something. I've worked on an iOS project with a really ugly web API. I could improve the project internally quite a bit by making a native iOS API that I would talk to, which would hide lots (but not all) of the uglyness of the web API. So I guess if one deals with ugly interfaces it may be wise to wrap the ugly interface in a cleaner one. As an added benefit, the project is decoupled more from the ugly interface, perhaps permitting to replace it with something better in the future.
- rosser 14y ago
  "All problems in computer science can be solved by another level of indirection." — David Wheeler [1] [1] https://en.wikipedia.org/wiki/David_Wheeler_(computer_scientist) https://en.wikipedia.org/wiki/David_Wheeler_(computer_scient...

btilly 14y ago

I love #6. (Mar's Law) Everything is linear if plotted log-log with a fat magic marker. People say lol a lot when they didn't really. But I really did at that one. Because I know exactly why it is true. What's going on is that you have a high order term that dominates the big-O. As long as that is anything of the form x^k it will be linear, and the lower order terms will show up as minor deviations, which the magic marker smoothes out. Since big-O scaling terms of that form arise in a lot of different equations, it is very common that real data DOES show up as a (reasonably) straight line on a log-log graph. And the slope of that approximate line tends to be very useful to know. But if you see data set after data set plotted on log-log with magic marker lines drawn, it is easy to ridicule the phenomena. :-)

jpxxx 14y ago

#41: The bridge must have kicky furniture that is stuffed with fragile explosives and easily ruptured fog vents

deleted 14y ago

[deleted]

zandor 14y ago

Kelly Johnson's 14 Rules of Management are also great. http://en.wikipedia.org/wiki/Clarence_Johnson#Kelly_Johnson.27s_14_Rules_of_Management http://en.wikipedia.org/wiki/Clarence_Johnson#Kelly_Johnson.... Note the unwritten 15th rule: "Starve before doing business with the damned Navy. They don't know what the hell they want and will drive you up a wall before they break either your heart or a more exposed part of your anatomy."

nazgulnarsil 14y ago

Number 20 describes much of the world.

Fice 14y ago

(Tupolev-Bartini law) An ugly plane won't fly.

dredmorbius 14y ago

Very early in my career, early enough that I could fully appreciate its relevance for another few decades, I stumbled across a copy of Arthur Boch's Murphey's Law and other reasons things go wrong. The fundamental truth of the astute, or more often, pained, observations of engineers continues to impress me. The 26th anniversary edition was released (or escaped) in 2003. http://www.amazon.com/Murphys-Law-26th-Anniversary-Edition/dp/0399529306 http://www.amazon.com/Murphys-Law-26th-Anniversary-Edition/d...

nnq 14y ago

> 11. Sometimes, the fastest way to get to the end is to throw everything out and start over. ...for all the people saying that a software rewrite is never worth it :)

simonh 14y ago
I think there are stages during preliminary development when this can be true, but once you ship to customers you cross a threshold it's hard to pull back from. Twice now I've seen whole companies brought to their knees and sold off for scrap because rewrites of successful products failed.

sspiff 14y ago

It's depressing how much of these are perfectly applicable to software development for large companies. At least most of them are valid in my current job.