Akin's Laws of Spacecraft Design (2003)
spacecraft.ssl.umd.edu
spacecraft.ssl.umd.edu
>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.
“Chesterson’s fence”
https://en.m.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fen...
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.
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.)
Similar idea from another angle: superficial design flaws obscure fundamental design flaws (Douglas Adams on the Sirius Corporation Complaints Depatment)
> 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.
And that's OK, because we're in the business of providing value, not building shiny monuments to our incredible cleverness.
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.
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.)
I’ve sometimes wondered - not entirely ironically - if development teams would be understood as a revenue source instead of a cost if they hired their own micro-marketing sub-team to do internal marketing to management.
1. A long time ago, we had this turd of a hardware abstraction layer that is every systems developer's nightmare. Windows drivers behind a middleware, with COM and whatnot. Support for USB devices, spanning back to Windows 98. No one dared touch it unless absolutely necessary. Fortunately, no one needed to touch it too often. The functionality it offered was rich enough that the trickier logic could be implemented at application level; it decreased code reuse to some degree, but then again, this was a critical enough piece of software that the time wasted by duplicating some logic among applications was offset by the testing effort required for changes in the HAL behemoth. Most of it was okay-ish, too; it crashed under a few circumstances, but not mysteriously -- we sort of knew where the bugs were, but workarounds were available and they were generally deemed good enough.
This was a reasonable kind of turd. I mean, yes, there was technical debt in it, Jesus, it had comments like "TODO: This looks ugly but for some reason it's the only way to make it work on <some Windows 2000 build>. Maybe figure out a cleaner way?", but it didn't really bother anyone. The code was architected so that technical debt piled up on separate shelves, too. The PCI (not -X. PCI. Plain PCI) stuff, in particular, was only touched by one or two people -- but it was perfectly possible to work on other pieces of that code without breaking the drivers for those weird PCI peripherals.
2. I was responsible for one of these turds. A while ago, we had to do a lot of fancy, detailed documentation for a custom logic design. This was going to be implemented in an FPGA which was going to sit in a pretty advanced medical device -- so you spec everything before writing a single line of code.
One of the things I wrote to help me was a tool that sucked in the timing diagrams in our docs (docs were in LaTeX, diagrams were in some markup language) and generated the Verilog code that put out those signals. This was a bunch of Python code, not too hairy, but it hardcoded every single assumption I could make. It started as a tool I'd made for myself; it was reluctantly promoted to a tool that everyone used.
Some folks tried to adopt it in other projects as well but honestly, the damn thing just wasn't up to it. I suggested to (my, by this time, former) colleagues that they'd probably be better off picking a standard markup language for the timing diagrams (maybe TDML?) and write something that was going to be useful forever, more or less from scratch. Or, if not, get a commercial, off-the-shelf thing that does exactly that, written by people who were paid to write exactly that. The time, people and resources for either of these options turned out to be pretty hard to secure, though, so they ended up polishing the half-bad Verilog code by hand. Still better than writing it all by hand, I suppose.
Frankly, this was at least an excusable turd. It was never meant to be used for so much. It got promoted from "a developer's hack" to "project infrastructure" through a combination of short-sightedness, lack of awareness of better options and bad communication, mine included. But it did provide some value and, honestly, removed none -- it sucked in the end, but it still sucked less than the other alternative that was actually available.
3. And then there's real turds. Like, there was this module I saw a while ago, as part of a bunch of firefighting meetings because the original developer had quit.
When it was initially written, it was rushed in, and the first thing that got crossed out from the list was IPv6 support. And fortunately for the schedule, it turned out some bits and pieces of another feature could be reused here and there.
The end result was a massive 30,000-line... thing, that not even its creator really understood by the time he was done. A good chunk of that code was there to glue the bits that could be "reused" to the new feature. There was no abstraction layer -- when IPv6 support had to be added in, what happened was another massive dump of maybe 10,000 lines, that was interleaved with the other one via a thick forest of if-this-is-ipv4-do-ipv4-stuff-else-do-ipv6-stuff.
After humongous amounts of testing and bugfixing, it actually made its way out through the door. which effectively marked it as "too expensive to rewrite", and that was it.
Unlike the thing at #1, there was no way to extend it, in any way. Adding even the tiniest feature took weeks and spawned dozens of bugs. Unlike the thing at #2, this wasn't some internal tool, it was production code.
Truth is, it works, or at least it worked the last time I had anything to do with it. But in terms of investment it was a really bad thing to do. It was so hard to extend that there was no way to accommodate customer requirements in any sort of realistic timeframe. Keeping up with the competition basically required two engineers working full-time, on something that wasn't necessarily a critical feature but you couldn't not have it.
This turd probably removed way more value than it added. Or, if not, it certainly prevented way more value from being added. It's my standard for turds.
Yes, that’s “value” in an important sense. But people rarely add in the opportunity cost.
We make decisions every week about what can be done based on the tech debt involved. Every time we punt on an improvement, that’s a real cost. These boondoggles that forever wall off parts of the product as immutable have a cost week after week. What’s the net value after you subtract that cost? Is there any?
I don't know if it's obvious from it, so I'd rather spell it out -- there are times when "turds" are useful and not to be disdained, much like their real-word cousins: cow dung can be a good construction material and a useful fuel. Certainly worse than concrete and uranium but if that's all you can find or all you can afford, it sure beats eating raw meat and sleeping under the stars.
This isn't true of every piece of software shit in existence, though. Sometimes, "but it works" is just a bad excuse.
The antiquated turd is so profitable that it supports the entire company, the mostly-modern one is about at a break-even point of profitability after 6 years of development, and the modern one hasn't made a dollar yet.
1) Make it work [in the nominal case]
2) Make it correct [in the edge cases]
3) Make it fast [without breaking the other two]
This, plus "Make the bad people pay" gives you working software in no time.
1) Make it work, if that's important and worth the time
2) Make it correct, if that's important and worth the time
3) Make it fast, if that's important and worth the time
Most of the time is spent hunting for what the software is supposed to be. Prototype, prototype and prototype until you get even close to what it's supposed to be. Treat everything as temporary until then, before applying any real importance on any of the above. Even then, you'll rather be rewriting it anyway, focusing on what's important, because your assumptions at the beginning were most likely wrong. You shouldn't hang yourself for those early decisions just because you invested too much time and effort on making them work.
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.
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.
> 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.
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.
A "stealth" aircraft is not stealthy from all directions (nor does it need to be) but is optimized for bouncing the radar waves away from the direction of its target. The best shape for this would be to build the plane in the shape of an infinitely long flat surface, but since those are too expensive the "infinitely long" part is usually scrapped. Even shorter flat surfaces have terrible aerodynamical properties though, so there's often a compromise to make it more like a triangle. Then of course it needs to carry stuff like pilots, engines and bombs, so it can't be extermely flat but has to be bulbous. The engines need air intakes but radar waves bouncing off the rotating blades of a jet engine compressor have a very distinct signature in the frequency spectrum, so it makes sense to move the air intakes to the top of the plane where ground based radars can't shine into them. A similar thing goes for the outlets, but those need to be extremely heat resistant as well. To prevent the hot gases from flowing over an extended area of the fuselage you move the trailing edge of the triangle a bit forward. Then there are some more requirements like visibility for the pilots during take off and landing that put bounds on where the cockpit can be. Looks were very much a last consideration for the B2 and pretty much all of of its shape is due to its mission requirements :)
People love to repeat this, but it's wrong. Yes the Boeing plane was ugly with the large air scoop, but it also was a great plane whereas the Lockheed Martin plane was a terrific plane. At the time of selection, the Boeing plane could not VTOL with all the bodywork in place (landing gear doors for instance) yes the LM plane had just completed a vertical landing after a supersonic flight. Also, not since the age of propellers had Boeing designed a combat aircraft, whereas Lockheed did the SR71, U2, F117, and a host of other innovative aircraft.
The one thing that the Boeing aircraft had going for it was the single-piece wing. The JSF competition was primarily to design an affordable plane, and the Boeing probably would have been much less expensive to build and qualify.
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.
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
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.
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).
I hope that was just to prove a point and that you were wearing goggles and gloves. If not that's borderline Darwin award territory.
You just have to repaint the house to be able to use it.
The engineer might think it solves the problem and does so in a way that is seen as cheaper, easier, and faster. But in reality it's not what was needed and the elegance of the solution will come back to bite them when the first user wants the picture a bit higher (which is normally met with "why would you want to do that?")
I think you've made a "No true Scotsman" statement, in other words - just swapping "elegant" for "Scotsman."
Elegant is a superset of effectiveness.
Also, side note, I would be happy to never see this “No True Scotsman” argument ever again. 9 times out of 10 it’s just used to demonize ideas: “Your idea was used in this horrible way once”/“That mistake is not inherent to the idea”/“No true Scotsman!” That’s not what you did here. So you’re the 10th. But my point is it’s just used as a rhetorical trick, from what I’ve seen.
.... eh ? what weird definition of elegance are you using ?
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.
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)
The real world is messy, ugly, full of edge cases, and convoluted.
An elegant solution will solve 70% maybe 80% of the problem, but never all of it.
Realy great engineering, which I feel I have yet to achieve, is managing that complexity and this edge cases and the mess that is the "real world" in a way that is maintainable and manageable and works for all.
1) No new launch vehicles.
2) No new launch vehicles.
3) Whatever you do, don't develop any new launch vehicles.
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&i....
"SpaceX and Boeing spacecraft may not become operational until 2020"
https://arstechnica.com/science/2018/05/new-report-suggests-...
I don’t think anyone seriously expects NASA’s schedule to happen.
SpaceX as a Mars colonization venture on the other hand...
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.
actually he originally tried to buy Russian ICBM launch vehicles. Russia refused and that forced him to develop his own.
No New Frameworks.
No New Frameworks.
Whatever you do, DON'T write a new Framework.Reposting it here because I think it's awesome.
> 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.
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.
Jerry Pournelle's Iron Law of Bureaucracy
https://www.jerrypournelle.com/reports/jerryp/iron.html
Or the Peter Principle
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.
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"
>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.
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...
Most of the time the requirements don’t contain common sense.
Like the servers have to keep working after our ad campaign is successful...
I feel like this applies to a lot more than just spacecraft design.
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.
You are correct in your analysis. 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.
"A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately."
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".
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.
But, TBF, the real problem is dependencies.
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.
Anyone else note the significance of stopping any list of questions at 42?
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
- 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.
If you want some actual advice, read Rechtin and Meier
"The Art of Systems Architecting" ISBN-13: 978-1420079135
Appendix A Heuristics for systems-level Architecting. While the issues of mutual inconsistent advice remain, at least the rest of the book gives enough guidance in navigation through the political technical and economic issues of systems engineering.
Note: systems engineering not software engineering.
(I have a first edition and haven't seen the current 3rd edition.)
(or at least we have the same problems)
14. (Edison's Law) "Better" is the enemy of "good".
To what level this is true depends on the complexity of the system I suppose, and how accurate the requirements actually are.
> 39. Any exploration program which "just happens" to include a new launch vehicle is, de facto, a launch vehicle program.
https://hn.algolia.com/?query=Laws%20of%20Spacecraft%20Desig...
The last one was only 1 day ago.
Until 42, that was a 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.
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.
So "higher trees" might be a good way to learn how to re-engineer the idea so that you can get to the moon.
31. (Mo's Law of Evolutionary Development) You can't get to the moon by climbing successively taller trees.
You can't run a marathon in sprints.