On the relationship between Software Engineering and Physics
It's about drawing correct relationships
As a product person, every time I wanted to build a software application I would start with wireframes (i.e. frontend)
I would then figure out what business logic would be needed (i.e. backend)
And finally, decide what the data model should be (i.e. database)
After working with sometime with Matt Magaldi, our head of engineering, I would notice that he would always start in the opposite order.
He would understand the real world, define the data model that reflects the world, build the business logic that manipulates the data model, and then decide how to show it to the user.
At first, I didn’t understand why but after building for some time, I now realize that all great product is based on deciding the right data model. Matt Brown does an excellent job at explaining this in his post, “Your data model is your destiny”.
But what does defining a data model mean? This post is intended to draw an analogy to physics, show how software engineering and physics are related, and show how this relationship is becoming increasingly important in the era of “vibe coding”.
Physics
A physics formula is no more than describing the relationship between two things. For example, E=mc^2 is simply stating that the relationship between energy (resource #1) and mass (resource #2) is proportional to the speed of light squared.
Another example is the circumference of a circle. The radius (resource #1) is related to circumference (resource #2) by 2*the constant pi.
What physicists do every single day for years is simply to find new relationships between resources. This is what it means to discover a formula!
In the example above, both relationships are correct. However, one is a more simple representation of it.
Software engineering
In software engineering, when architecting a system, one is looking at the real world and trying to decipher: (1) What are the resources? and (2) What is the relationship between those resources?
In Matt Brown’s example in “Your data model is your destiny”, when Notion and Google Docs looked to solve the problem of an organization’s knowledge base, Notion saw Blocks as the resource, Google Drive saw Documents.
Slack saw persistent channels. HipChat saw 1:1/group messages.
The most important decision product/engineering teams need to make is to decide on the data model. The thinking required to do this well is similar to that of a physicist discovering a formula.
Novice engineer — can’t figure out the right relationship
Good engineer — can figure out the relationship but it’s complicated
Great engineer — describes the pure relationship
Today, where AI can increasingly handle most of the implementation, value is pushing up to defining the data model. Like a physicist, figuring out the right relationships requires observation, thinking, and time.
The data model is like the physics equations while the Frontend wireframes and UX is like direct observation. You can’t have one without the other. It’s a chicken and egg problem. If you have a good understanding of the field, then you should start with the data model. If you don’t understand the field, start with UX and direct observation which will help you put together the underlying equations and models. In both scenarios, you eventually get in an equilibrium state where direct observation and data models are in a positive feedback loop with each other - each one enables you to advance. Each full “period” is 1 “iteration”.