
Akin's Laws of Spacecraft Design - MikeCapone
http://spacecraft.ssl.umd.edu/old_site/academics/akins_laws.html
======
btilly
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. :-)

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

~~~
pacaro
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
I remember that about the gears, too. IIRC, the big ones were too expensive
and the small ones' teeth broke.

------
hcarvalhoalves
> 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
So good leaders aren't allowed to want to lead?

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

------
6ren

      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...](https://docs.google.com/viewer?url=http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf)
(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+...](https://www.google.com/search?q=filetype%3Apdf+parna+on+the+criterion+for+decomposing+into+modules))

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
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
"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...](https://en.wikipedia.org/wiki/David_Wheeler_\(computer_scientist\))

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

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

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

------
dredmorbius
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...](http://www.amazon.com/Murphys-Law-26th-Anniversary-
Edition/dp/0399529306)

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

[http://en.wikipedia.org/wiki/Clarence_Johnson#Kelly_Johnson....](http://en.wikipedia.org/wiki/Clarence_Johnson#Kelly_Johnson.27s_14_Rules_of_Management)

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

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

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

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

------
nazgulnarsil
Number 20 describes much of the world.

