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.

> "A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately."

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.

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

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

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

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.

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

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

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

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.

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.

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.

It's a nice reflection, but what is the origin of this? Can't find another reference to this "law" online.

So will Musk finally be fired in 2026?

My favorite is still Mar’s law:

> Mar's Law) Everything is linear if plotted log-log with a fat magic marker.

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

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