> 36. Any run-of-the-mill engineer can design something which is elegant. A good engineer designs systems to be efficient. A great engineer designs them to be effective.<p>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.
"To design a spacecraft right takes an infinite amount of effort. This is why it's a good idea to design them to operate when some things are wrong."<p>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.
This one really tells a story:<p>"A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately."<p>Both sides of the issue. Doesn't matter how <i>right</i> you are if you can't convince anyone. While bad plans can persist in sucking up resources because they were 'sold' well.
Also relevant: Beginning Engineer's Checklist<p><a href="http://www.piclist.com/tecHREF/begin.htm" rel="nofollow">http://www.piclist.com/tecHREF/begin.htm</a><p>If a ten commandments of growth hacking ever comes into being, my hope is the first law states: Thou shalt not spam ;)
> 38. Capabilities drive requirements, regardless of what the systems engineering textbooks say.<p>This is so true. Yet, its the inverse of what all textbooks say.<p>How can it be this way? This is a huge blind spot right on the middle of systems engineering.
> 14. (Edison's Law) "Better" is the enemy of "good".<p>That's a traditional russian saying, never seen it attributed to Edison before.
> 29. (von Tiesenhausen's Law of Program Management) To get an accurate estimate of final program requirements, multiply the initial time estimates by pi, and slide the decimal point on the cost estimates one place to the right.<p>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.
"<i>18. ... Too much reality can doom an otherwise worthwhile design, though.</i>"<p>That is entirely too true.<p>"<i>20. A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately.</i>"<p>And <i>that</i> explains NASA. (Except for the corollary, "A good design with a good presentation is doomed, too.")
Same laws with some additional thoughts:
<a href="http://www.ece.uvic.ca/~elec399/201409/Akin's%20Laws%20of%20Spacecraft%20Design.pdf" rel="nofollow">http://www.ece.uvic.ca/~elec399/201409/Akin's%20Laws%20of%20...</a>
11. Sometimes, the fastest way to get to the end is to throw everything out and start over<p>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).
"2. To design a spacecraft right takes an infinite amount of effort. This is why it's a good idea to design them to operate when some things are wrong .
"<p>one of the key definitions of antifragility.