
Akin's Laws of Spacecraft Design - khet
http://spacecraft.ssl.umd.edu/akins_laws.html
======
idreyn
> 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.

I feel like you could permute "elegant", "efficient", and "effective" in any
way here and still arrive with a maxim that sounds nice but doesn't really say
anything.

~~~
sanj
I don't agree, but there is a level of interpretation at play in here:

elegant: builds a system in a way that is technically satisfying

efficient: builds a system in a way that uses the least resources

effective: builds a system in way that best solves the problem

I've built a lot of elegant systems that didn't solve the right problem but
sure looked good.

I've also build systems out of leftover servers and laptops that were super
inexpensive.

But I've learnt that there are times where spending money is the best way to
build the system that the customer actually wants (and will pay for).

~~~
pdx
> "elegant: builds a system in a way that is technically satisfying efficient:
> builds a system in a way that uses the least resources effective: builds a
> system in way that solves the problem"

No, 'Effective' solves the problem, but not necessarily in the "best" way
possible. In my opinion, the quote as stated is just wrong. Effective means
"gets it done", but doesn't convey that it was done optimally.

It makes much more sense to me to say...

"Any run-of-the-mill engineer can design something which is effective. A good
engineer designs systems to be efficient. A great engineer designs them to be
elegant."

~~~
JackFr
The way I read it, that's exactly the point.

It makes much more sense to you (and me) that way but the point is _our common
sense about what makes an engineer great is wrong._

------
numbsafari
"To design a spacecraft right takes an infinite amount of effort. This is why
it's a good idea to design them to operate when some things are wrong."

I feel like this applies to everything. I mostly work on ecommerce and
analytics systems, and I feel like I'm having to make this same argument all
the time.

~~~
sillysaurus3
There is an interesting, opposite mindset: The program will not function
unless nothing is wrong.

It was surprising how reliable the programs turn out to be. But the shocking
part is how small they are.

I'm starting to be convinced that the only way to write reliable code is to
spend most of your time trying to remove code. And not at the expense of
clarity; tricks like that don't matter.

~~~
adrianN
Very small programs don't solve complex tasks. If you plan to glue many small,
correct programs together you'll likely get unintended behavior from the
collection. You're just shifting the complexity around.

~~~
ska

       Very small programs don't solve complex tasks.
    

That's not quite right (some simple algorithms solve complex tasks). I think
it is more true that very small programs can't model or facilitate complex
interactions.

Your point about shifting complexity around is a good one.

~~~
adrianN
Well yeah, the universal turing machine has a pretty small program and solves
all kinds of problems. But that's not really what I imagine when I say "a
simple program".

~~~
ska
I wasn't being that abstract, I'm thinking of real world systems.

Some numerical solvers, graph algorithms, control systems, etc. have this
property. They are definitely what I would call a simple program, even if the
math behind them is not. YMMV.

------
johngalt
This one really tells a story:

"A bad design with a good presentation is doomed eventually. A good design
with a bad presentation is doomed immediately."

Both sides of the issue. Doesn't matter how _right_ you are if you can't
convince anyone. While bad plans can persist in sucking up resources because
they were 'sold' well.

~~~
romaniv
It is remarkable that most organization try to "fix" this by teaching everyone
to present (i.e. sell ideas) better, rather than teaching people how to better
listen and evaluate new ideas.

~~~
infogulch
The reason for this is quite simple. Presentation skills are taught to
underlings, but evaluation skills have to be taught to decision makers. It so
happens the decision makers also decide who has to put work into training.

~~~
mfringel
I disagree. Everyone is someone else's underling, even at the top of the
corporate hierarchy, where you have the executives reporting to the
investors/shareholders.

It then follows that everyone has to be taught presentation skills, just as
they're taught evaluation skills.

------
fitzwatermellow
Also relevant: Beginning Engineer's Checklist

[http://www.piclist.com/tecHREF/begin.htm](http://www.piclist.com/tecHREF/begin.htm)

If a ten commandments of growth hacking ever comes into being, my hope is the
first law states: Thou shalt not spam ;)

~~~
VLM
I can date that list to the early 90s because the amazon link is to the old
edition of AoE and I lived thru the Motorola anecdote in the early 90s "Hey
world, design something using our new cutting edge microcontroller" "Sorry
world, my bad, our sales guys did such a good job nobody but GM will get a
shipment for the next three years". I'd add a corollary to that anecdote that
the market to scale software is infinite, but not hardware, theres plenty of
people out there who can rewrite the code for a 8051 faster than anyone on the
planet can magically make late 68hc11 shipments arrive.

An interesting 4th book to add to the book list is the ARRL handbook. If
there's anything you don't understand between those covers, then you just
identified what you need to learn to be a well rounded engineer. AoE is still
good for strictly design topics. Can't design anything better than you
understand the application is another semi-related good one.

~~~
yekim
ARRL handbook = this?

[http://www.arrl.org/shop/ARRL-Handbook-2016-Hardcover-
Editio...](http://www.arrl.org/shop/ARRL-Handbook-2016-Hardcover-
Edition/?page=1)

------
marcosdumay
> 38\. Capabilities drive requirements, regardless of what the systems
> engineering textbooks say.

This is so true. Yet, its the inverse of what all textbooks say.

How can it be this way? This is a huge blind spot right on the middle of
systems engineering.

~~~
sk8ingdom
It's because your customer (who writes requirements) typically doesn't know 1)
what they actually want, or 2) what capabilities actually exist. This is why a
good customer will allow the company to help them write their requirements.

------
golergka
> 14\. (Edison's Law) "Better" is the enemy of "good".

That's a traditional russian saying, never seen it attributed to Edison
before.

~~~
omginternets
Hmm traditional French saying as well: "Le mieux est l'ennemi du bien"

I too call shenanigans on the Edison bit ;)

~~~
lucb1e
Assuming Edison is Thomas Edison, the Wikipedia page about him has nothing to
say about any law of his. I suppose they meant another Edison, though that is
sort of cheating ("Obama's law: such and such" \-- oh, I meant Jamie Obama)

~~~
talles
Why that would be considered cheating?

I often google names from personalities that I know and get a footballer or a
singer in the first results.

~~~
lucb1e
Well when using a very well-known name (such as Edison, Newton or Obama) it is
expected that it's about Thomas Edison, Isaac Newton or Barack Obama, not some
random dude who happens to have the same last name. If you want to quote Jason
Edison, say it's Jason Edison's law to prevent misattribution instead of
piggy-backing on the well-known name.

~~~
talles
The expectation is bounded to the audience and the context of the text. Maybe
Jason Edison would be more obvious than Thomas in a given setting.

Maybe there's an Edison that spacecraft folks know and we don't.

------
b_emery
> 29\. (von Tiesenhausen's Law of Program Management) To get an accurate
> estimate of final program requirements, multiply the initial time estimates
> by pi, and slide the decimal point on the cost estimates one place to the
> right.

I was once commenting to a friend that my project was taking about 12 times
longer than planned, and he said, "ok, about a factor of 4pi". All my time
estimates get a factor of 4pi increase now.

------
mcguire
" _18\. ... Too much reality can doom an otherwise worthwhile design, though._
"

That is entirely too true.

" _20\. A bad design with a good presentation is doomed eventually. A good
design with a bad presentation is doomed immediately._ "

And _that_ explains NASA. (Except for the corollary, "A good design with a
good presentation is doomed, too.")

------
exDM69
Colin Chapman's law of race car design: "simplify, then add lightness".

~~~
nkantar
Keep in mind the following is also attributed to him:

"Any car which holds together for a whole race is too heavy."

------
sly010
Same laws with some additional thoughts:
[http://www.ece.uvic.ca/~elec399/201409/Akin's%20Laws%20of%20...](http://www.ece.uvic.ca/~elec399/201409/Akin's%20Laws%20of%20Spacecraft%20Design.pdf)

------
heaths1
SLS, meet Akin's Law #39. Law #39, meet SLS.

~~~
thearn4
On the other hand, new launch vehicles are good for jobs. Well, probably only
in Huntsville and nowhere else, but Sen. Shelby will see to it that nothing
happens to that work, even if its to the determinant of NASA as a whole.

------
personjerry
This reminds me of Jon’s Law: any drive powerful enough to be interesting is
powerful enough to be a weapon of mass destruction.

~~~
venomsnake
Assume that you could discharge a full Tesla battery in a picosecond. It will
be unpleasant to be nearby.

------
Paul_S
11\. Sometimes, the fastest way to get to the end is to throw everything out
and start over

If this ever happens to me in my career I will start believing in god or
whatever you want. Dealing with "legacy" tech has been the only constant in my
life across several unrelated industries (even in the supposedly brash and
agile games industry).

------
larrydag
I believe most of the laws could be applied to building a minimum viable
product.

------
perlpimp
"2\. To design a spacecraft right takes an infinite amount of effort. This is
why it's a good idea to design them to operate when some things are wrong . "

one of the key definitions of antifragility.

------
nsajko
The "Miller's Law" entry seems wrong in more than one way...

Does anybody know to which Miller it refers to?

------
raymondhong
omg

