[HN Gopher] Akin's Laws of Spacecraft Design [pdf] (2011)
___________________________________________________________________
Akin's Laws of Spacecraft Design [pdf] (2011)
Author : tosh
Score : 243 points
Date : 2025-12-31 10:12 UTC (12 hours ago)
(HTM) web link (www.ece.uvic.ca)
(TXT) w3m dump (www.ece.uvic.ca)
| joha4270 wrote:
| While this PDF might be new, Akin's Laws of Spacecraft Design
| dates back to 2003.
|
| https://web.archive.org/web/20031101212246/https://spacecraf...
| Sharlin wrote:
| The first law already gives a good reason why software
| "engineering" is rarely actually engineering.
| PxldLtd wrote:
| 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 wrote:
| 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 wrote:
| 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. :)
| z3t4 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| jobjobjobjob wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| noduerme wrote:
| Hiring salesmen to talk to other salesmen is always the
| sleaziest part of doing anything productive. You could say the
| same thing about opening a restaurant.
| __patchbit__ wrote:
| Petro Tyschtschenko is a good salesman.
| https://youtu.be/0-z1TaNx7TM
| martin-t wrote:
| I'd add to that: If you recognize a good design presented
| poorly, be the one to stand up and present it well, otherwise
| you will be stuck with the bad one.
| sho_hn wrote:
| This is key to fulfilling a senior tech leadership role and
| substantially what people expect to pay you for, if you ever
| wonder what the mysterious "impact" really means.
| nine_k wrote:
| Imagine that you're a highly intellectual, highly technical,
| and highly responsible person in control of large sums of
| governmental or corporate money. You don't want to waste the
| money, you want stellar results (in spacecraft industry, maybe
| literally so).
|
| Would you assign a large sum of money to a group that cannot
| present their design clearly, neatly, and concisely? If they
| are struggling even with that, would you trust them to be good
| at actually designing a spacecraft soundly, economically, and
| in a reasonable time?
|
| "If you can't explain it to a five-years-old, you likely do not
| understand it yourself", said one of the greatest modern
| scientists, who also was notoriously good at explaining things.
| pklausler wrote:
| I think that Feynman was talking about preparing a freshman-
| level lecture for Caltech-standard freshmen, but maybe you
| have somebody else in mind.
| Nevermark wrote:
| I would say: You either don't understand your subject, or
| don't understand your audience, if you can't explain your
| subject to your audience, at the highest level they can
| understand, coherently.
|
| The average person can understand anything ... at some
| level. Being able to match that level is positive evidence
| (but not proof) of competence.
| nine_k wrote:
| I think if you understand something _really_ well
| (anything: the law of gravity, the Curry-Howard
| isomorphism, electrolytic dissociation, general
| relativity,...), you can find a bunch of comparisons, or
| metaphors, or other ways to explain it so that an
| interested five-years-old will get a rough idea. A very
| rough idea indeed, but one that could allow them to ask
| qualitatively reasonable questions, and that forms an
| intuition which helps during a real study.
| gcanyon wrote:
| > 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 wrote:
| 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 wrote:
| 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".
| jltsiren wrote:
| That's not a good example, but for a different reason: the N95
| outsold the original iPhone.
|
| The original iPhone was a promising proof of concept. It got
| the form factor and the interface right, but the actual device
| was underwhelming. It had no 3G, no GPS, no third-party apps,
| and a weak camera. iPhone 3G added all the features competitors
| already had (apart from a good camera) and became a much bigger
| commercial success.
| elzbardico wrote:
| The N95 outsold the IPhone because it had a good camera and
| was cheaper, and got even cheaper with the phone companies
| subsidy.
|
| But I'd be surprised if Apple didn't have a beefier profit
| with the IPhone compared to Nokia with the N95.
| JumpCrisscross wrote:
| > _That's not a good example_
|
| It's a great example. One can list a litany of technical
| specifications on which the N95 is superior. That, however,
| doesn't make it a superior product.
| strawhatdev wrote:
| > Quality thinking is more important in this profession than fast
| thinking.
|
| Feels true, particularly in an era where LLMs make fast thinking
| cheap.
| einrealist wrote:
| > 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 wrote:
| He promises 10, gives the world 4, but everybody else has 1,
| and he's hated for it.
| erikig wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| gus_massa wrote:
| https://en.wikipedia.org/wiki/SpaceX_Crew-9
|
| It's not a breakthrough, because it could have been done
| with the Soyutz (except the part of reusing the launcher),
| but it's enough for " _He promises 10, gives the world 4,
| but everybody else has 1, and he 's hated for it._"
| karaterobot wrote:
| 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 wrote:
| I'm Henshaw (#37). AMA.
| getpost wrote:
| Tell us. What inspired you to say this?
| ycombiredd wrote:
| 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.
| aj7 wrote:
| 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 wrote:
| 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-...
| AnimalMuppet wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| care to share the site? :)
| sbondaryev wrote:
| 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.
| MinimalAction wrote:
| > 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 wrote:
| 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 wrote:
| Last archived working original:
| https://web.archive.org/web/20250808213459/https://spacecraf...
| pjdesno wrote:
| > "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 wrote:
| > _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.
| db48x wrote:
| No, it's more like HomeModem -A- Exchange1 -D- Exchange2 -A-
| ISPModem. The digital parts were all inside the telco's
| networks that connect the exchanges to each other.
|
| > Couldn't you send data at megabits per seconds over a mile
| long copper wire without using modems at all (using just
| UARTs?).
|
| No. The exchange is sampling the analog signal coming in over
| your phone line at 8kHz and 8 bits per sample. They just
| designed modems that sent digital data over that analog link,
| in a way that would line up exactly with the way the exchange
| will sample it.
| senshan wrote:
| _The S /CNN for both trunk and nonloaded subscriber loop
| circuits shall not be less than 31 dB._
|
| 4kHz/2*log2(1+10^(31dB/10)) ~ 60.3kBps
|
| [0]
| https://www.ecfr.gov/current/title-7/subtitle-B/chapter-
| XVII...
| ycombiredd wrote:
| > Couldn't you send data at megabits per seconds over a mile
| long copper wire
|
| Yes, but you need the bare copper wire without signaling. We
| operated a local ISP in the 90's and did exactly that by
| ordering so-called "alarm circuits" from the telco (with no
| dial tone) and placed a copper T1 CSU on each end. We
| marketed it as "metro T1" and undercut traditional T1 pricing
| by a huge margin with great success to the surrounding
| downtown area.
| immibis wrote:
| It's ISP-A-Telco-D-Telco-A-You
|
| Traditionally both the ISP and you pay for analog phone lines
| from the telco. The telco uses digital internally (remember
| you and your ISP probably aren't at the same exchange), which
| puts a hard limit on data rate - there is no trick you can do
| to get more bits through than the bits used in the digital
| part of the call.
|
| If you (as the ISP) buy enough lines you can get them
| delivered in digital format. A T1 is designed to carry 24
| simultaneous phone calls, acting virtually as a bundle of 24
| analog phone cables. So the obvious next stage was to have a
| modem that can handle 24 simultaneous connections on one
| cable.
|
| Now you have ISP\\_modem-Ax24-ISP\\_muxer-Dx24-Telco--Telco-
| A-User
|
| The ISP's modem generates analog signals for up to 24
| simultaneous incoming calls, and they pass into a multiplexer
| that connects 24 analog lines to a T1 line and they go
| through the telco digitally to users. The maximum bandwidth
| is still as before - the modem has to generate an analog
| signal that will still be receivable at the other end after
| A2D and D2A conversion. Even though the digital bandwidth for
| the digital part is 56kbps, the maximum achievable bandwidth
| through this digital-bottlenecked analog call was found to be
| 33.6kbps.
|
| But the industry had an idea: by convincing the telco to
| install the modems into the user's exchange, the analog
| portion would only be between the telco and the user, without
| a digital segment in the middle of it, and therefore wouldn't
| be bottlenecked the same way. The same digital backhaul from
| the ISP through the telco was used, but instead of
| transmitting a digitised analog modem signal and therefore
| causing degradation of quality, it transmitted your actual
| internet traffic bits, up to 56kbps. The analog signal was
| made at the user's side of the telco and didn't have to fit
| within 56kbps when digitised.
|
| Pedantically, the digital circuits are 64kbps but one bit in
| some bytes is used for call status signaling, which is okay
| for voice, but the ISP equipment can't predict which bytes
| have a bit overwritten (and it could be multiple if there are
| several hops) so it just used 7 bits in each byte.
| putzdown wrote:
| 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.
| inamberclad wrote:
| 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 wrote:
| 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 wrote:
| Lol, see the recent HN post on TRIZ and my comment there pointing
| folks to this. And here I complete the cycle.
| cainxinth wrote:
| Adapted to writing:
|
| https://en.wikipedia.org/wiki/Wikipedia:Akin%27s_Laws_of_Art...
| buildsjets wrote:
| 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.
| dvrp wrote:
| "Avoid the temptation to believe a completely new product will
| always be better than an evolution of an old product".
| ricksunny wrote:
| 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 wrote:
| _> 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 wrote:
| > _> 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 wrote:
| > _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.
___________________________________________________________________
(page generated 2025-12-31 23:00 UTC)