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.
> 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.
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".
"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. :)
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.
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 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.
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."
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.
> 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.
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".
> 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?
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.
The first law already gives a good reason why software "engineering" is rarely actually engineering.
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. :)
Almost all the laws are great guidance for Software dev to be honest and idiomatic to a lot of what's banded around today as good practice.
Oh god it can be worse when the suits try to measure everything. Some things are measurable and others are taste / gut and that is OK.
While this PDF might be new, Akin's Laws of Spacecraft Design dates back to 2003.
https://web.archive.org/web/20031101212246/https://spacecraf...
> Quality thinking is more important in this profession than fast thinking.
Feels true, particularly in an era where LLMs make fast thinking cheap.
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
It's a nice reflection, but what is the origin of this? Can't find another reference to this "law" online.
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...
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
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.