Akin's Laws of Spacecraft Design
spacecraft.ssl.umd.edu
spacecraft.ssl.umd.edu
I feel like you could permute "elegant", "efficient", and "effective" in any way here and still arrive with a maxim that sounds nice but doesn't really say anything.
elegant: builds a system in a way that is technically satisfying
efficient: builds a system in a way that uses the least resources
effective: builds a system in way that best solves the problem
I've built a lot of elegant systems that didn't solve the right problem but sure looked good.
I've also build systems out of leftover servers and laptops that were super inexpensive.
But I've learnt that there are times where spending money is the best way to build the system that the customer actually wants (and will pay for).
No, 'Effective' solves the problem, but not necessarily in the "best" way possible. In my opinion, the quote as stated is just wrong. Effective means "gets it done", but doesn't convey that it was done optimally.
It makes much more sense to me to say...
"Any run-of-the-mill engineer can design something which is effective. A good engineer designs systems to be efficient. A great engineer designs them to be elegant."
It makes much more sense to you (and me) that way but the point is our common sense about what makes an engineer great is wrong.
In real world systems you often have competing constraints. In construction if someone asked you to make a beam section more efficient you'd need to consider weight, cost, weld-ability, yield strength etc. All competing against each other.
An effective engineer is someone who can see the whole picture of the system and where his design fits into it. Being able to make the most appropriate efficiency gains in areas where you get the greatest benefit.
I've always considered a technically elegant solution to be something more novel - an approach that had never been considered before or consider and dismissed as unworkable in the past.
Elegance requires constraints consistent and few, whereas reality is a seething mess of capricious special cases - the far end of the spectrum from pure consistent abstractions.
But not only that it's easier, he also means that a solipsist chasing idealized butterflies is not an engineer. An engineer is meant to solve real, practical problems.
I feel like this applies to everything. I mostly work on ecommerce and analytics systems, and I feel like I'm having to make this same argument all the time.
It was surprising how reliable the programs turn out to be. But the shocking part is how small they are.
I'm starting to be convinced that the only way to write reliable code is to spend most of your time trying to remove code. And not at the expense of clarity; tricks like that don't matter.
In an informal way I think of it as a good design being 'square', as in the design is distributed evenly across all scales. So a small program might have ten functions of about ten lines each. A bigger one might have ten files, each containing about ten functions of about ten lines. It's different in every project but solid, elegant, well structured systems always seem to feel 'square'.
Very small programs don't solve complex tasks.
Your point about shifting complexity around is a good one.
Some numerical solvers, graph algorithms, control systems, etc. have this property. They are definitely what I would call a simple program, even if the math behind them is not. YMMV.
This is one of the valid criticisms of OO. "Gluing" small (mostly) correct objects together can produce unforseen results in the aggregate, or can be hard to understand in aggregate.
When you introduce containers in some form, it becomes reasonable to add monitoring for errors. Make sure that there is redundancy. Now if error conditions are found, it is OK to lose the container. Another will be along shortly to pick up where you left off.
This approach is often used in distributed software. For example a good MapReduce framework will take care of detecting failing machines and replacing them, hopefully with perfect results. Erlang uses the same approach, and some of the most reliable software in the world has been written with it.
This idea does not just apply to a digital world. For example each rocket in a Falcon 9 is able to detect that it is not working right and shut down. The overall system is designed to work if any 7 rockets still fire.
Take high-frequency trading, for example.
"A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately."
Both sides of the issue. Doesn't matter how right you are if you can't convince anyone. While bad plans can persist in sucking up resources because they were 'sold' well.
It then follows that everyone has to be taught presentation skills, just as they're taught evaluation skills.
It's because a lot of engineers are horrible communicators. Not a surprise, and not their fault - it's never been part of their training, how would they be good at it?. But it means that often, the way they present ideas is at best only understandable by fellow engineers with experience in the domain. And often not even by those.
And that's what most corporate presentation training I've seen focuses on - how can you say what you want to say more clearly. (And, equally important, how can you deal with the stress of being on stage in front of a set of people).
Presentation is rarely about "selling", but about communicating an overview concisely and cleanly.
(It's also incredibly hard to teach salesmanship. It requires a lot of charisma and empathy, and that's not something you teach in an afternoon or two)
http://www.piclist.com/tecHREF/begin.htm
If a ten commandments of growth hacking ever comes into being, my hope is the first law states: Thou shalt not spam ;)
An interesting 4th book to add to the book list is the ARRL handbook. If there's anything you don't understand between those covers, then you just identified what you need to learn to be a well rounded engineer. AoE is still good for strictly design topics. Can't design anything better than you understand the application is another semi-related good one.
http://www.arrl.org/shop/ARRL-Handbook-2016-Hardcover-Editio...
This is so true. Yet, its the inverse of what all textbooks say.
How can it be this way? This is a huge blind spot right on the middle of systems engineering.
That's a traditional russian saying, never seen it attributed to Edison before.
I too call shenanigans on the Edison bit ;)
I often google names from personalities that I know and get a footballer or a singer in the first results.
Maybe there's an Edison that spacecraft folks know and we don't.
http://www.edbatista.com/2009/04/voltaire-patton-perfection....
https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good
Old sayings don't really have frontiers, so it might as well be an old Russian saying.
"He who is determined not to be satisfied with anything short of perfection will never do anything to please himself or others."
I thought the classic Russian problem is having too many frontiers.
The concept is very important to learn, especially for those with a strong sense of idealism.
I was once commenting to a friend that my project was taking about 12 times longer than planned, and he said, "ok, about a factor of 4pi". All my time estimates get a factor of 4pi increase now.
That is entirely too true.
"20. A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately."
And that explains NASA. (Except for the corollary, "A good design with a good presentation is doomed, too.")
"Any car which holds together for a whole race is too heavy."
Well...
Today I see how much Soyuz-2 costs vs. how much spacecraft Soyuz costs... and wonder - may be it's still trickier to create Apollo and LEM than Saturn-V, even though in Russian history H1 turned out to be harder to make than the payloads...
Rockets are doing roughly the same thing, since 1957 - get things to orbit. While payloads keep changing - with all those stations, telescopes, probes, monitoring satellites etc. Rockets aren't that much "rocket science" anymore - but the payloads surely are. So may be - just may be - this law can be amended, a little bit.
If this ever happens to me in my career I will start believing in god or whatever you want. Dealing with "legacy" tech has been the only constant in my life across several unrelated industries (even in the supposedly brash and agile games industry).
one of the key definitions of antifragility.
Does anybody know to which Miller it refers to?