>16. The previous people who did a similar analysis did not have a direct pipeline to the wisdom of the ages. There is therefore no reason to believe their analysis over yours. There is especially no reason to present their analysis as yours.
>19. The odds are greatly against you being immensely smarter than everyone else in the field. If your analysis says your terminal velocity is twice the speed of light, you may have invented warp drive, but the chances are a lot better that you've screwed up.
Learning how to better thread the needle between these two is been one of the most important things I have learned in my career. Just because this is the way it was always done doesn't mean we have to do it that way, but the people who did it that way probably had some reason for it that is worth exploring and fully understanding.
> 40. (McBryan's Law) You can't make it better until you make it work.
This has been my credo for developing software for as far back as I can remember. If you approach creating something new as purely experimentation, you'll get to something workable sooner. You can then either polish your newly created turd or choose to scrap it for something new that builds on what you learned.
My favorite as an engineer/scientist who has sat through tons of terrible presentations:
20. A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately.
If people can't understand your ideas, you're counting on them to shrug and say, "Boy, this guy sounds smart! I guess we should do what he says!" If they're doing their job, they won't.
> 30. (von Tiesenhausen's Law of Engineering Design) If you want to have a maximum effect on the design of a new engineering system, learn to draw. Engineers always wind up designing the vehicle to look like the initial artist's concept.
I suppose a lot of new ideas come with a lot of "filler" details that weren't consciously decided on but end up as a permanent fixture of the design, and that whoever tries first to communicate the idea to others has a lot of unintentional influence over the final product.
This was the best advice I got in undergrad (as an EE). We had a seminar from a mechanical engineer who argued that the best thing we could do for our careers was take a drawing class or otherwise get to a point where we were competent at sketching an idea.
People, especially the non-technical, are so visually oriented that, no matter the engineering field, the ability to draw a coherent picture of a concept can be enormously valuable.
Tangentially related: every now and then I do some graphic design, and I've seen this "okay I'll just throw down a quick mockup → the client likes it so it basically becomes the final version" progression so many times...
This approach comes with hidden cost of adding unnecessary complexity. Think about B2 bomber design: it looks like some "artist" wanted to recreate a Batplane, or other sci-fi spacecraft and then it took a lot of engineering effort to make the thing of such ridiculous shape to actually fly in stable, predictable manner.
I wish I had gotten good at sketching early in my career. Too late for me now, but not too late for my kid as I involve him in STEM education activites. Interestingly, learning how to sketch is featured in several robotics curriculums for kids, for example Carnegie Mellon's Robotics Academy.
> 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.
This is awesome. I don't know how many times I've seen over engineering in the field. It's crazy. Well we may one day want to do X.
I like the way Ben Horowitz puts it in his good pm, bad pm document:
Good product managers focus the team on revenue and customers. Bad product managers focus team on how many features Microsoft is building. Good product managers define good products that can be executed with a strong effort. Bad product managers define good products that can’t be executed or let engineering build whatever they want (i.e. solve the hardest problem).
As an engineer, I want to find the demons that are out there in the problem space and assault them, I want to eliminate all weakness from my precious software. But from the business POV I know we need to provide value to customers quickly and efficiently with the available resources, which is usually not the same thing.
In software, these three are not exclusive, they're in fact three rungs on the same ladder. In the words attributed to Kent Beck: make it work (effective), make it right (elegant), make it fast (efficient). http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast
This whole thread talks about efficient and elegant and effective. Good engineering is mostly in the domain of how a system handles failure. Either by making it a really low likelihood or making it graceful.
Actually, I think SpaceX as a satellite launch company is living this advice as well as one could. You need at least one engine and one launch vehicle, so they built Merlin and Falcon. The rest of their LV development has been steady iterative improvements to those platforms. This strategy enabled them to achieve reusable boosters, because building sophisticated autonomous flight controls on top of a known, proven, reliable LV is much easier than doing it on top of a newly minted one.
SpaceX as a Mars colonization venture on the other hand...
NASA insistence on the human-rating for their own commercial crew spaceflights greatly increases the cost. If I recall right two falcon 9 have been lost to accidents, one on the pad, another 150 seconds into the flight. But the overall ratio of rapid unscheduled disassemblies to successful flights is looking promising.
Compare the predicted likelihood of fatalities with how many FAA licensed amateur/kit built "experimental" airplanes crash each year, killing their sole occupant pilots...
The FAA seems to be relatively OK with that fatality rate, on an ongoing basis, but spacecraft are held to a much higher standard.
If there had been a human in the very first Dragon flight carrying a wheel of cheese, years ago, they would have survived and had a nominal flight.
His advice predates all private spaceflight. Any launch vehicle was destined to be a sprawling, overbudget federal project back then. Not a lean, for-profit enterprise like Musk has developed.
I think you can make an exception when you haven't developed a new launch vehicle in 50 years, and NASA doesn't plan to launch a human mission until 2035, 15 years after SpaceX will start using its BFR for other types of missions.
> 33. (Patton's Law of Program Planning) A good plan violently executed now is better than a perfect plan next week.
In case anyone's wondering about the use of "violently" - this is supposed to be General Patton's law about military plans. Just so happens to apply to other fields.
I agree that you shouldn't spend a lot of effort going beyond the requirements, but sometimes you will reap huge benefits because you happened to go somewhat beyond the requirements in a given instance. It's like the property of brittleness - you don't want to spend too much time making everything adjustable and bendable, but neither do you want to make everything as hard and precise and brittle as possible.
Someone linked an article elsewhere on HN about the true meaning of mediocrity that I enjoyed and really made me think about this:
That is true, but the phrasing is a little aggressive. Assigning "lines of blame" makes it sound like it is about having someone to point to after the fact. It is really about every part of a project having a single owner who is accountable so nothing slips through the cracks of bureaucracy. A way to rephrase that without the negative connotations of "blame" is "when everyone is responsible, no one is responsible."
I mentor a high school robotics team. Oh man does it apply to them! I like to run the laws past them at the start of every season. They still stumble over many of them. :-O
The laws I stress:
14. (Edison's Law) "Better" is the enemy of "good".
40. (McBryan's Law) You can't make it better until you make it work.
The law that they are really good at (especially in the middle of a competition):
34. (Roosevelt's Law of Task Planning) Do what you can, where you are, with what you have.
I saw a $96M startup fail, not because the product failed, but because the distribution function for the yield was not understood. It was too sharply peaked to be practical. There’s a lesson there.
> 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.
I was going to complain that Cheops' Law ("it always takes longer and costs more" is my version) was missing, but that's a useful elaboration providing a new target.
15. (Shea's Law) The ability to improve
a design occurs primarily at the
interfaces. This is also the prime
location for screwing it up.
This is the problem with the information hiding approach of ADT, OO and even APIs: makes it easy to change the module internals, but hard to change the module interfaces.
[+] [-] slg|7 years ago|reply
>19. The odds are greatly against you being immensely smarter than everyone else in the field. If your analysis says your terminal velocity is twice the speed of light, you may have invented warp drive, but the chances are a lot better that you've screwed up.
Learning how to better thread the needle between these two is been one of the most important things I have learned in my career. Just because this is the way it was always done doesn't mean we have to do it that way, but the people who did it that way probably had some reason for it that is worth exploring and fully understanding.
[+] [-] koolba|7 years ago|reply
> 40. (McBryan's Law) You can't make it better until you make it work.
This has been my credo for developing software for as far back as I can remember. If you approach creating something new as purely experimentation, you'll get to something workable sooner. You can then either polish your newly created turd or choose to scrap it for something new that builds on what you learned.
[+] [-] tomkat0789|7 years ago|reply
20. A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately.
If people can't understand your ideas, you're counting on them to shrug and say, "Boy, this guy sounds smart! I guess we should do what he says!" If they're doing their job, they won't.
[+] [-] elihu|7 years ago|reply
> 30. (von Tiesenhausen's Law of Engineering Design) If you want to have a maximum effect on the design of a new engineering system, learn to draw. Engineers always wind up designing the vehicle to look like the initial artist's concept.
I suppose a lot of new ideas come with a lot of "filler" details that weren't consciously decided on but end up as a permanent fixture of the design, and that whoever tries first to communicate the idea to others has a lot of unintentional influence over the final product.
[+] [-] InitialLastName|7 years ago|reply
People, especially the non-technical, are so visually oriented that, no matter the engineering field, the ability to draw a coherent picture of a concept can be enormously valuable.
As they say, a picture is worth a thousand words.
[+] [-] uryga|7 years ago|reply
[+] [-] mamon|7 years ago|reply
[+] [-] geomark|7 years ago|reply
[+] [-] bargl|7 years ago|reply
This is awesome. I don't know how many times I've seen over engineering in the field. It's crazy. Well we may one day want to do X.
[+] [-] strong_silent_t|7 years ago|reply
Good product managers focus the team on revenue and customers. Bad product managers focus team on how many features Microsoft is building. Good product managers define good products that can be executed with a strong effort. Bad product managers define good products that can’t be executed or let engineering build whatever they want (i.e. solve the hardest problem).
As an engineer, I want to find the demons that are out there in the problem space and assault them, I want to eliminate all weakness from my precious software. But from the business POV I know we need to provide value to customers quickly and efficiently with the available resources, which is usually not the same thing.
[+] [-] WalterBright|7 years ago|reply
Baloney :-) They design things they imagine are elegant. Nobody agrees with them.
My take is anybody can design something complicated. It takes genius to design something simple. (and elegance comes from simplicity)
[+] [-] BerislavLopac|7 years ago|reply
[+] [-] colordrops|7 years ago|reply
[+] [-] sitkack|7 years ago|reply
[+] [-] JepZ|7 years ago|reply
https://en.wikipedia.org/wiki/Form_follows_function
[+] [-] ythn|7 years ago|reply
Say the problem is driving a nail into a wall for hanging up a picture.
In this case:
Elegant = solution is a glass cube
Efficient = solution is gasoline-powered nail driver which drives 1000 nails per minute
Effective = solution is hammer
[+] [-] mabbo|7 years ago|reply
[+] [-] 323454|7 years ago|reply
SpaceX as a Mars colonization venture on the other hand...
[+] [-] walrus01|7 years ago|reply
Compare the predicted likelihood of fatalities with how many FAA licensed amateur/kit built "experimental" airplanes crash each year, killing their sole occupant pilots...
The FAA seems to be relatively OK with that fatality rate, on an ongoing basis, but spacecraft are held to a much higher standard.
If there had been a human in the very first Dragon flight carrying a wheel of cheese, years ago, they would have survived and had a nominal flight.
[+] [-] hodgesrm|7 years ago|reply
[+] [-] WJW|7 years ago|reply
[+] [-] trhway|7 years ago|reply
actually he originally tried to buy Russian ICBM launch vehicles. Russia refused and that forced him to develop his own.
[+] [-] starpilot|7 years ago|reply
[+] [-] mtgx|7 years ago|reply
[+] [-] mikro2nd|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] gvb|7 years ago|reply
"SpaceX and Boeing spacecraft may not become operational until 2020"
https://arstechnica.com/science/2018/05/new-report-suggests-...
[+] [-] teeray|7 years ago|reply
Reposting it here because I think it's awesome.
[+] [-] jacquesm|7 years ago|reply
[+] [-] TeMPOraL|7 years ago|reply
> 6. (Mar's Law) Everything is linear if plotted log-log with a fat magic marker.
I also love btilly's explanation of why it's actually true: https://news.ycombinator.com/item?id=5058211.
[+] [-] maze-le|7 years ago|reply
Sounds like Software Architecture to me.
> At the start of any design effort, the person who most wants to be team leader is least likely to be capable of it.
This might be true for any organization.
[+] [-] azernik|7 years ago|reply
In case anyone's wondering about the use of "violently" - this is supposed to be General Patton's law about military plans. Just so happens to apply to other fields.
[+] [-] andrewbinstock|7 years ago|reply
>13. Design is based on requirements. There's no justification for designing something one bit "better" than the requirements dictate.
This is YAGNI stated a different way.
[+] [-] perl4ever|7 years ago|reply
Someone linked an article elsewhere on HN about the true meaning of mediocrity that I enjoyed and really made me think about this:
https://www.ribbonfarm.com/2018/04/24/survival-of-the-medioc...
[+] [-] hinkley|7 years ago|reply
Most of the time the requirements don’t contain common sense.
Like the servers have to keep working after our ad campaign is successful...
[+] [-] Veelox|7 years ago|reply
I feel like this applies to a lot more than just spacecraft design.
[+] [-] slg|7 years ago|reply
[+] [-] gvb|7 years ago|reply
The laws I stress:
14. (Edison's Law) "Better" is the enemy of "good".
40. (McBryan's Law) You can't make it better until you make it work.
The law that they are really good at (especially in the middle of a competition):
34. (Roosevelt's Law of Task Planning) Do what you can, where you are, with what you have.
[+] [-] thebigspacefuck|7 years ago|reply
"A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately."
[+] [-] sgillen|7 years ago|reply
11. Sometimes, the fastest way to get to the end is to throw everything out and start over.
And
14. (Edison's Law) "Better" is the enemy of "good".
[+] [-] aj7|7 years ago|reply
[+] [-] B1FF_PSUVM|7 years ago|reply
I was going to complain that Cheops' Law ("it always takes longer and costs more" is my version) was missing, but that's a useful elaboration providing a new target.
[+] [-] hyperpallium|7 years ago|reply
But, TBF, the real problem is dependencies.
[+] [-] skmurphy|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] marze|7 years ago|reply
1) No new launch vehicles.
2) No new launch vehicles.
3) Whatever you do, don't develop any new launch vehicles.
Funny to see this on the list while NASA violates it year after year.