Using First Principle Thinking to Stress Test your Technical Architecture
First Principle Thinking (FPT) came onto my radar when watching an interview of Elon Musk talking about SpaceX. I had heard of FPT before, but like most nerds I pay special attention when the Techno-King speaks up in his idiosyncratic way about his secrets behind making the future.
In the interview, Musk said:
“I tend to approach things from a physics framework. Physics teaches you to reason from first principles rather than by analogy. So I said, okay, let’s look at the first principles. What is a rocket made of? Aerospace-grade aluminium alloys, plus some titanium, copper, and carbon fibre. Then I asked, what is the value of those materials on the commodity market? It turned out that the materials cost of a rocket was around two percent of the typical price.”
Since watching this I have been exploring FPT and trying to apply it to my work — architecting and implementing technology solutions for (typically) web and mobile applications and services.
What is First Principle Thinking
FPP is best described in the FPP blog as:
Reasoning by first principles removes the impurity of assumptions and conventions. What remains is the essentials. It’s one of the best mental models you can use to improve your thinking because the essentials allow you to see where reasoning by analogy might lead you astray.
To use an analogy (slightly ironic, yes), FPP is like cooking. To be a good cook you have to understand why ingredients work in concert with each other and what process is required to combine them together effectively. A chef who just follows recipes (reasoning by analogy) will never understand the why behind the cooking and not succeed in creating consistently delicious grub.
Returning to the process of designing technical solutions for digital apps and services — or what is termed technical architecture — FPP can be a very useful tool to interrogate and validate your decisions, and get a deeper understanding behind the reasoning for them.
Why Apply FPP to Technical Architecture
When architecting solutions, it is very easy to reason by analogy, or select technologies or implementation approaches without the solid reasoning behind them. Some common factors behind this include:
- The Shiny Factor. The tech is new and cool and the devs really want to use it. See any number of new front-end frameworks.
- The Star Struck Factor. A new star in the digital space emerges and others follow the engineering decisions behind it to try and recreate success. See Netflix or Spotify.
- The Ceremony Factor. Everybody is talking about how great this design pattern is for solving a certain problem. This will be problematic if followed (almost ceremonially) and applied to the wrong problem. See Micro Frontends.
Applying FPP to technology decision making is important because it means you prevent yourself from falling into some of the traps identified above, and having to engineer yourself out of a deep hole. I have seen this often, and at an enterprise scale, can incur great cost and inhibit business growth.
How to Apply FPP Thinking
The FPP blog describes using Socratic thinking as a framework for getting down to first principles. Some pointers include:
- Clarifying your thinking and explaining the origins of your ideas (Why do I think this? What exactly do I think?)
- Challenging assumptions (How do I know this is true? What if I thought the opposite?)
- Looking for evidence (How can I back this up? What are the sources?)
Considering alternative perspectives (What might others think? How do I know I am correct?) - Examining consequences and implications (What if I am wrong? What are the consequences if I am?)
- Questioning the original questions (Why did I think that? Was I correct? What conclusions can I draw from the reasoning process?)
A more simple approach is the 5 Whys. A blunt (but effective) approach to keep asking ‘WHY’ until the true reason is unearthed, and understood.
A FPP Cheat Sheet
Broadly, applying FPP to architecture involves questing any or all significant technical decisions to get to the ‘Why’.
To get you started, here are a collection of questions that cover general business, operational and development needs.
- What are the main assumptions I’m making about the business need?
- Should any of these assumptions be challenged?
- What are the main assumptions I’m making about the development process?
- What is the operational environment and the way the software will be managed?
- What is the longevity of the solution
- What is the necessary flexibility of the solution?
And some specific examples related to common front-end, backend and APIs and platform decisions.
- Do I really need a front-end framework?
- Is a Monolith really that bad?
- Do we need a CMS at all?
- Do we even need a database?
- Is the benefits of serverless really needed here?
- Is ‘Headless’ really the best architecture for my CMS?
- Are Micro-frontends worth the headache?
- What do we mean by hybrid architecture?
- Will we have enough data to get benefit out of a big data analytics pipeline?
The questions above are examples of interrogators against common analogous decisions made. There are many more examples and I’d be interested to hear of more, or of experiences where analogous thinking has led you down a thorny path.
We’ve all undoubtedly made choices without really digging into to the why, but with conscious effort to apply FPT, at the very least your decisions will be validated and, at best, help you will avoid (and to round off with a final analogy) getting tangled in a paralyzing web of complexity.
