Akin's Laws of Spacecraft Design | Hacker News Reader

Akin's Laws of Spacecraft Design

spacecraft.ssl.umd.edu

134 pointsskmurphy17 comments

I found this looking for the source of "climbing higher and higher trees to reach the moon" It's Mo's Law (#31 on Akin's list) 31. (Mo's Law of Evolutionary Development) You can't get to the moon by climbing successively taller trees.

Some other good ones for software products:

   1. Engineering is done with numbers. Analysis without numbers is only an opinion.
   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.
   9. Not having all the information you need is never a satisfactory excuse for not 
      starting the analysis.
   23. The schedule you develop will seem like a complete work of fiction up until 
       the time your customer fires you for not meeting it.

I'm puzzled by #31, I can only interpret it as iterative development not working.

What would be the intended interpretation?

More of the same is not enough to get you to some other faraway place.

Making a better car will not result in an airplane.

That does not mean that making a car first is not an worthy endeavor for gaining experience to build an airplane - should you need e.g. machining, metalworking and general engineering experience. But it won't give you ANY aerospace background.

Or as Alan Mulally famously put it: "An automobile has about 10,000 moving parts, right? An airplane has two million, and it has to stay up in the air." (on being asked "How are you going to tackle something as complex and unfamiliar as the auto business when we are in such tough financial shape?")

Some problems require a revolutionary approach. For example, managing the info in a departmental system for 100 users is very different from an Internet application serving a million users. You can't just evolve from one to the other, you need to radically re-design for fundamentally different requirements.

Iterative development is good at getting the details right. But you're never going to make a huge leap with iterative development, you need to make such leaps intentionally and with significant planning, even if you iteratively fine-tune after that.

So true

Also, about iterative design:

   33. A good plan violently executed now is better than a perfect plan next week.

About the unknown:

   22. When in doubt, document.

Harsh reality:

   27. Schedules only move in one direction.

"When in doubt, estimate. In an emergency, guess. But be sure to go back and clean up the mess when the real numbers come along."

This works well for financial forecasting too.

The three keys to keeping a new manned space program affordable and on schedule: 1) No new launch vehicles. 2) No new launch vehicles. 3) Whatever you do, don't decide to develop any new launch vehicles.

Sigh.

Sounds exactly like trying to launch your new startup.

In case of web startups:

1) no new web framework

2) no new web framework

3) whatever you do, don't decide to develop any new web framework

From a design/user experience point of view I think this one is the most profound.

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.

Designing for perfect means designing for perfect context. But perfect context never exist. In most cases your customers are using your service/product in sub-optimal circumstances.

    > 14. "Better" is the enemy of "good".

Alludes to Voltaire's Le mieux est l'ennemi du bien. Google Translate: http://translate.google.com/translate_t?q=Le%20mieux%20est%2.... http://en.wikiquote.org/wiki/Voltaire (many thought-provoking quotes)

    > 30. Engineers always wind up designing the vehicle to look like
    the initial artist's concept.

I find it really helps to have a picture in my mind of what I'm building.

    > 34. Do what you can, where you are, with what you have.

Relevant for me this day, as it includes acknowledging my own inabilities, lack of knowledge, low-quality of prototype code etc, then accepting that that's how it is right now, and acting instead of hand-wringing.

> 28. (Ranger's Law) There ain't no such thing as a free launch.

Corollary to Heinlein's Law:

http://en.wikipedia.org/wiki/There_ain%27t_no_such_thing_as_...

I think these apply more to engineering in general, rather than spacecraft design.

Huh, cool. The Perlis epigrams go to outer space. :)

I was going to say: An ideal spacecraft is not one in which everything is perfect, but one in which it gets hit by something unexpected, everything explodes, while all people manage to evacuate to some escape capsules, combine into a giant robot and save the universe (note anything after "combine" is optional as long as all people survive)

Was a fun read. Works well in software development, just know when to draw the line at ensure it works (people might not die due to our failure, unless you are writing pacemaker code)

..or spacecraft guidance and control software.

Reply on news.ycombinator.com