19 ms·

Akin's Laws of Spacecraft Design (2011) [pdf]

345 points by tosh 11mo ago

joha4270 11mo ago
While this PDF might be new, Akin's Laws of Spacecraft Design dates back to 2003. https://web.archive.org/web/20031101212246/https://spacecraft.ssl.umd.edu/akins_laws.html https://web.archive.org/web/20031101212246/https://spacecraf...
Sharlin 11mo ago
The first law already gives a good reason why software "engineering" is rarely actually engineering.
- PxldLtd 11mo ago
  Almost all the laws are great guidance for Software dev to be honest and idiomatic to a lot of what's banded around today as good practice.
- nrhrjrjrjtntbt 11mo ago
  Oh god it can be worse when the suits try to measure everything. Some things are measurable and others are taste / gut and that is OK.
- StatsAreFun 11mo ago
  Agreed (unfortunately). It's also a good reminder IMHO to think and do engineering so we can one day be worthy of the title. Be the change you wish to see in the world. :)
deleted 11mo ago
[deleted]
z3t4 11mo ago
I like systems that are maintence free and easily replaceable. My experience so far in software engineering is that technologies die, so it should also be easy to replace the tecnology, like the hardware it runs on, the platform/os, the programming language and the framework.
- rawgabbit 11mo ago
  In the big companies I worked, it was easier to replace a system with all its dependencies than to remove a part of it. This had nothing to with tech. It was about getting buy in from the business stakeholders and the internal risk compliance department.
num42 11mo ago
TL;DR: Minimize negative(painful) notions as much as possible, ideally approaching zero, while maximizing positive (pleasurable) notions. Minimize negative(painful) notions: Uncertainty, Risk, Chaotic behavior, Randomness, Non-deterministic, Instability, Cost, Energy losses, Time consumption, Resource usage, Excessive complexity, Failure modes, Noise Maximize positive(Pleasure) notions: Reliability, Efficiency, Deterministic, Predictability, Precision, Accuracy, Verification, Validation, Safety, Stability, Simplicity (lower complexity), Robustness, Redundancy
- xtiansimon 11mo ago
  I can think of a few SaaS products in the document scanning and OCR space whose UIs are not efficient or simple, while being time consuming and, to my mind, chaotic. There should be an Akin Exit Clause from said 3-year contracts. They have zero incentives to fix or improve _anything_ during those years of servitude.
wcrossbow 11mo ago
The last and most important slide is missing. "Ignore all the advise above and do the right thing Subtext: This will take multiple lifetimes to accomplish" This is particularly important considering that some of the advice is at odds with each other and engineering is an unending juggling of tradeoffs. It's also by far the hardest to achieve both technically and socially but worth striving for.
- firesteelrain 11mo ago
  I believe that might be Law 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.”
