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

  Rest of world<--- digital--->Telco<---digital--->ISPmodem<---analog--->HomeModem

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

   https://youtu.be/0-z1TaNx7TM

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

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.

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

Adapted to writing:

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

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

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.

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.

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.

> 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’m Henshaw (#37). AMA.

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

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

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

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

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

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.

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

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.

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

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