> "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.
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.
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.
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.
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.
> 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.
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.
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".
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”.
"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.
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. :)
> 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.
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.
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.
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.
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.
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.
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.
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...
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...
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.
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.)
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.
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.
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."
(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.)
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 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.
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.
Feels true, particularly in an era where LLMs make fast thinking cheap.
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...
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.
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.