How to assess the feasibility of an engineering solution using first principles?

Hello, friend. This is an interesting question, and it's not as mysterious as it sounds. 'First Principles Thinking,' simply put, means 'getting to the root of things, returning to the essence.'

Imagine you're not an engineer, but a chef who wants to create a dish 'never before seen.'

How would most chefs approach this? They'd look for existing recipes, like how to make braised pork belly, then tweak it slightly, add some new spices, and turn it into 'secret recipe braised pork belly.' This is optimizing within an existing framework.

But how would a chef using first principles think? They would ask:

1. What is the ultimate goal of this dish? It's to give diners an experience that is 'rich but not greasy, melts in the mouth, and is savory with a hint of sweetness.'
2. To achieve this goal, what are the most fundamental elements? They are the fat and protein in pork, amino acids in soy sauce, caramelization reactions of sugar, and the temperature and pressure of water. These are physical and chemical laws, unavoidable 'axioms.'
3. What are our past assumptions? For example, 'it must be stewed in an iron pot for a long time.' But they would question: Why? Is it to ensure even temperature? Or to make the meat tender? Are there other ways to achieve the same effect? Like using a pressure cooker? Or slow-cooking at a low temperature first, then quickly searing for color?

You see, they don't start from the 'solution' of 'braised pork belly,' but from the 'goal' of 'texture' and the 'essence' of 'physical and chemical laws,' recombining them to forge an entirely new path.

Returning to engineering solutions, the process is the same:

Step One: Deconstruct your solution's goal to its 'original form.'

Don't immediately say, 'I want to build a bridge' or 'I want to develop an app.' You need to ask, what is the most fundamental purpose of doing this?

• It's not 'to build a bridge,' but 'to allow 10,000 people per hour to safely cross this river.'
• It's not 'to develop an app,' but 'to enable users to complete an order within 30 seconds.'

Separate the solution (building a bridge, making an app) from the goal (crossing the river, placing an order). The goal is your 'first principle.'

Step Two: List the 'unavoidable rules' for achieving this goal.

These are the 'hard truths' of physics, mathematics, and chemistry.

• River crossing problem: Gravity, water flow speed, geological conditions of the riverbed, strength limits of existing materials (how much tension can rebar withstand), the law of conservation of energy. These are the rules of the game you must obey; no one can change them.
• Ordering problem: The ultimate speed limit of information transmission (speed of light), server data processing capability, user phone performance, the reaction speed of human eyes recognizing information and fingers tapping.

In this step, you need to calculate the 'theoretical limits.' For example, according to the conservation of energy, what is the absolute minimum energy required to move a ton of something from point A to point B? Calculate that number. If your proposed solution requires significantly more energy than this theoretical value, you need to ask 'why?'

Step Three: Question all 'taken-for-granted' assumptions.

This is the most crucial step. Our minds are filled with too much 'common sense,' 'industry practice,' and 'best practices,' which often become the biggest obstacles to innovation.

• River crossing problem: 'To cross a river, you must build a bridge.' Really? Can you dig a tunnel? Can you use a fleet of super drones for ferry service? Can you drain the river for a few minutes and then refill it (though absurd, this is how you should think)?
• Ordering problem: 'An order must have a shopping cart.' Really? Can it be a one-click order? Can it be a voice order? 'Servers must be written in Java.' Really? Would Go or Rust be faster and more resource-efficient?

You need to be like a three-year-old, asking 'why?' about every 'rule.' List these assumptions one by one, then verify if they are the optimal solution under the physical rules established in 'Step Two.'

Step Four: Recombine the solution, starting from the 'essence.'

Now you have: a pure goal (Step One), a set of insurmountable physical rules (Step Two), and a bunch of old assumptions you've broken (Step Three).

Alright, now you can start 'building with blocks.'

Take Elon Musk's SpaceX as an example:

1. Goal: To send people and cargo into space, and to do so extremely cheaply.
2. Physical Rules: Sending a rocket into space requires overcoming Earth's gravity, which consumes a large amount of fuel and adheres to the rocket equation (Tsiolkovsky rocket equation). Rocket materials are primarily aluminum alloys, titanium, and other metals.
3. Questioning Assumptions: 'Rockets are expendable.' Musk asked: Why? Does a Boeing 747 throw away an engine after every flight? No. So why should rockets be thrown away? It's simply because no one had successfully made them reusable before.
4. Recombination: He investigated the raw material cost of rockets and found it accounted for only about 2% of the total cost. The conclusion was: rockets are expensive not because the materials are costly, but because they are 'thrown away.' Therefore, if rockets could be recovered and reused, the cost could be reduced to one-tenth or even less. Thus, the company's core objective became 'developing reusable rockets.'

To summarize:

To judge the feasibility of an engineering solution using first principles, it means:

Don't look at how fancy the solution itself is, and don't care if everyone else does it that way. Just break it down into its most basic physical/mathematical units and calculate the 'theoretical limit.' If it's theoretically impossible (e.g., violates the conservation of energy), then it definitely won't work. If it's theoretically possible, then see how much your solution deviates from the theoretical limit; that gap is where you can innovate and optimize.

This is a way of thinking that is exhausting because you have to constantly calculate and question. But once you figure it out, you can often find paths that others don't see.