Today, I came across a true gem: Akin's Laws of Spacecraft Design. Originally written for the aerospace engineering domain. I find many parts of it relevant for software engineers as well. Below, I share my thoughts on the Laws that resonate most with my experience as a software designer and tech blogger.
As it often happens, I discovered it through Matt Rickard's newsletter.
What DALL-E thinks the image for this blog post should look like.
Level up your server-side game — join 6,500 engineers getting insightful learning materials straight to their inbox.
On Software Design
1. Engineering is done with numbers. Analysis without numbers is only an opinion.
For the better part of my career (spanning over a decade), I was producing system designs that most of the time weren't data driven. Only during my extensive preparation for passing a FAANG interview, I learned about the idea of "back-of-the-envelope calculations" and using math in general to define system requirements. Now, I almost never approach a problem without a clear understanding of the expected data volume, the load, and the required resources first, even when it means the design phase will be preceded by a non-trivial amount of exploration work including building ad-hoc tools and prototypes. And I'm still surprised by how often the numbers produced by such exploratory work prove my gut feeling on what an optimal design might look like wrong.
4. Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment.
This happens to me more often than not. The hardest part was to learn to throw away this engineering "gems" and move on with the development. In my experience, it's less about regretting not including the closest to the heart parts into the final result and more about making the timely decision to cut them out when they stop meeting the new requirements or don't fit the evolving system well anymore.
8. In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point.
I call it the "rule of balance" and it's quite universal. If a certain subsystem, or module, or even a single file is ten times bigger than average in the project, there is something wrong with the program's design. You may not feel the pain just yet, but eventually this imbalance will strike back. That's why I try to design "balanced" systems - it spreads the cost and the mental load evenly which in particular prevents the complexity from localizing and gaining a critical mass keeping it manageable. The same is true about writing - every sentence, every paragraph, every part of an essay should be more or less equally sized and loaded with an equal amount of information.
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.
Akin to Law No. 1. When requirements or constraints are too vague or you're experimenting, or urgently putting out a fire, or maybe just don't have a good idea how something that has to be done could be done in the right way, it's fine to "guess" and draft something seemingly functional but not quite meeting the quality and/or correctness bar. However, when things stabilize or after gaining more clarity on the requirements and constraints, a phase of "cleaning up" the mess is a must. For me, this rule is not just about keeping the tech debt at bay, it's also a vital technique to unblock the development in situations where otherwise you might find yourself stuck in analysis paralysis.
11. Sometimes, the fastest way to get to the end is to throw everything out and start over.
Keep this rule in mind, this might be the only way out of the mess introduced by following Law No. 10.
13. Design is based on requirements. There's no justification for designing something one bit "better" than the requirements dictate.
This is my favorite. Don't remember where I read it first, but I've been following this mantra for years. In my extended form: the program's functionality should be driven by use cases; the program's design should be driven by its functionality; the code structure should be driven by testability. It's very unlikely you'll be able to design something really future-proof. Unless you're designing it for the second time, but then the system is doomed because of other reasons.
14. (Edison's Law) "Better" is the enemy of "good".
Probably a remedy for the Second System effect (see above). This and Gall's Law (not in Akin's list): "A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system."
18. Past experience is excellent for providing a reality check. Too much reality can doom an otherwise worthwhile design, though.
It's vital to be pragmatic, but you also have to be an optimist and sometimes even a believer to succeed as a system designer.
20. A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately.
Surprisingly or not, if you want to influence fellow engineers, you have to be a good storyteller. Mastering only the hard skills won't be enough.
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.
The first time I've heard about this technique was more than ten years ago. Initially, I thought it's a joke. Working in the industry for a few years taught me it's no joke at all, but for way too long after that realization I was ashamed to use this estimation technique in my day job. Now I fully embrace it, and so should you.
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.
If there is a single skill more important than storytelling, it's drawing. I believe this blog gained most of its readership through its engaging, "never boring" technical diagrams. And to be honest, I do consider diagramming part of storytelling.
40. (McBryan's Law) You can't make it better until you make it work.
Reinforces Laws No. 13-14.
41. There's never enough time to do it right, but somehow, there's always enough time to do it over.
Reinforces Law No. 29.
43. You really understand something the third time you see it (or the first time you teach it.)
One of the main benefits of writing for me - that's how I learn (more) things and internalize them "for real".
On Writing
While writing this post, I ran into a derivative work called Akin's Laws of Article Writing - I've told you, writing is how you learn 😉
2. To write a perfect article takes an infinite amount of effort. This is why it's a good idea to write them to work when some things are wrong.
That's why I don't usually write mere How-To's. They don't age well when the underlying tech changes, and it always happens faster than you expect. When writing a technical blog post, in addition to covering the main subject, I aim to showcase my thought process and the tricks I employ to explore it. When the "hard" part of the blog post becomes obsolete, the "soft" part keeps its value for a few more years.
4. Your best writing efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment.
How often do you see write-ups compiled of sections that don't really belong together (like this one 🙈)? Even if your historical excurse to containerization tech is superb, it doesn't go well with the rest of the tutorial on building container images - it's two different topics, go split them into separate articles. Or just throw the secondary part away (the latter is harder to accept though, I know).
9. Not having all the information you need is never a satisfactory excuse for not starting the writing.
Often, much of what ends up in my blog posts is actually discovered during the writing process not before it.
10. When in doubt, compose. In an emergency, scribble. But be sure to go back and clean up the mess when the facts come along.
Morgan Housel, one of my favorite contemporary authors, writes: "Whoever says the most stuff in the fewest words wins." And Julian Shapiro once complemented this in a now-deleted Twitter thread on good writing: "Draft to messily generate ideas and then rewrite, rewrite, rewrite..."
20. A bad article with a good presentation is doomed eventually. A good article with a bad presentation is doomed immediately.
As an author, it's crucial to master both the art of writing (content) and the mechanics of distribution (media). If only ten people read your perfect writing, it's a semi-wasted effort. You still gain from writing even when it happens for an audience of one, but the returns would be much higher with a successful social media game. One particularly important skill to master is titles - a good title is responsible for 80% of the future article performance on Reddit, Twitter, or Hacker News.
The list ends here. Draw your own conclusions.
Level up your server-side game — join 6,500 engineers getting insightful learning materials straight to their inbox:
