
Akin's Laws of Spacecraft Design (2003) - teeray
http://spacecraft.ssl.umd.edu/akins_laws.html
======
slg
>16\. The previous people who did a similar analysis did not have a direct
pipeline to the wisdom of the ages. There is therefore no reason to believe
their analysis over yours. There is especially no reason to present their
analysis as yours.

>19\. The odds are greatly against you being immensely smarter than everyone
else in the field. If your analysis says your terminal velocity is twice the
speed of light, you may have invented warp drive, but the chances are a lot
better that you've screwed up.

Learning how to better thread the needle between these two is been one of the
most important things I have learned in my career. Just because this is the
way it was always done doesn't mean we have to do it that way, but the people
who did it that way probably had some reason for it that is worth exploring
and fully understanding.

~~~
derefr
I don't see these as opposed principles.

16\. They're not smart.

19\. You're not smart, either.

Assume everyone is an idiot, including yourself. Verify everything (your own
work _and_ other people's work) using robust testing protocols. Don't use your
own judgement; you're not smart enough for that. Gather evidence. But test
your evidence-gatherers to make sure they're doing their jobs, too. Assume
every component of your system-of-people is half-fallen-down and just barely
limping along at all times. Make a system that works in the face of everyone
coming to work with a concussion.

(And, if some component _isn 't_ barely limping along, then people are
probably being too naive about its potential failures, so inject some chaos
[monkeys] into it to get its reliability down to a level where routing around
_it_ has to be operationalized, too.)

~~~
hyperpallium
In WWII, bullet holes in planes had to be repaired. But the damage wasn't
uniform - some areas got badly shot up, some areas were never damaged. So they
added armour to the undamaged areas, because the planes that got shot there
never came back.

Similar idea from another angle: superficial design flaws obscure fundamental
design flaws (Douglas Adams on the Sirius Corporation Complaints Depatment)

------
koolba
Number 40 is beautiful:

> 40\. (McBryan's Law) You can't make it better until you make it work.

This has been my credo for developing software for as far back as I can
remember. If you approach creating something new as purely experimentation,
you'll get to something workable sooner. You can then either polish your newly
created turd or choose to scrap it for something new that builds on what you
learned.

~~~
OpenDrapery
Turds have a way of living on in the software world.

~~~
groby_b
They live on if they provide value.

And that's OK, because we're in the business of providing value, not building
shiny monuments to our incredible cleverness.

~~~
alxlaz
There's turds and turds. I've seen many of them and no two turds are alike:

1\. A long time ago, we had this turd of a hardware abstraction layer that is
every systems developer's nightmare. Windows drivers behind a middleware, with
COM and whatnot. Support for USB devices, spanning back to Windows 98. No one
dared touch it unless absolutely necessary. Fortunately, no one needed to
touch it too often. The functionality it offered was rich enough that the
trickier logic could be implemented at application level; it decreased code
reuse to some degree, but then again, this was a critical enough piece of
software that the time wasted by duplicating some logic among applications was
offset by the testing effort required for changes in the HAL behemoth. Most of
it was okay-ish, too; it crashed under a few circumstances, but not
mysteriously -- we sort of knew _where_ the bugs were, but workarounds were
available and they were generally deemed good enough.

This was a reasonable kind of turd. I mean, yes, there was technical debt in
it, Jesus, it had comments like "TODO: This looks ugly but for some reason
it's the only way to make it work on <some Windows 2000 build>. Maybe figure
out a cleaner way?", but it didn't really bother anyone. The code was
architected so that technical debt piled up on separate shelves, too. The PCI
(not -X. PCI. Plain PCI) stuff, in particular, was only touched by one or two
people -- but it was perfectly possible to work on other pieces of that code
without breaking the drivers for those weird PCI peripherals.

2\. I was responsible for one of these turds. A while ago, we had to do a lot
of fancy, detailed documentation for a custom logic design. This was going to
be implemented in an FPGA which was going to sit in a pretty advanced medical
device -- so you spec everything _before_ writing a single line of code.

One of the things I wrote to help me was a tool that sucked in the timing
diagrams in our docs (docs were in LaTeX, diagrams were in some markup
language) and generated the Verilog code that put out those signals. This was
a bunch of Python code, not too hairy, but it hardcoded every single
assumption I could make. It started as a tool I'd made for myself; it was
reluctantly promoted to a tool that everyone used.

Some folks tried to adopt it in other projects as well but honestly, the damn
thing just wasn't up to it. I suggested to (my, by this time, former)
colleagues that they'd probably be better off picking a standard markup
language for the timing diagrams (maybe TDML?) and write something that was
going to be useful forever, more or less from scratch. Or, if not, get a
commercial, off-the-shelf thing that does exactly that, written by people who
were paid to write _exactly that_. The time, people and resources for either
of these options turned out to be pretty hard to secure, though, so they ended
up polishing the half-bad Verilog code by hand. Still better than writing it
all by hand, I suppose.

Frankly, this was at least an _excusable_ turd. It was never meant to be used
for so much. It got promoted from "a developer's hack" to "project
infrastructure" through a combination of short-sightedness, lack of awareness
of better options and bad communication, mine included. But it did provide
_some_ value and, honestly, removed none -- it sucked in the end, but it still
sucked less than the other alternative that was actually available.

3\. And then there's real turds. Like, there was this module I saw a while
ago, as part of a bunch of firefighting meetings because the original
developer had quit.

When it was initially written, it was rushed in, and the first thing that got
crossed out from the list was IPv6 support. And fortunately for the schedule,
it turned out some bits and pieces of another feature could be reused here and
there.

The end result was a massive 30,000-line... thing, that not even its creator
really understood by the time he was done. A good chunk of that code was there
to glue the bits that could be "reused" to the new feature. There was no
abstraction layer -- when IPv6 support had to be added in, what happened was
_another_ massive dump of maybe 10,000 lines, that was interleaved with the
other one via a thick forest of if-this-is-ipv4-do-ipv4-stuff-else-do-
ipv6-stuff.

After humongous amounts of testing and bugfixing, it actually made its way out
through the door. which effectively marked it as "too expensive to rewrite",
and that was it.

Unlike the thing at #1, there was no way to extend it, in any way. Adding even
the tiniest feature took weeks and spawned dozens of bugs. Unlike the thing at
#2, this wasn't some internal tool, it was production code.

Truth is, _it works_ , or at least it worked the last time I had anything to
do with it. But in terms of investment it was a really bad thing to do. It was
so hard to extend that there was no way to accommodate customer requirements
in any sort of realistic timeframe. Keeping up with the competition basically
required two engineers working full-time, on something that wasn't necessarily
a critical feature but you couldn't _not_ have it.

 _This_ turd probably removed way more value than it added. Or, if not, it
certainly _prevented_ way more value from being added. It's my standard for
turds.

~~~
erikpukinskis
> Truth is, _it works_

Yes, that’s “value” in an important sense. But people rarely add in the
opportunity cost.

We make decisions every week about what can be done based on the tech debt
involved. Every time we punt on an improvement, that’s a real cost. These
boondoggles that forever wall off parts of the product as immutable have a
cost week after week. What’s the net value after you subtract that cost? Is
there any?

~~~
B1FF_PSUVM
"Evolution in action" is what comes to mind reading alxlaz's detailed,
cathartic (I hope ;-), lamentation.

~~~
alxlaz
I meant it more like a recollection than a lamentation, but it was cathartic
here and there :-).

I don't know if it's obvious from it, so I'd rather spell it out -- there are
times when "turds" are useful and not to be disdained, much like their real-
word cousins: cow dung can be a good construction material and a useful fuel.
Certainly worse than concrete and uranium but if that's all you can find or
all you can afford, it sure beats eating raw meat and sleeping under the
stars.

This isn't true of _every_ piece of software shit in existence, though.
Sometimes, " _but it works_ " is just a bad excuse.

------
tomkat0789
My favorite as an engineer/scientist who has sat through tons of terrible
presentations:

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

If people can't understand your ideas, you're counting on them to shrug and
say, "Boy, this guy sounds smart! I guess we should do what he says!" If
they're doing their job, they won't.

~~~
TeMPOraL
It's sad, really. In a perfect world, you'd have an awesome design coupled
with awesome sales pitch. In reality, a _lot_ of people realized that almost
the entire ROI comes from the sales pitch, so you can half-ass the design part
(or even skip it entirely, if your sales person is good).

~~~
forgotmysn
its also probably a supply/cost issue. People that are good at sales are more
common, and cheaper to employ than people that are good at designing complex
feats of engineering.

~~~
danielsju6
But they rarely find themselves in the same circles.

~~~
sverige
People that are _great_ at sales are very rare, though. And people that are
great at sales _and_ have great platform skills are the ones who make it past
director level to the executive suite.

Engineers do well when they spot such people early and make friends with them.
"Early" is important, because by the time they make it to the executive suite,
they (hopefully) already have trusted "technical advisers" who will tell them
when their idea sucks before it gets sold and propagated throughout the
organization. If they don't, then they will rely on their secret sales
intuition and their defenses against common sense will be impenetrable.

This is usually the highest executive function of engineers / "technical
advisers" in large enterprises. Not so glamorous, but critical to the health
of any organization.

------
elihu
I thought this one was interesting:

> 30\. (von Tiesenhausen's Law of Engineering Design) If you want to have a
> maximum effect on the design of a new engineering system, learn to draw.
> Engineers always wind up designing the vehicle to look like the initial
> artist's concept.

I suppose a lot of new ideas come with a lot of "filler" details that weren't
consciously decided on but end up as a permanent fixture of the design, and
that whoever tries first to communicate the idea to others has a lot of
unintentional influence over the final product.

~~~
mamon
This approach comes with hidden cost of adding unnecessary complexity. Think
about B2 bomber design: it looks like some "artist" wanted to recreate a
Batplane, or other sci-fi spacecraft and then it took a lot of engineering
effort to make the thing of such ridiculous shape to actually fly in stable,
predictable manner.

~~~
WJW
Actually the shape of a B2 is very much influenced by it's function and only
mildly by the desire to "look cool". (Though that is important too, apparently
the F35 contract went to Lockheed Martin instead of to Boeing because the
specs of both proposal were nearly identical but the LM one looked much
better)

A "stealth" aircraft is not stealthy from all directions (nor does it need to
be) but is optimized for bouncing the radar waves away from the direction of
its target. The best shape for this would be to build the plane in the shape
of an infinitely long flat surface, but since those are too expensive the
"infinitely long" part is usually scrapped. Even shorter flat surfaces have
terrible aerodynamical properties though, so there's often a compromise to
make it more like a triangle. Then of course it needs to carry stuff like
pilots, engines and bombs, so it can't be extermely flat but has to be
bulbous. The engines need air intakes but radar waves bouncing off the
rotating blades of a jet engine compressor have a very distinct signature in
the frequency spectrum, so it makes sense to move the air intakes to the top
of the plane where ground based radars can't shine into them. A similar thing
goes for the outlets, but those need to be extremely heat resistant as well.
To prevent the hot gases from flowing over an extended area of the fuselage
you move the trailing edge of the triangle a bit forward. Then there are some
more requirements like visibility for the pilots during take off and landing
that put bounds on where the cockpit can be. Looks were very much a last
consideration for the B2 and pretty much all of of its shape is due to its
mission requirements :)

~~~
dotancohen
> apparently the F35 contract went to Lockheed Martin instead of to Boeing
> because the specs of both proposal were nearly identical but the LM one
> looked much better

People love to repeat this, but it's wrong. Yes the Boeing plane was ugly with
the large air scoop, but it also was a great plane whereas the Lockheed Martin
plane was a terrific plane. At the time of selection, the Boeing plane could
not VTOL with all the bodywork in place (landing gear doors for instance) yes
the LM plane had just completed a vertical landing after a supersonic flight.
Also, not since the age of propellers had Boeing designed a combat aircraft,
whereas Lockheed did the SR71, U2, F117, and a host of other innovative
aircraft.

The one thing that the Boeing aircraft had going for it was the single-piece
wing. The JSF competition was primarily to design an affordable plane, and the
Boeing probably would have been much less expensive to build and qualify.

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

This is awesome. I don't know how many times I've seen over engineering in the
field. It's crazy. Well we may one day want to do X.

~~~
ythn
I'm having a hard time visualizing this one.

Say the problem is driving a nail into a wall for hanging up a picture.

In this case:

Elegant = solution is a glass cube

Efficient = solution is gasoline-powered nail driver which drives 1000 nails
per minute

Effective = solution is hammer

~~~
kbutler
Elegant = using magnetic paint and magents on the back of the picture. You
thus do not need a nail, can hang the picture where ever you want, and remove
it without leaving a trace.

You just have to repaint the house to be able to use it.

~~~
Klathmon
See I think of elegant as "set the picture on a table".

The engineer might _think_ it solves the problem and does so in a way that is
seen as cheaper, easier, and faster. But in reality it's not what was needed
and the elegance of the solution will come back to bite them when the first
user wants the picture a bit higher (which is normally met with "why would you
want to do that?")

------
mabbo
39\. (alternate formulation) The three keys to keeping a new human space
program affordable and on schedule:

    
    
           1)  No new launch vehicles.
           2)  No new launch vehicles.
           3)  Whatever you do, don't develop any new launch vehicles.
    

Someone better tell Elon.

~~~
walrus01
NASA insistence on the human-rating for their own commercial crew spaceflights
greatly increases the cost. If I recall right two falcon 9 have been lost to
accidents, one on the pad, another 150 seconds into the flight. But the
overall ratio of rapid unscheduled disassemblies to successful flights is
looking promising.

Compare the predicted likelihood of fatalities with how many FAA licensed
amateur/kit built "experimental" airplanes crash each year, killing their sole
occupant pilots...

The FAA seems to be relatively OK with that fatality rate, on an ongoing
basis, but spacecraft are held to a much higher standard.

If there had been a human in the very first Dragon flight carrying a wheel of
cheese, years ago, they would have survived and had a nominal flight.

~~~
octorian
I also wonder how many of NASA's own human launch vehicles would have actually
passed the "human rating" requirements they're now applying to everyone else.

~~~
walrus01
Few, considering the 1+0 lack of redundancy for major life support systems on
the Mercury, gemini and Apollo. Their test method seemed to be "fly it
unmanned a couple times, if it didn't explode or lose pressure, put some
people in it".

~~~
dvdkhlng
And don't forget the space shuttle which had a lot of possible single-point-of
failures during launch and landing (e.g. no way to do a survivable launch
abort during the first phase of flight; no way to survivably compensate
asymmetric thrust when one booster were to fail; no way to shut down or eject
boosters until burned empty; no way to perform ballistic reentry and landing
when orbital control thrusters damaged).

------
teeray
Credit to @tlb for surfacing it in a comment here:
[https://news.ycombinator.com/item?id=16995612](https://news.ycombinator.com/item?id=16995612)

Reposting it here because I think it's awesome.

~~~
jacquesm
Agreed. I was looking for a posting so I could upvote it when it happened.
There's a scary number of parallels with software development in there.

------
TeMPOraL
My all-time favourite is #6:

> _6\. (Mar 's Law) Everything is linear if plotted log-log with a fat magic
> marker._

I also love btilly's explanation of why it's actually true:
[https://news.ycombinator.com/item?id=5058211](https://news.ycombinator.com/item?id=5058211).

------
maze-le
> Your best design efforts will inevitably wind up being useless in the final
> design. Learn to live with the disappointment.

Sounds like Software Architecture to me.

> At the start of any design effort, the person who most wants to be team
> leader is least likely to be capable of it.

This might be true for any organization.

~~~
mattkevan
And product management. The cheery slogan there is 70 percent of what you do
will fail, the remaining 30 percent will need at least 3 or 4 goes before you
get it right.

~~~
duncan_bayne
An actually cheery way of putting that is "30 percent of your hypotheses will
be validated, after some amount of refinement" ;)

~~~
mattkevan
Oh I like that. Sounds much better!

------
andrewbinstock
Great link!

>13\. Design is based on requirements. There's no justification for designing
something one bit "better" than the requirements dictate.

This is YAGNI stated a different way.

~~~
perl4ever
I agree that you shouldn't spend a _lot_ of effort going beyond the
requirements, but sometimes you will reap huge benefits because you happened
to go _somewhat_ beyond the requirements in a given instance. It's like the
property of brittleness - you don't want to spend too much time making
everything adjustable and bendable, but neither do you want to make everything
as hard and precise and brittle as possible.

Someone linked an article elsewhere on HN about the true meaning of mediocrity
that I enjoyed and really made me think about this:

[https://www.ribbonfarm.com/2018/04/24/survival-of-the-
medioc...](https://www.ribbonfarm.com/2018/04/24/survival-of-the-mediocre-
mediocre/)

------
azernik
> 33\. (Patton's Law of Program Planning) A good plan violently executed now
> is better than a perfect plan next week.

In case anyone's wondering about the use of "violently" \- this is supposed to
be _General_ Patton's law about military plans. Just so happens to apply to
other fields.

~~~
groby_b
Except the "violently" here does not actually refer to the use of military
force.

It's in the sense of "vigorously" or "forcefully". No hesitation. No
hesitation, no waffling, no debate - "just do it". Or, as Amazon calls it
"disagree and commit"

~~~
azernik
In the engineering context it means that. But in the original context, it
meant both.

------
Veelox
> 37\. (Henshaw's Law) One key to success in a mission is establishing clear
> lines of blame.

I feel like this applies to a lot more than just spacecraft design.

~~~
slg
That is true, but the phrasing is a little aggressive. Assigning "lines of
blame" makes it sound like it is about having someone to point to after the
fact. It is really about every part of a project having a single owner who is
accountable so nothing slips through the cracks of bureaucracy. A way to
rephrase that without the negative connotations of "blame" is "when everyone
is responsible, no one is responsible."

~~~
GlenTheMachine
Hi! I'm Henshaw, and I coined this law. Dave Akin was my lab director in grad
school.

You are correct in your analysis. Of course, the phrasing was _meant_ to be a
little aggressive, otherwise it isn't memorable.

~~~
slg
>Of course, the phrasing was meant to be a little aggressive, otherwise it
isn't memorable.

That is totally true and was something I missed. A law is of no value if no
one remembers it. I bet we could even find one of Akin's laws to explain why
that is the case.

Side note, HN blows my mind sometimes in that I can make a comment on a term
and within minutes the guy who coined the term is on here responding.

------
thebigspacefuck
My personal favorite is 20:

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

------
aje403
That link is easily the greatest thing I've seen on HN. Thank you

Until 42, that was a buzzkill

~~~
bartread
There's a lot of fantastic nuggets in there, that's for sure, but I have a
nasty feeling that in a few years time this one will have become firmly
entrenched in the vile lexicon of management wank-speak:

 _31\. (Mo 's Law of Evolutionary Development) You can't get to the moon by
climbing successively taller trees._

~~~
staticautomatic
That one's gonna be the new "revolution vs evolution".

------
sgillen
Hey! I worked with Dr. Akin in my undergrad. Definitely learned some of these
he hard way during my project:

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

And

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

------
aj7
I saw a $96M startup fail, not because the product failed, but because the
distribution function for the yield was not understood. It was too sharply
peaked to be practical. There’s a lesson there.

------
B1FF_PSUVM
> 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 going to complain that Cheops' Law ("it always takes longer and costs
more" is my version) was missing, but that's a useful elaboration providing a
new target.

------
hyperpallium

      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.
    

This is the problem with the information hiding approach of ADT, OO and even
APIs: makes it easy to change the module internals, but hard to change the
module interfaces.

But, TBF, the real problem is dependencies.

------
skmurphy
I blogged about how to apply ten of these to startups at
[https://www.skmurphy.com/blog/2011/01/10/applying-akins-
laws...](https://www.skmurphy.com/blog/2011/01/10/applying-akins-laws-of-
spacecraft-design-to-startups/)

------
marze
>39\. (alternate formulation) The three keys to keeping a new human space
program affordable and on schedule:

1) No new launch vehicles.

2) No new launch vehicles.

3) Whatever you do, don't develop any new launch vehicles.

Funny to see this on the list while NASA violates it year after year.

------
sandworm101
43\. Does it work in KSP?

Anyone else note the significance of stopping any list of questions at 42?

------
marcofloriano
I'm not an engineer, but i can relate a lot with that:

19\. The odds are greatly against you being immensely smarter than everyone
else in the field. If your analysis says your terminal velocity is twice the
speed of light, you may have invented warp drive, but the chances are a lot
better that you've screwed up

------
FractalLP
As an engineer I don't understand "engineering is done without numbers". All
engineering revolves around math. Granted, estimations are needed when your
doing analysis on something with no simple formula or that 12 inch pipe has
some unknown amount of grime between 1-4 inches.

~~~
FeteCommuniste
It says “engineering is done with numbers.”

------
neves
Great!!! These laws work for _any_ kind of engineering project. Maybe any kind
of project.

------
hobofan
This has to be one of the worst advice lists of its kind I've seen.

\- Too long to be remembered

\- Half of it is clever quips and not actual insights

\- A lot of the points contradict each other

A list like this mostly serves as a feel-good piece for experienced engineers
rather than useful advice for inexperienced ones, since they don't know which
part of the list to take how seriously and how to interpret the contradicting
ones.

~~~
lopatin
If long and contradictory lists are so bad, how do you explain the Ferengi
culture's success in adopting the 300 or so Rules of Acquisition? [1]

[1] [http://memory-alpha.wikia.com/wiki/Rules_of_Acquisition](http://memory-
alpha.wikia.com/wiki/Rules_of_Acquisition)

~~~
mmirate
Quite easily: _Star Trek_ being a work of fiction, its contents are
unconstrained by any aspects of reality other than the limitations of its
medium (in this case, live-action television).

------
eecc
Hmm, judging by that list we’re all Rocket Scientists.

(or at least we have the same problems)

------
Angostura
Not a big fan of

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

~~~
jgsteven
Same here. Also this one: 13\. Design is based on requirements. There's no
justification for designing something one bit "better" than the requirements
dictate.

To what level this is true depends on the complexity of the system I suppose,
and how accurate the requirements actually are.

------
mauliknshah
Honestly, I loved this! Thank you for posting.

------
mrfusion
There’s really nothing about spacecraft.

~~~
ceejayoz
I mean, sure, it's mostly all stuff applicable to large, complex projects, but
you should scroll down a bit...

> 39\. Any exploration program which "just happens" to include a new launch
> vehicle is, de facto, a launch vehicle program.

~~~
Hextinium
This also though could be applied to any system that just happens to have a
massive amount of work to get it even above the ground as well. Just change
the language to the behemoth in your field of choice and it applies.

------
nissarup
I want these on a poster.

------
jonshariat
This has been posted to HN 9 times

[https://hn.algolia.com/?query=Laws%20of%20Spacecraft%20Desig...](https://hn.algolia.com/?query=Laws%20of%20Spacecraft%20Design%20&sort=byPopularity&prefix&page=0&dateRange=all&type=story)

The last one was only 1 day ago.

~~~
humanfromearth
Not enough! These should be read at least once a month.

