Applying the Laws of Spacecraft Design to Everyday Life
This list of rules for spacecraft design has surprisingly powerful insights applicable to our day-to-day lives
This will seem like a Linkedin-baba article, but trust me, it is better. I don’t believe in writing articles like “10 Lessons for Startup Founders from the Israel-Palestine Conflict”. But I found these Laws of Spacecraft Design insightful enough that I promptly forwarded it to a bunch of my friends, and got back responses ranging from “What absolute gems” to “some of these have hit hard so many times”.
Space is unforgiving, and the people who make rockets that go to space, to the moon, and to Mars are Gods. And the rules of building rockets they follow can be followed by us too, to make our lives a teeny bit more godlike.
David Akin, the creator of this list, introduces it thus:
I've been involved in spacecraft and space systems design and development for my entire career, including teaching the senior-level capstone spacecraft design course, for ten years at MIT and now at the University of Maryland for more than three decades. These are some bits of wisdom that I have gleaned during that time, some by picking up on the experience of others, but mostly by screwing up myself. I originally wrote these up and handed them out to my senior design class, as a strong hint on how best to survive my design experience
You should read the entire list, but here are some of my favourites, and those of some of my friends, illustrated with examples from the lives of people who don’t design spacecraft. (This article is also available as a YouTube video on my YouTube channel or as a podcast.)
Shrikant’s favourites
(with Shrikant’s examples as bullet points)
10. When in doubt, estimate. In an emergency, guess. But be sure to go back and clean up the mess when the real numbers come along.
I do this every single time with budgeting: I want to set aside money towards future expenses, so I have an Excel sheet with buckets for these expenses. However, I often don’t know the exact amounts of these expenses, and waiting until the amounts are known would be too late. So, I start with very rough estimates and set aside money based on this. Then, as time goes by, I improve the estimates and adjust the money being set aside.
The story is similar with my clients: I can’t give them estimates on projects until many many details are in place. But clients want estimates before they will put in the effort to give the many many details. So I put in some rough estimates to get the process started, and then iterate.
Both parts of this principle are important: if you don’t do such rough estimation and guesswork (often called SWAGs: scientific wild-assed guesses), you get analysis paralysis and your ability to get things done goes down. But later, if you don’t calibrate reality against your guesses and don’t adjust your estimates (and correspondingly adjust other things) then you’ll get in all kinds of trouble
40. (McBryan's Law) You can't make it better until you make it work.
Get a shitty draft ready before you edit it to improve it
One of the most important principles of creative work: whether it is writing or designing or even programming. You have a vague vision in your head of a perfect creation but you’re unable to put it down on paper (or computer) and have difficulty getting started. I’ve delayed some projects for 5+ years because of this problem.
The inability to get started is because you don’t really know how to convert your perfect vision to a perfect implementation, so you keep thinking of possibilities assuming somehow magically you’ll get the right approach. But that never happens.
The right thing to do is to not only give up hope of a perfect implementation but even give up any pretence of a decent implementation. Just focus on getting a substandard, shameful creation completed quickly. Because you’ll discover that it is much easier for you to improve your bad creation than it is to create a good creation from scratch. Of course, you will never manage to get your perfect implementation (because see Law 33 below in Ankur’s list).
You’ll also notice that Law 10 is just a corollary of Law 40 if you think of your estimates as a creative activity.
You’ll also notice that this is you applying Cunningham’s Law to yourself!
Ankur’s favourites
33. (Patton's Law of Program Planning) A good plan violently executed now is better than a perfect plan next week.
You can see a pattern forming here: quick planning and quick iteration work better than spending a lot of effort on a perfect plan and then getting into trouble because No Plan Survives Contact With the Enemy. (If you’re not an actual general fighting a war, then replace “Enemy” with “Reality” here.) A related philosophy here is the OODA Loop (on which I’ll write an article One Day™) and the idea that faster OODA loops beat slower OODA loops. This is also the idea behind the Agile Software Development method which seems to have more or less beaten the old Waterfall method consisting of making very elaborate plans.
37. (Henshaw's Law) One key to success in a mission is establishing clear lines of blame.
If there is an avoidable failure, the reason it occurred is because someone did not take the time or effort to do whatever was necessary to avoid that failure. In case of an unavoidable failure, if there is an avoidable delay in recovering from the failure, similar reasoning applies. And the most common reason this happens in companies, or in any group activity is when it’s not clear who was/is responsible for avoiding the failure or for quick recovery. When the developer thinks it is the fault of the testing department and the testing department blames product management for unclear requirements and so on, you get increasing failures and focus on blame games instead of improvements.
Having clear lines of blame ensures that the potential blamee takes the necessary effort to reduce chances of failure in their areas of blame.
A related idea is “skin in the game”—people really put in the effort to increase the chances of a positive outcome if they risk something important (reputation, money) in case of a failure.
Akash’s favourite
(with Akash’s examples as bullet points)
20. A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately.
This is almost always seen in job interviews and candidate selection: a candidate who does not have the necessary skills will (probably) get rejected, at some point in the interview process. However a candidate who has the skills but is bad at highlighting them in the resume or presenting them during interviews will get rejected even before getting a chance to show those skills.
In my case (i.e., Akash’s), a friend and I made a website for Instagram influencers. We had a good and functioning site when we approached influencers in person. But we failed the first few times entirely because the introductory pitch wasn’t good enough and they never even checked the website. So the thing didn't even get a chance to prove its worth because of our lack of good presentation skills.
In other words, presentation matters. Communication skills matter. Far too much of our education system focuses on hard skills and completely ignores soft skills.
Navin’s favourite
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.
You don’t have infinite time, so you can never create/build anything complex that’s fail-proof. So, instead of spending too much time trying to prevent every possible failure and trying to do the right thing in every possible situation, it is often better to let it fail and build robust mechanisms to continue operating in spite of the failure, and to recover from the failure.
I think this law is interesting and non-intuitive enough that I’ll do an entire article on it next week. Stay tuned (i.e. subscribe to get articles via email)
What’s your favourite?
I’ve noticed that every person I’ve sent the article to has found a different law that resonated with them. So please check out the whole list and let me know which is the most important and why.
I think the one I find the most interesting is the same as yours but for a slightly different reason. It struck me the most when I heard it for the first time in a talk by Jeff Dean when he said that when you operate systems at the scale and complexity of the Internet, something is always going to be wrong at any given time, so you have to design to tolerate failures.
But I did not understand the full impact of this until recently I realized that pretty much everything is complex enough [1]. If I may add one more law/quote (which I got from http://johnsalvatier.org/blog/2017/reality-has-a-surprising-amount-of-detail) "Reality has a surprising amount of detail". In fact I feel lot of the laws stem from this realization. You have to tolerate failures because some details are going to go wrong sooner or later. You have to keep iterating because there are always going to be details that you didn't grasp the previous time. You have to estimate, guesstimate or approximate because there are lots of detail that can not be always perfectly captured - hence also why you shouldn't wait for a perfect plan, etc.
[1] I will give a very mundane example that is actually example of failing to apply this law rather than success :) I am anxious about forgetting routine things like bill payments. I setup a bunch of automation to protect against that so that me forgetting things is not a problem. But recently a sequence of events of losing wallet -> losing cards -> blocking them -> forgetting to update all the accounts etc lead to an automated payments failing resulting in a late payment. Not a big deal, but just an example of something as simple as that where a setup I thought was perfect did not work because "details".
This one is my favourite. 44. (Lachance's Law) "Plenty of time" becomes "not enough time" in a very short time.
I begin planning early, really early. Then realise, oh, this is not efficient. And when I wake up next, there is nearly not enough time.
Equally applicable to time you look forward to.... vacations, time with kid. When you view it a the beginning it feels like the ten days will stretch forever, and you stop counting. And before you know it.. Bam. Lachances Law.