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."
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.
Isn't your job to evaluate the design independent of their race, sex, ability to presentate, and other biases? Also if you are highly intellectual and highly technical, chances are that you hate when the looks are more important than the thing itself.
(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.)
https://youtu.be/0-z1TaNx7TMThat’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 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.
But I'd be surprised if Apple didn't have a beefier profit with the IPhone compared to Nokia with the N95.
"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://web.archive.org/web/20031101212246/https://spacecraf...
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.
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.
So will Musk finally be fired in 2026?
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.
And no I'm not a fan of the Musk personna.
It's a nice reflection, but what is the origin of this? Can't find another reference to this "law" online.
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...
Feels true, particularly in an era where LLMs make fast thinking cheap.
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.
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
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.)
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
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.