16 ms·
Akin's Laws of Spacecraft Design (2003)
- teeray 9y agoCredit to @tlb for surfacing it in a comment here: https://news.ycombinator.com/item?id=16995612 https://news.ycombinator.com/item?id=16995612 Reposting it here because I think it's awesome.
- jacquesm 9y agoAgreed. I was looking for a posting so I could upvote it when it happened. There's a scary number of parallels with software development in there.
- aje403 9y agoThat link is easily the greatest thing I've seen on HN. Thank you Until 42, that was a buzzkill
- msla 9y agoI find 31 a bigger buzzkill: > (Mo's Law of Evolutionary Development) You can't get to the moon by climbing successively taller trees. There's no gradual path to some goals. It's annoying beyond belief to only know something well enough to solve toy problems, and not have any way to see how you can extend your knowledge so you can solve non-toy problems. Sometimes, you can't get there from here.
- rm_-rf_slash 9y agoI read it as the other way. Acknowledging that iterative improvements on fixed assumptions goes nowhere is quite liberating. Perhaps I have been watching too much Gurren Lagann lately, but my corollary to rule 31 would be: if you are underground, you can only find sunlight by digging up.
- tlb 9y agoBut you can get to the moon starting with hand-made shoestring-budget rockets like Goddard's. https://en.wikipedia.org/wiki/History_of_rockets#/media/File:Goddard_and_Rocket.jpg https://en.wikipedia.org/wiki/History_of_rockets#/media/File....
- SahAssar 9y agoActually that image perfectly represents the concept. To get to the moon they had to abandon puller rockets (like the one in the image), and use pusher rockets instead. That isn't just a higher tree, that's completely re-imagining the way a rocket works. So "higher trees" might be a good way to learn how to re-engineer the idea so that you can get to the moon.
- sbov 9y agoSometimes I feel like software developers are using rockets to climb trees.
- bartread 9y agoThere's a lot of fantastic nuggets in there, that's for sure, but I have a nasty feeling that in a few years time this one will have become firmly entrenched in the vile lexicon of management wank-speak: 31. (Mo's Law of Evolutionary Development) You can't get to the moon by climbing successively taller trees.
- hinkley 9y agoHeard this one as “you can’t cross the Grand Canyon in Three Easy Steps”
- staticautomatic 9y agoThat one's gonna be the new "revolution vs evolution".
- callmeal 9y agoI think there already is: You can't run a marathon in sprints.
- perl4ever 9y agoI heard something similar from people who worked on Navy subs - an engineering assistant fresh out of college was told "you may have gotten partial credit in school, but a sailor at the bottom of the ocean doesn't care if you did your work partly right".
- hinkley 9y agoGod I started saying that one pretty early. I may have still been in college when I started saying it. Working while going to school is a very different experience than doing them in order.
- mrfusion 9y agoThere’s really nothing about spacecraft.
- ceejayoz 9y agoI mean, sure, it's mostly all stuff applicable to large, complex projects, but you should scroll down a bit... > 39. Any exploration program which "just happens" to include a new launch vehicle is, de facto, a launch vehicle program.
- Hextinium 9y agoThis also though could be applied to any system that just happens to have a massive amount of work to get it even above the ground as well. Just change the language to the behemoth in your field of choice and it applies.
- topspin 9y agoThat may be the most important takeaway.
- maze-le 9y ago> Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment. 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.
- Rhinobird 9y ago>This might be true for any organization. Jerry Pournelle's Iron Law of Bureaucracy https://www.jerrypournelle.com/reports/jerryp/iron.html https://www.jerrypournelle.com/reports/jerryp/iron.html Or the Peter Principle https://en.wikipedia.org/wiki/Peter_principle https://en.wikipedia.org/wiki/Peter_principle
- mattkevan 9y agoAnd product management. The cheery slogan there is 70 percent of what you do will fail, the remaining 30 percent will need at least 3 or 4 goes before you get it right.
- duncan_bayne 9y agoAn actually cheery way of putting that is "30 percent of your hypotheses will be validated, after some amount of refinement" ;)
- mattkevan 9y agoOh I like that. Sounds much better!
- andrewbinstock 9y agoGreat link! >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 9y agoI 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: https://www.ribbonfarm.com/2018/04/24/survival-of-the-mediocre-mediocre/ https://www.ribbonfarm.com/2018/04/24/survival-of-the-medioc...
- deleted 9y ago[deleted]
- hinkley 9y agoI’ve worked on this project a few times. It’s hell or /r/maliciouscompliance territory. Most of the time the requirements don’t contain common sense. Like the servers have to keep working after our ad campaign is successful...
- ishi 9y agoA real life example - client discovers that users cannot actually get into the system. Contractor says: "Ah, you wanted a login screen? This wasn't in the specs! You need to pay me more to implement a login screen."
- bargl 9y ago> 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.
- ythn 9y agoI'm having a hard time visualizing this one. 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
- WJW 9y agoA glass cube with rounded edges of course :)
- eddieh 9y agoHm, I think elegant here does not mean classy or fancy. It instead means "ingenious and simple" so an elegant solution is in fact a hammer. Likewise, I think of efficiency as the resources used to accomplish something. While a nail driver would be fast, it isn't really efficient. An efficient solution is also a hammer. And of course the hammer is the effective solution.
- Nomentatus 9y agoCubes are simpler than hammers, was the point.
- jacquesm 9y agoHow does a glass cube drive a nail into the wall for hanging up a picture? If used as a hammer it is just another hammer (and an ineffective one at that because it is going to slide off the nail and cause you injury or shatter and cause you injury).
- koolba 9y agoNumber 40 is beautiful: > 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.
- OpenDrapery 9y agoTurds have a way of living on in the software world.
- groby_b 9y agoThey live on if they provide value. And that's OK, because we're in the business of providing value, not building shiny monuments to our incredible cleverness.
- unclebucknasty 9y agoYeah, I guess like most things that's true to a degree. But, those turds have a way of coming back to haunt a project in the form of technical debt. It would really be interesting if you could calculate how much the technical debt ends up costing on the average project, and whether it's worth the savings gained from leaving the turds in place.
- groby_b 9y agoThat's an excellent question. It depends, to some extent, on the question if a solution with less technical debt would've been possible at all. Often, the "turds" were either the only thing possible at the time, or the savings there opened up other opportunities. Not always - sometimes the "cost savers" simply insist on digging a grave for the project. But that's the main distinction - if it's bad and yet lives on, there has to be value in it. No company spends money on something that doesn't provide value. I suppose what you are arguing is that the product doesn't necessarily provide the maximum value possible. But that's a pretty high bar to meet. There's always a "good enough". In a perfect world, engineering and product "good enough" coincide. If only one is good enough, you get either a badly engineered financial success, or a financially disastrous monument to engineering. All other things being equal, only the former lives on. And hence, "turds live on" - and make money, and pay paychecks. And if their maintenance costs exceed their revenue, they usually get shut down. (I'm deliberately ignoring all projects that can afford to ignore money. The rules are different there.)
- neves 9y agoGreat!!! These laws work for any kind of engineering project. Maybe any kind of project.
- jonshariat 9y agoThis has been posted to HN 9 times https://hn.algolia.com/?query=Laws%20of%20Spacecraft%20Design%20&sort=byPopularity&prefix&page=0&dateRange=all&type=story https://hn.algolia.com/?query=Laws%20of%20Spacecraft%20Desig... The last one was only 1 day ago.
- humanfromearth 9y agoNot enough! These should be read at least once a month.
- mabbo 9y ago39. (alternate formulation) The three keys to keeping a new human space program affordable and on schedule: 1) No new launch vehicles. 2) No new launch vehicles. 3) Whatever you do, don't develop any new launch vehicles. Someone better tell Elon.
- WJW 9y agoHe is already reusing the launch vehicle used for unmanned launches so I don't see the problem.
- mtgx 9y agoI 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.
- Rebelgecko 9y agoI believe NASA is currently planning on launching a manned mission in 2023 or so. There was a push to put humans on the first SLS launch (2019 or 2020) but I think that was motivated by political concerns.
- TeMPOraL 9y agoThe whole SLS is entirely a political thing. NASA just announced a request for private Lunar capacity - currently, the requirements are the ability to deliver 10kg of NASA cargo to the Moon. So there's that. See: https://www.fbo.gov/index?s=opportunity&mode=form&tab=core&id=46b23a8f2c06da6ac08e1d1d2ae97d35&tab=documents&tabmode=list https://www.fbo.gov/index?s=opportunity&mode=form&tab=core&i....
- deleted 9y ago[deleted]
- starpilot 9y agoHis 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.
- thebigspacefuck 9y agoMy personal favorite is 20: "A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately."
- Veelox 9y ago> 37. (Henshaw's Law) One key to success in a mission is establishing clear lines of blame. I feel like this applies to a lot more than just spacecraft design.
- gvb 9y agoI 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.
- geomark 9y agoI sure would like to know more about your mentoring of a robotics team. I sent you email.
- slg 9y agoThat 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."
- GlenTheMachine 9y agoHi! I'm Henshaw, and I coined this law. Dave Akin was my lab director in grad school. You are correct in your analysis. Of course, the phrasing was meant to be a little aggressive, otherwise it isn't memorable.
- slg 9y ago>Of course, the phrasing was meant to be a little aggressive, otherwise it isn't memorable. That is totally true and was something I missed. A law is of no value if no one remembers it. I bet we could even find one of Akin's laws to explain why that is the case. Side note, HN blows my mind sometimes in that I can make a comment on a term and within minutes the guy who coined the term is on here responding.
- tomkat0789 9y agoMy 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.
- TeMPOraL 9y agoIt's sad, really. In a perfect world, you'd have an awesome design coupled with awesome sales pitch. In reality, a lot of people realized that almost the entire ROI comes from the sales pitch, so you can half-ass the design part (or even skip it entirely, if your sales person is good).
- forgotmysn 9y agoits also probably a supply/cost issue. People that are good at sales are more common, and cheaper to employ than people that are good at designing complex feats of engineering.
- danielsju6 9y agoBut they rarely find themselves in the same circles.
- sverige 9y agoPeople that are great at sales are very rare, though. And people that are great at sales and have great platform skills are the ones who make it past director level to the executive suite. Engineers do well when they spot such people early and make friends with them. "Early" is important, because by the time they make it to the executive suite, they (hopefully) already have trusted "technical advisers" who will tell them when their idea sucks before it gets sold and propagated throughout the organization. If they don't, then they will rely on their secret sales intuition and their defenses against common sense will be impenetrable. This is usually the highest executive function of engineers / "technical advisers" in large enterprises. Not so glamorous, but critical to the health of any organization.
- hobofan 9y agoThis has to be one of the worst advice lists of its kind I've seen. - Too long to be remembered - Half of it is clever quips and not actual insights - A lot of the points contradict each other A list like this mostly serves as a feel-good piece for experienced engineers rather than useful advice for inexperienced ones, since they don't know which part of the list to take how seriously and how to interpret the contradicting ones.
- lopatin 9y agoIf long and contradictory lists are so bad, how do you explain the Ferengi culture's success in adopting the 300 or so Rules of Acquisition? [1] [1] http://memory-alpha.wikia.com/wiki/Rules_of_Acquisition http://memory-alpha.wikia.com/wiki/Rules_of_Acquisition
- mmirate 9y agoQuite easily: Star Trek being a work of fiction, its contents are unconstrained by any aspects of reality other than the limitations of its medium (in this case, live-action television).
- blueprint 9y agoAnswers without problems are useless as there is no way to confirm them. So a law (principle) is that something is determined.
- jotm 9y agoThis is HN, don't try to bring reality in here.
- microtherion 9y agoAny list of advice without contradictions is bound to be a poor representation for full reality. "Experience" is precisely the ability of resolving these contradictions properly in a given situation.
- rzimmerman 9y agoYeah it’s a bunch of inside jokes from building spacecraft the same way many times with varying degrees of success. There is little to no practical advice. The bit about never exceeding the requirements is great if you want to build something once and wash your hands of it. The “advice” on not building new launch vehicles sounds like someone had a bad time building a launch vehicle and I guess we should double down on the shuttle?
- TeMPOraL 9y agoMy all-time favourite is #6: > 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 https://news.ycombinator.com/item?id=5058211.
- azernik 9y ago> 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.
- groby_b 9y agoExcept the "violently" here does not actually refer to the use of military force. It's in the sense of "vigorously" or "forcefully". No hesitation. No hesitation, no waffling, no debate - "just do it". Or, as Amazon calls it "disagree and commit"
- azernik 9y agoIn the engineering context it means that. But in the original context, it meant both.
- deleted 9y ago[deleted]
- deleted 9y ago[deleted]
- slg 9y ago>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.
- Mtinie 9y ago> Put very simply: don’t destroy what you don’t understand. “Chesterson’s fence” https://en.m.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.m.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fen...
- JepZ 9y agoDidn't know that principle had a name, but I love it. Once I have seen a project manager who's project didn't deliver much insight, so he had this brilliant idea to advise to replace some software which was built with some old technology. He didn't have the slightest clue how that software worked, he just knew what the purpose of the software was and his advise was to rebuilt it with newer technology to make it better (whatever that means). When I told him, that the software wasn't as trivial as he might think and that I am against replacing it, as long as it wasn't clear how the new version would be better (besides being built with that new technology he was suggesting) he started looking for some other findings his project could deliver.
- derefr 9y agoI don't see these as opposed principles. 16. They're not smart. 19. You're not smart, either. Assume everyone is an idiot, including yourself. Verify everything (your own work and other people's work) using robust testing protocols. Don't use your own judgement; you're not smart enough for that. Gather evidence. But test your evidence-gatherers to make sure they're doing their jobs, too. Assume every component of your system-of-people is half-fallen-down and just barely limping along at all times. Make a system that works in the face of everyone coming to work with a concussion. (And, if some component isn't barely limping along, then people are probably being too naive about its potential failures, so inject some chaos [monkeys] into it to get its reliability down to a level where routing around it has to be operationalized, too.)
- aj7 9y agoI 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.
- elihu 9y agoI thought this one was interesting: > 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 9y agoThis 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. As they say, a picture is worth a thousand words.
- ghaff 9y agoThere used to be more emphasis placed on technical drawing. I came in at the tail end but I still worked with a lot of blueprints for a number of years.
- ams6110 9y agoWhen I was in Middle School, my shop class had a large unit devoted to mechanical drawing / drafting with pencil and paper. It was fun but also frustrating because the teacher was very particular about the details. If two lines were supposed to meet at a corner, and either one of them extended a little too far, he would mark down for that. Also any erasures prevented a perfect grade. Yes this was before computer drafting was practical, at least in schools.
- MrEldritch 9y ago
- FractalLP 9y agoAs an engineer I don't understand "engineering is done without numbers". All engineering revolves around math. Granted, estimations are needed when your doing analysis on something with no simple formula or that 12 inch pipe has some unknown amount of grime between 1-4 inches.
- FeteCommuniste 9y agoIt says “engineering is done with numbers.”
- marcofloriano 9y agoI'm not an engineer, but i can relate a lot with that: 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
- sandworm101 9y ago43. Does it work in KSP? Anyone else note the significance of stopping any list of questions at 42?
- skmurphy 9y agoI blogged about how to apply ten of these to startups at https://www.skmurphy.com/blog/2011/01/10/applying-akins-laws-of-spacecraft-design-to-startups/ https://www.skmurphy.com/blog/2011/01/10/applying-akins-laws...
- sgillen 9y agoHey! I worked with Dr. Akin in my undergrad. Definitely learned some of these he hard way during my project: 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".
- hyperpallium 9y ago15. (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. But, TBF, the real problem is dependencies.
- mauliknshah 9y agoHonestly, I loved this! Thank you for posting.
- deleted 9y ago[deleted]
- Angostura 9y agoNot a big fan of 14. (Edison's Law) "Better" is the enemy of "good".
- jgsteven 9y agoSame here. Also this one: 13. Design is based on requirements. There's no justification for designing something one bit "better" than the requirements dictate. To what level this is true depends on the complexity of the system I suppose, and how accurate the requirements actually are.
- eecc 9y agoHmm, judging by that list we’re all Rocket Scientists. (or at least we have the same problems)
- nissarup 9y agoI want these on a poster.
- marze 9y ago>39. (alternate formulation) The three keys to keeping a new human space program affordable and on schedule: 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.
- B1FF_PSUVM 9y ago> 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.