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

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

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

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.

While this PDF might be new, Akin's Laws of Spacecraft Design dates back to 2003.

https://web.archive.org/web/20031101212246/https://spacecraf...

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

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.

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.

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

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.

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.

Last archived working original: https://web.archive.org/web/20250808213459/https://spacecraf...

Adapted to writing:

https://en.wikipedia.org/wiki/Wikipedia:Akin%27s_Laws_of_Art...

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

I’m Henshaw (#37). AMA.

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

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.

> Quality thinking is more important in this profession than fast thinking.

Feels true, particularly in an era where LLMs make fast thinking cheap.

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

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.

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

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

> 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?

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.

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.

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

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

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

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