[105] in 6.033 discussion
Dave Akin's Laws of Spacecraft Design
nygren@ATHENA.MIT.EDU (nygren@ATHENA.MIT.EDU)
Mon May 20 22:34:16 1996
This was specifically written in terms of Spacecraft Design,
but most of these principles apply to systems in general.
Some of these come from a different point of view (aero/astro
vs computers) and have an interesting perspective.
(Note: Dave Akin used to run the Spacecraft Systems Lab here but
is now a professor at U of Maryland)
From:
http://www.ssl.umd.edu/SSL_html/WWWAuthors/Dave/Akins_laws.html
------- Forwarded Message
Akin's Laws of Spacecraft Design
Engineering is done with numbers. Analysis without numbers is
only an opinion.
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.
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.
Your best design efforts will inevitably wind up being useless in the
final design. Learn to live with the disappointment.
(Miller's Law) Three points determine a curve.
(Mar's Law) Everything is linear if plotted log-log
with a fat magic marker.
At the start of any design effort, the person who most wants to be
team leader is least likely to be capable of it.
In nature, the optimum is almost always in the middle somewhere.
Distrust assertions that the optimum is at an extreme point.
Not having all the information you need is never a
satisfactory excuse for not starting the analysis.
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.
Sometimes, the fastest way to get to the end is to
throw everything out and start over.
There is never a single right solution. There are always
multiple wrong ones, though.
Design is based on requirements. There's no justification for
designing something one bit "better" than the requirements dictate.
(Edison's Law) "Better" is the enemy of "good".
The ability to improve a design occurs primarily at the
interfaces. This is also the prime location for screwing it up.
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.
The fact that an analysis appears in print has no relationship
to the likelihood of its being correct.
Past experience is excellent for providing a reality check. Too much
reality can doom an otherwise worthwhile design, though.
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, the chances are better that you're screwed
up than that you've invented warp drive.
A bad design with a good presentation is doomed eventually. A good
design with a bad presentation is doomed immediately.
(Larrabee's Law) Half of everything you hear in a classroom is
crap. Education is figuring out which half is which.
When in doubt, document. (Documentation requirements will reach a
maximum shortly after the termination of a program.)
The schedule you develop will seem like a complete work of fiction up
until the time your customer fires you for not meeting it.
It's called a "Work Breakdown Structure" because the Work remaining
will grow until you have a Breakdown, unless you enforce some
Structure on it.
(Bowden's Law) Following a testing failure, it's always possible to
refine the analysis to show that you really had negative margins all along.
Space is a completely unforgiving environment. If you screw up the
engineering, somebody dies (and there's no partial credit because
*most* of the analysis was right...)
------- End of Forwarded Message