jobjobjobjob 11mo ago
> Bhargava’s Law: Only 1 out of 10 research ideas make it into industrial practice It's a nice reflection, but what is the origin of this? Can't find another reference to this "law" online.
- beklein 11mo ago
  Not all laws are hard science laws in the sense of the second law of thermodynamics; they are, however, good approximations based on experience and, in the right context, make a bit more sense. Notes from the original author: > I've been involved in spacecraft and space systems design and development for my entire career, including teaching the senior-level capstone spacecraft design course, for ten years at MIT and now at the University of Maryland for more than a decade. These are some bits of wisdom that I have gleaned during that time, some by picking up on the experience of others, but mostly by screwing up myself. I originally wrote these up and handed them out to my senior design class, as a strong hint on how best to survive my design experience. Months later, I get a phone call from a friend in California complimenting me on the Laws, which he saw on a "joke-of-the-day" listserve. Since then, I'm aware of half a dozen sites around the world that present various editions of the Laws, and even one site which has converted them to the Laws of Certified Public Accounting. (Don't ask...) Anyone is welcome to link to these, use them, post them, send me suggestions of additional laws, but I do maintain that this is the canonical set of Akin's Laws...
barishnamazov 11mo ago
Law 20 seems to express the state of most startups these days: > "A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately."
- potato3732842 11mo ago
  That's what happens when the likely success scenario is selling out to an existing company rather than growing to be a genuinely large and long lived company.
  - nine_k 11mo ago
    There are beef companies and milk companies, depending on the way they plan to use their cash cow. (Most VC funding is used to quickly produce a beefy market share, and sell it to those who think they can milk it, or to profitably butcher it.)
    - potato3732842 11mo ago
      Trying to get milk out of the kind of cattle one raises for beef is a pretty good analogy for using an IPO to offload a questionable company onto the public.
      - metalman 11mo ago
        realy like the cattle analogy, and it can be extended further, Dexter cattle are dual use cattle, and the worlds smallest breed, so increadably popular for small acerages and single family cows, so in a way the type of thing that is terrifying for big operations, as they are not monetisable at scale, but idealy suited to a distributed network that is also a peer to peer economical exchange.
        capyba 11mo ago
        I wish I knew more about cattle to add to the analogy but I do very much appreciate it as is.
gcanyon 11mo ago
> The biggest commercial success is not the best technical design: Nokia N95 versus the first generation iPhone That’s not a good example. Neither is Beta vs VHS. The most they illustrate is a different law I am coining right here: Canyon’s Law of Design Optimization: you will inevitably choose to optimize for different metrics than your customers would wish. Don’t try to convince them they are wrong.
- JKCalhoun 11mo ago
  I had to look up the N95. Yeah, Wikipedia goes to pains to rattle off things that made it better than the iPhone, but then I looked at a photo of the device and it was clear why the iPhone "won".
  - pfisherman 11mo ago
    I has a Nokia N95. The phone itself was great. The problem was the dearth of apps. Nobody developed anything for windows mobile OS. Maybe Ballmer was not so crazy when he was running around on stage screaming “Developers, developers, developers”.
    - Tuna-Fish 11mo ago
      N95 didn't use Windows mobile. It used Symbian, and the reason there were so few apps was that the development experience was downright horrible.
  - canjobear 11mo ago
    This was the (juvenile) nerd take back then https://maddox.xmission.com/c.cgi?u=iphone/ https://maddox.xmission.com/c.cgi?u=iphone/ (Nokia E70 not N95, but still)
    - JKCalhoun 11mo ago
      That's funny. I guess the iPhone was the poseur phone, the Nokia was punk.
- 11mo ago
strawhatdev 11mo ago
> Quality thinking is more important in this profession than fast thinking. Feels true, particularly in an era where LLMs make fast thinking cheap.
einrealist 11mo ago
> The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it. (Law 23) So will Musk finally be fired in 2026?
- Geonode 11mo ago
  He promises 10, gives the world 4, but everybody else has 1, and he's hated for it.
  - erikig 11mo ago
    It's been interesting to see how often Elon is chided (even by his supporters) because his reach always seems to somehow exceed his grasp knowing full well that this is by design and not by fault.
  - zoeysmithe 11mo ago
    I'm not seeing that. The truck is a mess of a product. The self-driving is terrible compared to things like waymo, and the robot seems to be entirely fraud. Tesla cars was a good product but now lost the early lead and 2025 sales were unimpressive and certainly not remotely enough to justify the stock price. So he gives 4, which but 1 are all terrible, and is rightly criticized. Then he inserts hateful regressive politics into our collective culture as the secondary price of using/buying/supporting his brand and products. If anything, he's under-criticized and keeps failing up.
    - witx 11mo ago
      You very conveniently don't mention SpaceX the most well accomplished of his companies (and of any modern space company for that matter) -- I really don't believe SpaceX is as good as it is because of him though... And no I'm not a fan of the Musk personna.
  - nancyminusone 11mo ago
    I can't think of any breakthrough successes Musk has had within the last 5 years, unless you count helping the current president get elected. If the promising but still incomplete Starship was on the same pace as the exceptionally successful Falcon 9, it would have already delivered cargo to orbit by now. His rates appear to be slipping.
karaterobot 11mo ago
I've been quoting von Tiesenhausen's Law of Engineering Design for over a decade, since it is a great summary of why I switched from engineering to product design mid-career. That law is the one that says engineers always wind up designing the vehicle to look like the initial artist's concept. I didn't engineer spacecraft, but on web projects I noticed that whoever made the documents furthest upstream had a ridiculous amount of influence over the outcome of the product. Even just being the one taking notes in the first meeting gives you leverage in a process which, despite claims of being agile, is definitively path-dependent most of the time.
GlenTheMachine 11mo ago
I’m Henshaw (#37). AMA.
- getpost 11mo ago
  Tell us. What inspired you to say this?
  - ycombiredd 11mo ago
    I think he's saying that he (GlenTheMachine) is Glen Henshaw, "space roboticist", and (understandably) was a bit excited that a somewhat famous document contains a "law" bearing his name as attribution was posted by this water cooler. A way to get some minor attention for it in a comment thread full of like-minded users, and probably offer a genuine (and also maybe coy/tongue-in-cheek) offer to answer questions about that specific line item law. I like that he waved from the crowd in this way, if only for the "huh. Small world" moment I had reading his comment.
  - GlenTheMachine 11mo ago
    I was a grad student in Dave Akin's lab from 1994-2003. Like many labs, we had a journal club. Once a week (Wednesday, I think) somebody would give a presentation over lunch on a paper they'd read. We would get takeout Chinese and eat while discussing the paper. On this particular Wednesday the presentation was on a failed spacecraft program. It's been a long time, but I think it was probably this paper: https://llis.nasa.gov/llis_lib/pdf/1009464main1_0641-mr.pdf https://llis.nasa.gov/llis_lib/pdf/1009464main1_0641-mr.pdf which is the initial failure analysis of the Mars Climate Orbiter (1999), which famously crashed into Mars during its orbital insertion burn because JPL specifications were in metric, but Lockheed wrote code in imperial units, and as a result there was a failure to properly convert between newtons and pounds. One fact of note was that the the team responsible for spacecraft navigation had already observed anomalous trajectory data but their reports were ignored because they didn't follow program guidelines for filling out the paperwork to document the observations, so the insertion burn went ahead heedless of what the spacecraft's behavior was trying to tell them. Ultimately, the loss of mission was a result of unclear responsibility for ownership of the orbital maneuvering software, including the mission requirements that traced to the software, the development of the software derived from those requirements, tests to validate the software, and reports from users of the software that it was behaving unexpectedly. I was trying to be funny, and turned the statement around from "clear lines of responsibility" to "clear lines of blame".
aj7 11mo ago
I have found that my best designs, few and far between, enter a period where they get simpler as they are completed. And my worst or failed designs keep getting more complex as I go on.
- iancmceachern 11mo ago
  This is the way. "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage to move in the opposite direction." https://www.goodreads.com/quotes/14789-any-intelligent-fool-can-make-things-bigger-more-complex-and https://www.goodreads.com/quotes/14789-any-intelligent-fool-...
AnimalMuppet 11mo ago
My contributions/spins on this: The most general problem cannot be solved. (If you don't limit scope, you will never finish. You won't even finish the design.) If you want it bad, that's how you're going to get it. (That is, rushing a project means you get crummy results. This may be "Hanka's Law", because I first heard it from Steve Hanka, but it may not be original to him.)
sbondaryev 11mo ago
Law 20: A good design with a bad presentation is doomed immediately I definitely struggle with this. I run a math education site and I usually focus heavily on technical accuracy but underestimate the presentation. Hard lesson that being "right" isn't enough if the delivery is clunky.
- elzbardico 11mo ago
  Something I've learned, loosely related: Adding "just a few fundamental equations" to a presentation won't make your case more compelling to business stakeholders. You lose roughly 10% of engagement for every greek letter in a slide.
- pklausler 11mo ago
  I have learned to think about this problem thus: there's reality, and then there's perceptions, and communication is a task of persuading somebody else's perception to somehow align with yours. When you both view reality clearly, it's best to present simple facts and their implications. The other three cases are education, bullshitting, and nonsense, and it's best to involve a professional.
- i_am_a_peasant 11mo ago
  care to share the site? :)
  - sbondaryev 11mo ago
    yeah, i learned this the hard way. I tried producthunt, indie hackers, linkedIn, twitter even instagram thinking distribution was the issue. Turns out it was mostly audience and presentation. Math/educational content just doesn't travel well on those channels unless it’s tailored very carefully. Being right wasnt enough if the delivery didn’t match how people consume it.
    - i_am_a_peasant 11mo ago
      I’m guessing that’s a no.
MinimalAction 11mo ago
> Bhargava’s Law: Only 1 out of 10 research ideas make it into industrial practice. Not sure of the source for this. Nevertheless, this is ridiculously high percentage of projects that ever see an industrial angle, at least in basic sciences. Perhaps, this is restricted to engineering.
zoeysmithe 11mo ago
I'm not sure if the nokia example works. When the nokia launched the screen technology, SoC horsepower, battery tech, etc just wasn't there to make an iphone. Even when the 2007 iphone launched it was a bit of mess, with the first gen not being 3G when other phones were and no app store, but instead devs were told to write web apps. If anything, some of these early smartphones were pushing a lot of limits considering the hardware restraints. Its just by the time the iphone came out, these restraints were lessened and Apple did a good job using these technologies.
beefman 11mo ago
Last archived working original: https://web.archive.org/web/20250808213459/https://spacecraft.ssl.umd.edu/akins_laws.html https://web.archive.org/web/20250808213459/https://spacecraf...
pjdesno 11mo ago
> "Trellis coded modulation got this rate up to 50 kilobaud by the 1990s" Not quite, and an interesting story that fits these engineering maxims better than you might think. An analog channel with the bandwidth and SNR characteristics of a landline phone line has (IIRC) a Shannon capacity of 30-something kbit/s, which was closely approached with V.34, which used trellis coded modulation plus basically every other coding and equalization mechanism they knew of at the time to get to 33.6kb/s on a good day. But... by the 80s or so the phone system was only analog for the "last mile" to the home - the rest of the system was digital, sending 8-bit samples (using logarithmic mu-law encoding) at a sampling rate of 8000 samples/s, and if you had a bunch of phone lines coming into a facility you could get those lines delivered over a digital T1 link. Eventually someone realized that if your ISP-side modem directly outputs digital audio, the downstream channel capacity is significantly higher - in theory the limit is probably 64000 bit/s, i.e. the bit rate of the digital link, although V.90 could only achieve about 56000 b/s in theory, and more like 53kb/s in practice. (in particular, the FCC limited the total signal power, which means not all 64000 combinations of bits in a second of audio would be allowable) I worked with modem modulation folks when I was a co-op student in the mid-80s. They had spent their lives thinking about the world in terms of analog channels, and it took some serious out-of-the-box thinking on someone's part to realize that the channel was no longer analog, and that you could take advantage of that. A few years later those same folks all ended up working on cable modems, and it was back to the purely analog world again.
- computator 11mo ago
  > if your ISP-side modem directly outputs digital audio, the downstream channel capacity is significantly higher But why is it higher? It's still an analog channel (the last mile from the ISP to your house), right? Doesn't it get filtered? So isn't it still subject to the Shannon-Nyquist limit? Here's an ASCII drawing of which parts are digital vs analog as I understood your explanation: Rest of world<--- digital--->Telco<---digital--->ISPmodem<---analog--->HomeModem Suppose you're saying that the link between the ISPmodem and the HomeModem is a bare unfiltered copper wire. In that case, I have a different question: Couldn't you send data at megabits per seconds over a mile long copper wire without using modems at all (using just UARTs?). I hope you can clear up my confusion.
putzdown 11mo ago
What's the story with the Avro C102 (per law 20)? What's the connection with "A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately"? I'm intrigued.
- nxobject 11mo ago
  Two references come to mind – the first is that the Avro C102 was beat by the de Havilland Comet, which was an example of a bad design with a good presentation. It had a series of mysterious hull losses that were eventually attributed metal fatigue accumulating around a square cut-out in the hull. https://en.wikipedia.org/wiki/De_Havilland_Comet#Comet_disasters_of_1954 https://en.wikipedia.org/wiki/De_Havilland_Comet#Comet_disas... The second, more depressingly, is that the Avro C102 was cancelled to redirect resources to the Avro Arrow: Canada's mythical last jet fighter, of which only a handful were produced before the program was (painfully) cancelled, and Avro wound up. IIRC, the Canadian government was the main-to-sole bankroller of the project, and ballistic missiles became increasingly more important.
  - Aloha 11mo ago
    I'll argue that Comet was a good design, but with too many unknowns being solved at once - while we had limited experience with pressurization the comet took more cycles, and had a much higher service ceiling. I dont think the Comet was a materially worse design than the Avro C102 (both aircraft are similar) and the C102 may very well have had other unknown issues only to be found if it went into series production.
inamberclad 11mo ago
I have these taped up above my desk at work. I've been able to point to at least half of them from one time or another
OrvalWintermute 11mo ago
My general issue with this is that it is overly hardware centric and not as accurate when it comes to Aerospace Software Law 4 Bhargava’s Law: Only 1 out of 10 research ideas make it into industrial practice is wrong anecdotally particularly when it relates to software. Law 13 is flat-out wrong in that there is a huge amount of potential SWaP trades & innovation trades to be made, and the changing requirements environment where it is easy to predict where a requirement will be, despite a space program with a legacy requirements baseline. An example of Law 13 errors would be the JPSS security redesign campaigns, and a less ideal retrofit
iancmceachern 11mo ago
Lol, see the recent HN post on TRIZ and my comment there pointing folks to this. And here I complete the cycle.
cainxinth 11mo ago
Adapted to writing: https://en.wikipedia.org/wiki/Wikipedia:Akin%27s_Laws_of_Article_Writing https://en.wikipedia.org/wiki/Wikipedia:Akin%27s_Laws_of_Art...
buildsjets 11mo ago
Buildsjets laws of spacecraft design: The propellant storage shall be designed and located such that a catastrophic failure of propellant storage will not damage the passenger compartment. The propulsion system shall be designed and located such that a catastrophic failure of the propulsion system will not damage the propellant storage or the passenger compartment. The launch system shall be designed to ensure a minimum of two survivable abort alternatives at each phase of the flight. Each abort scenario shall be validated by a flight test before certifying the system for general use. The re-entry system shall be designed so there are no single points of failure. If single points of failure are unavoidable, a method pf inspection or surveillance shall be developed to detect the failure prior to de-orbit. In-orbit repair procedures for foreseeable types of damage shall be developed and validated prior to certifying the system for general use. Yeah, this is all 20/20 hindsight. But we really need to avoid developing ANYTHING similar to the STS in the future. I truly believe it set us back by 50 years.
deleted 11mo ago
[deleted]
dvrp 11mo ago
“Avoid the temptation to believe a completely new product will always be better than an evolution of an old product”.
deleted 11mo ago
[deleted]
ricksunny 11mo ago
These are awesome. I took that capstone spacecraft design course at MIT in 2003, and can't recall encountering this list (based on the archive snapshot, he would have shifted on to UMD more than thirty years prior). The project was satellite-focused rather than launch vehicle, so maybe his instructions were imbued implicitly into the course? • Much of the design-conservative ethos permeates aerospace development. It's unsurprising that astronautics evolution has been slow at least until Elon came along. I wonder how Elon / SpaceX folks would respond to these laws esp. #39 (avoid designing launch vehicles). • Also the one that was conspicuously maintained at the end across the different archived versions: "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...)" It's notable that the wayback machine's first crawl of Akin's list is late 2003 (so presumably when the source page went live) the year in which the Columbia disaster took place.
- Nevermark 11mo ago
  > I wonder how Elon / SpaceX folks would respond to these laws esp. #39 (avoid designing launch vehicles). Perhaps, based on specific context, let the Law's vote! > Law 11: Sometimes, the fastest way to get to the end is to throw everything out and start over. > Law 16: The previous people [...] did not have a direct pipeline to the wisdom of the ages. There is therefore no reason to believe their analysis [was optimal]. > Law 31 (Mo's Law of Evolutionary Development): [...] understand the fundamental limitations of [the existing] technology/approach. IMHO: Law 31 is the kicker. That triggers Law 11. With general support from Law 16.
  - JumpCrisscross 11mo ago
    > > I wonder how Elon / SpaceX folks would respond to these laws esp. #39 (avoid designing launch vehicles) SpaceX has designed 3 (four if you include Falcon 1) launch vehicles: Falcon 1, Falcon 9, Falcon Heavy and Starship. The first three run the same engine family and are arguably in the same vehicle family. SpaceX has absolutely embraced avoiding designing new launch vehicles (and even major components) until the fundamental limitations of the existing approach are exceeded.
dctoedt 11mo ago
> Ask any industrial engineer about MBAs (in Law 7) In the Navy-nuke world there was a saying, purportedly by Admiral Rickover, about non-technical "managers": There but for the grace of God goes God.
jaynate 11mo ago
Many of these laws can be applied to any discipline. Business, politics, etc.
jmux 11mo ago
when I was at JPL, Akins laws (html version) were linked on the front page of the wiki. still one of the best (funniest) sources of engineering tips I’ve come across. My favorite is still Mar’s law: > Mar's Law) Everything is linear if plotted log-log with a fat magic marker.

345 points by tosh 11mo ago

While this PDF might be new, Akin's Laws of Spacecraft Design dates back to 2003. https://web.archive.org/web/20031101212246/https://spacecraft.ssl.umd.edu/akins_laws.html https://web.archive.org/web/20031101212246/https://spacecraf...

Sharlin 11mo ago

The first law already gives a good reason why software "engineering" is rarely actually engineering.

PxldLtd 11mo ago
Almost all the laws are great guidance for Software dev to be honest and idiomatic to a lot of what's banded around today as good practice.
nrhrjrjrjtntbt 11mo ago
Oh god it can be worse when the suits try to measure everything. Some things are measurable and others are taste / gut and that is OK.
StatsAreFun 11mo ago
Agreed (unfortunately). It's also a good reminder IMHO to think and do engineering so we can one day be worthy of the title. Be the change you wish to see in the world. :)

deleted 11mo ago

[deleted]

z3t4 11mo ago

I like systems that are maintence free and easily replaceable. My experience so far in software engineering is that technologies die, so it should also be easy to replace the tecnology, like the hardware it runs on, the platform/os, the programming language and the framework.

rawgabbit 11mo ago
In the big companies I worked, it was easier to replace a system with all its dependencies than to remove a part of it. This had nothing to with tech. It was about getting buy in from the business stakeholders and the internal risk compliance department.

num42 11mo ago

TL;DR: Minimize negative(painful) notions as much as possible, ideally approaching zero, while maximizing positive (pleasurable) notions. Minimize negative(painful) notions: Uncertainty, Risk, Chaotic behavior, Randomness, Non-deterministic, Instability, Cost, Energy losses, Time consumption, Resource usage, Excessive complexity, Failure modes, Noise Maximize positive(Pleasure) notions: Reliability, Efficiency, Deterministic, Predictability, Precision, Accuracy, Verification, Validation, Safety, Stability, Simplicity (lower complexity), Robustness, Redundancy

xtiansimon 11mo ago
I can think of a few SaaS products in the document scanning and OCR space whose UIs are not efficient or simple, while being time consuming and, to my mind, chaotic. There should be an Akin Exit Clause from said 3-year contracts. They have zero incentives to fix or improve _anything_ during those years of servitude.

wcrossbow 11mo ago

The last and most important slide is missing. "Ignore all the advise above and do the right thing Subtext: This will take multiple lifetimes to accomplish" This is particularly important considering that some of the advice is at odds with each other and engineering is an unending juggling of tradeoffs. It's also by far the hardest to achieve both technically and socially but worth striving for.

firesteelrain 11mo ago
I believe that might be Law 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.”

jobjobjobjob 11mo ago

> Bhargava’s Law: Only 1 out of 10 research ideas make it into industrial practice It's a nice reflection, but what is the origin of this? Can't find another reference to this "law" online.

beklein 11mo ago
Not all laws are hard science laws in the sense of the second law of thermodynamics; they are, however, good approximations based on experience and, in the right context, make a bit more sense. Notes from the original author: > I've been involved in spacecraft and space systems design and development for my entire career, including teaching the senior-level capstone spacecraft design course, for ten years at MIT and now at the University of Maryland for more than a decade. These are some bits of wisdom that I have gleaned during that time, some by picking up on the experience of others, but mostly by screwing up myself. I originally wrote these up and handed them out to my senior design class, as a strong hint on how best to survive my design experience. Months later, I get a phone call from a friend in California complimenting me on the Laws, which he saw on a "joke-of-the-day" listserve. Since then, I'm aware of half a dozen sites around the world that present various editions of the Laws, and even one site which has converted them to the Laws of Certified Public Accounting. (Don't ask...) Anyone is welcome to link to these, use them, post them, send me suggestions of additional laws, but I do maintain that this is the canonical set of Akin's Laws...

barishnamazov 11mo ago

Law 20 seems to express the state of most startups these days: > "A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately."

potato3732842 11mo ago
That's what happens when the likely success scenario is selling out to an existing company rather than growing to be a genuinely large and long lived company.
- nine_k 11mo ago
  There are beef companies and milk companies, depending on the way they plan to use their cash cow. (Most VC funding is used to quickly produce a beefy market share, and sell it to those who think they can milk it, or to profitably butcher it.)
  - potato3732842 11mo ago
    Trying to get milk out of the kind of cattle one raises for beef is a pretty good analogy for using an IPO to offload a questionable company onto the public.
    - metalman 11mo ago
      realy like the cattle analogy, and it can be extended further, Dexter cattle are dual use cattle, and the worlds smallest breed, so increadably popular for small acerages and single family cows, so in a way the type of thing that is terrifying for big operations, as they are not monetisable at scale, but idealy suited to a distributed network that is also a peer to peer economical exchange.
      - capyba 11mo ago
        I wish I knew more about cattle to add to the analogy but I do very much appreciate it as is.

gcanyon 11mo ago

> The biggest commercial success is not the best technical design: Nokia N95 versus the first generation iPhone That’s not a good example. Neither is Beta vs VHS. The most they illustrate is a different law I am coining right here: Canyon’s Law of Design Optimization: you will inevitably choose to optimize for different metrics than your customers would wish. Don’t try to convince them they are wrong.

JKCalhoun 11mo ago
I had to look up the N95. Yeah, Wikipedia goes to pains to rattle off things that made it better than the iPhone, but then I looked at a photo of the device and it was clear why the iPhone "won".
- pfisherman 11mo ago
  I has a Nokia N95. The phone itself was great. The problem was the dearth of apps. Nobody developed anything for windows mobile OS. Maybe Ballmer was not so crazy when he was running around on stage screaming “Developers, developers, developers”.
  - Tuna-Fish 11mo ago
    N95 didn't use Windows mobile. It used Symbian, and the reason there were so few apps was that the development experience was downright horrible.
- canjobear 11mo ago
  This was the (juvenile) nerd take back then https://maddox.xmission.com/c.cgi?u=iphone/ https://maddox.xmission.com/c.cgi?u=iphone/ (Nokia E70 not N95, but still)
  - JKCalhoun 11mo ago
    That's funny. I guess the iPhone was the poseur phone, the Nokia was punk.
11mo ago

strawhatdev 11mo ago

> Quality thinking is more important in this profession than fast thinking. Feels true, particularly in an era where LLMs make fast thinking cheap.

einrealist 11mo ago

> The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it. (Law 23) So will Musk finally be fired in 2026?

Geonode 11mo ago
He promises 10, gives the world 4, but everybody else has 1, and he's hated for it.
- erikig 11mo ago
  It's been interesting to see how often Elon is chided (even by his supporters) because his reach always seems to somehow exceed his grasp knowing full well that this is by design and not by fault.
- zoeysmithe 11mo ago
  I'm not seeing that. The truck is a mess of a product. The self-driving is terrible compared to things like waymo, and the robot seems to be entirely fraud. Tesla cars was a good product but now lost the early lead and 2025 sales were unimpressive and certainly not remotely enough to justify the stock price. So he gives 4, which but 1 are all terrible, and is rightly criticized. Then he inserts hateful regressive politics into our collective culture as the secondary price of using/buying/supporting his brand and products. If anything, he's under-criticized and keeps failing up.
  - witx 11mo ago
    You very conveniently don't mention SpaceX the most well accomplished of his companies (and of any modern space company for that matter) -- I really don't believe SpaceX is as good as it is because of him though... And no I'm not a fan of the Musk personna.
- nancyminusone 11mo ago
  I can't think of any breakthrough successes Musk has had within the last 5 years, unless you count helping the current president get elected. If the promising but still incomplete Starship was on the same pace as the exceptionally successful Falcon 9, it would have already delivered cargo to orbit by now. His rates appear to be slipping.

karaterobot 11mo ago

I've been quoting von Tiesenhausen's Law of Engineering Design for over a decade, since it is a great summary of why I switched from engineering to product design mid-career. That law is the one that says engineers always wind up designing the vehicle to look like the initial artist's concept. I didn't engineer spacecraft, but on web projects I noticed that whoever made the documents furthest upstream had a ridiculous amount of influence over the outcome of the product. Even just being the one taking notes in the first meeting gives you leverage in a process which, despite claims of being agile, is definitively path-dependent most of the time.

GlenTheMachine 11mo ago

I’m Henshaw (#37). AMA.

getpost 11mo ago
Tell us. What inspired you to say this?
- ycombiredd 11mo ago
  I think he's saying that he (GlenTheMachine) is Glen Henshaw, "space roboticist", and (understandably) was a bit excited that a somewhat famous document contains a "law" bearing his name as attribution was posted by this water cooler. A way to get some minor attention for it in a comment thread full of like-minded users, and probably offer a genuine (and also maybe coy/tongue-in-cheek) offer to answer questions about that specific line item law. I like that he waved from the crowd in this way, if only for the "huh. Small world" moment I had reading his comment.
- GlenTheMachine 11mo ago
  I was a grad student in Dave Akin's lab from 1994-2003. Like many labs, we had a journal club. Once a week (Wednesday, I think) somebody would give a presentation over lunch on a paper they'd read. We would get takeout Chinese and eat while discussing the paper. On this particular Wednesday the presentation was on a failed spacecraft program. It's been a long time, but I think it was probably this paper: https://llis.nasa.gov/llis_lib/pdf/1009464main1_0641-mr.pdf https://llis.nasa.gov/llis_lib/pdf/1009464main1_0641-mr.pdf which is the initial failure analysis of the Mars Climate Orbiter (1999), which famously crashed into Mars during its orbital insertion burn because JPL specifications were in metric, but Lockheed wrote code in imperial units, and as a result there was a failure to properly convert between newtons and pounds. One fact of note was that the the team responsible for spacecraft navigation had already observed anomalous trajectory data but their reports were ignored because they didn't follow program guidelines for filling out the paperwork to document the observations, so the insertion burn went ahead heedless of what the spacecraft's behavior was trying to tell them. Ultimately, the loss of mission was a result of unclear responsibility for ownership of the orbital maneuvering software, including the mission requirements that traced to the software, the development of the software derived from those requirements, tests to validate the software, and reports from users of the software that it was behaving unexpectedly. I was trying to be funny, and turned the statement around from "clear lines of responsibility" to "clear lines of blame".

aj7 11mo ago

I have found that my best designs, few and far between, enter a period where they get simpler as they are completed. And my worst or failed designs keep getting more complex as I go on.

iancmceachern 11mo ago
This is the way. "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage to move in the opposite direction." https://www.goodreads.com/quotes/14789-any-intelligent-fool-can-make-things-bigger-more-complex-and https://www.goodreads.com/quotes/14789-any-intelligent-fool-...

AnimalMuppet 11mo ago

My contributions/spins on this: The most general problem cannot be solved. (If you don't limit scope, you will never finish. You won't even finish the design.) If you want it bad, that's how you're going to get it. (That is, rushing a project means you get crummy results. This may be "Hanka's Law", because I first heard it from Steve Hanka, but it may not be original to him.)

sbondaryev 11mo ago

Law 20: A good design with a bad presentation is doomed immediately I definitely struggle with this. I run a math education site and I usually focus heavily on technical accuracy but underestimate the presentation. Hard lesson that being "right" isn't enough if the delivery is clunky.

elzbardico 11mo ago
Something I've learned, loosely related: Adding "just a few fundamental equations" to a presentation won't make your case more compelling to business stakeholders. You lose roughly 10% of engagement for every greek letter in a slide.
pklausler 11mo ago
I have learned to think about this problem thus: there's reality, and then there's perceptions, and communication is a task of persuading somebody else's perception to somehow align with yours. When you both view reality clearly, it's best to present simple facts and their implications. The other three cases are education, bullshitting, and nonsense, and it's best to involve a professional.
i_am_a_peasant 11mo ago
care to share the site? :)
- sbondaryev 11mo ago
  yeah, i learned this the hard way. I tried producthunt, indie hackers, linkedIn, twitter even instagram thinking distribution was the issue. Turns out it was mostly audience and presentation. Math/educational content just doesn't travel well on those channels unless it’s tailored very carefully. Being right wasnt enough if the delivery didn’t match how people consume it.
  - i_am_a_peasant 11mo ago
    I’m guessing that’s a no.

MinimalAction 11mo ago

> Bhargava’s Law: Only 1 out of 10 research ideas make it into industrial practice. Not sure of the source for this. Nevertheless, this is ridiculously high percentage of projects that ever see an industrial angle, at least in basic sciences. Perhaps, this is restricted to engineering.

zoeysmithe 11mo ago

I'm not sure if the nokia example works. When the nokia launched the screen technology, SoC horsepower, battery tech, etc just wasn't there to make an iphone. Even when the 2007 iphone launched it was a bit of mess, with the first gen not being 3G when other phones were and no app store, but instead devs were told to write web apps. If anything, some of these early smartphones were pushing a lot of limits considering the hardware restraints. Its just by the time the iphone came out, these restraints were lessened and Apple did a good job using these technologies.

beefman 11mo ago

Last archived working original: https://web.archive.org/web/20250808213459/https://spacecraft.ssl.umd.edu/akins_laws.html https://web.archive.org/web/20250808213459/https://spacecraf...

pjdesno 11mo ago

> "Trellis coded modulation got this rate up to 50 kilobaud by the 1990s" Not quite, and an interesting story that fits these engineering maxims better than you might think. An analog channel with the bandwidth and SNR characteristics of a landline phone line has (IIRC) a Shannon capacity of 30-something kbit/s, which was closely approached with V.34, which used trellis coded modulation plus basically every other coding and equalization mechanism they knew of at the time to get to 33.6kb/s on a good day. But... by the 80s or so the phone system was only analog for the "last mile" to the home - the rest of the system was digital, sending 8-bit samples (using logarithmic mu-law encoding) at a sampling rate of 8000 samples/s, and if you had a bunch of phone lines coming into a facility you could get those lines delivered over a digital T1 link. Eventually someone realized that if your ISP-side modem directly outputs digital audio, the downstream channel capacity is significantly higher - in theory the limit is probably 64000 bit/s, i.e. the bit rate of the digital link, although V.90 could only achieve about 56000 b/s in theory, and more like 53kb/s in practice. (in particular, the FCC limited the total signal power, which means not all 64000 combinations of bits in a second of audio would be allowable) I worked with modem modulation folks when I was a co-op student in the mid-80s. They had spent their lives thinking about the world in terms of analog channels, and it took some serious out-of-the-box thinking on someone's part to realize that the channel was no longer analog, and that you could take advantage of that. A few years later those same folks all ended up working on cable modems, and it was back to the purely analog world again.

computator 11mo ago
> if your ISP-side modem directly outputs digital audio, the downstream channel capacity is significantly higher But why is it higher? It's still an analog channel (the last mile from the ISP to your house), right? Doesn't it get filtered? So isn't it still subject to the Shannon-Nyquist limit? Here's an ASCII drawing of which parts are digital vs analog as I understood your explanation: Rest of world<--- digital--->Telco<---digital--->ISPmodem<---analog--->HomeModem Suppose you're saying that the link between the ISPmodem and the HomeModem is a bare unfiltered copper wire. In that case, I have a different question: Couldn't you send data at megabits per seconds over a mile long copper wire without using modems at all (using just UARTs?). I hope you can clear up my confusion.

putzdown 11mo ago

What's the story with the Avro C102 (per law 20)? What's the connection with "A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately"? I'm intrigued.

nxobject 11mo ago
Two references come to mind – the first is that the Avro C102 was beat by the de Havilland Comet, which was an example of a bad design with a good presentation. It had a series of mysterious hull losses that were eventually attributed metal fatigue accumulating around a square cut-out in the hull. https://en.wikipedia.org/wiki/De_Havilland_Comet#Comet_disasters_of_1954 https://en.wikipedia.org/wiki/De_Havilland_Comet#Comet_disas... The second, more depressingly, is that the Avro C102 was cancelled to redirect resources to the Avro Arrow: Canada's mythical last jet fighter, of which only a handful were produced before the program was (painfully) cancelled, and Avro wound up. IIRC, the Canadian government was the main-to-sole bankroller of the project, and ballistic missiles became increasingly more important.
- Aloha 11mo ago
  I'll argue that Comet was a good design, but with too many unknowns being solved at once - while we had limited experience with pressurization the comet took more cycles, and had a much higher service ceiling. I dont think the Comet was a materially worse design than the Avro C102 (both aircraft are similar) and the C102 may very well have had other unknown issues only to be found if it went into series production.

inamberclad 11mo ago

I have these taped up above my desk at work. I've been able to point to at least half of them from one time or another

OrvalWintermute 11mo ago

My general issue with this is that it is overly hardware centric and not as accurate when it comes to Aerospace Software Law 4 Bhargava’s Law: Only 1 out of 10 research ideas make it into industrial practice is wrong anecdotally particularly when it relates to software. Law 13 is flat-out wrong in that there is a huge amount of potential SWaP trades & innovation trades to be made, and the changing requirements environment where it is easy to predict where a requirement will be, despite a space program with a legacy requirements baseline. An example of Law 13 errors would be the JPSS security redesign campaigns, and a less ideal retrofit

iancmceachern 11mo ago

Lol, see the recent HN post on TRIZ and my comment there pointing folks to this. And here I complete the cycle.

cainxinth 11mo ago

Adapted to writing: https://en.wikipedia.org/wiki/Wikipedia:Akin%27s_Laws_of_Article_Writing https://en.wikipedia.org/wiki/Wikipedia:Akin%27s_Laws_of_Art...

buildsjets 11mo ago

Buildsjets laws of spacecraft design: The propellant storage shall be designed and located such that a catastrophic failure of propellant storage will not damage the passenger compartment. The propulsion system shall be designed and located such that a catastrophic failure of the propulsion system will not damage the propellant storage or the passenger compartment. The launch system shall be designed to ensure a minimum of two survivable abort alternatives at each phase of the flight. Each abort scenario shall be validated by a flight test before certifying the system for general use. The re-entry system shall be designed so there are no single points of failure. If single points of failure are unavoidable, a method pf inspection or surveillance shall be developed to detect the failure prior to de-orbit. In-orbit repair procedures for foreseeable types of damage shall be developed and validated prior to certifying the system for general use. Yeah, this is all 20/20 hindsight. But we really need to avoid developing ANYTHING similar to the STS in the future. I truly believe it set us back by 50 years.

deleted 11mo ago

[deleted]

dvrp 11mo ago

“Avoid the temptation to believe a completely new product will always be better than an evolution of an old product”.

deleted 11mo ago

[deleted]

ricksunny 11mo ago

These are awesome. I took that capstone spacecraft design course at MIT in 2003, and can't recall encountering this list (based on the archive snapshot, he would have shifted on to UMD more than thirty years prior). The project was satellite-focused rather than launch vehicle, so maybe his instructions were imbued implicitly into the course? • Much of the design-conservative ethos permeates aerospace development. It's unsurprising that astronautics evolution has been slow at least until Elon came along. I wonder how Elon / SpaceX folks would respond to these laws esp. #39 (avoid designing launch vehicles). • Also the one that was conspicuously maintained at the end across the different archived versions: "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...)" It's notable that the wayback machine's first crawl of Akin's list is late 2003 (so presumably when the source page went live) the year in which the Columbia disaster took place.

Nevermark 11mo ago
> I wonder how Elon / SpaceX folks would respond to these laws esp. #39 (avoid designing launch vehicles). Perhaps, based on specific context, let the Law's vote! > Law 11: Sometimes, the fastest way to get to the end is to throw everything out and start over. > Law 16: The previous people [...] did not have a direct pipeline to the wisdom of the ages. There is therefore no reason to believe their analysis [was optimal]. > Law 31 (Mo's Law of Evolutionary Development): [...] understand the fundamental limitations of [the existing] technology/approach. IMHO: Law 31 is the kicker. That triggers Law 11. With general support from Law 16.
- JumpCrisscross 11mo ago
  > > I wonder how Elon / SpaceX folks would respond to these laws esp. #39 (avoid designing launch vehicles) SpaceX has designed 3 (four if you include Falcon 1) launch vehicles: Falcon 1, Falcon 9, Falcon Heavy and Starship. The first three run the same engine family and are arguably in the same vehicle family. SpaceX has absolutely embraced avoiding designing new launch vehicles (and even major components) until the fundamental limitations of the existing approach are exceeded.

dctoedt 11mo ago

> Ask any industrial engineer about MBAs (in Law 7) In the Navy-nuke world there was a saying, purportedly by Admiral Rickover, about non-technical "managers": There but for the grace of God goes God.

jaynate 11mo ago

Many of these laws can be applied to any discipline. Business, politics, etc.

jmux 11mo ago

when I was at JPL, Akins laws (html version) were linked on the front page of the wiki. still one of the best (funniest) sources of engineering tips I’ve come across. My favorite is still Mar’s law: > Mar's Law) Everything is linear if plotted log-log with a fat magic marker.