Akin's Laws of Spacecraft Design | Hacker News Reader

Akin's Laws of Spacecraft Design

spacecraft.ssl.umd.edu

132 pointsMikeCapone25 comments

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

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

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.

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

I remember that about the gears, too. IIRC, the big ones were too expensive and the small ones' teeth broke.

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?

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

So good leaders aren't allowed to want to lead?

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.

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.

The keyword here is want.

Pick a good leader who doesn't brown nose his way into leadership positions

People who want to lead are not good leaders.

  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/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+...)

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.

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.

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

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

Somehow the added ones don't seem as insightful as the rest.

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

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

Kelly Johnson's 14 Rules of Management are also great.

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

> 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 :)

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.

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

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.

Number 20 describes much of the world.

Reply on news.ycombinator.com