Relationships between code structures are formed over time because we see different parts as part of a whole, which in practice we should try to avoid.
There has been a lot of work to do in the last few months, I’ve had a tough time and I need a break. My way of relaxation is reading, and I chose Liu Cixin’s “Three-Body Problem”. I never knew about this book, nor about the three-body problem, before I started reading it, but after reading it I was blown away. “The Three-Body Problem” is a science fiction novel, the first in a trilogy of past events on Earth. This book formulates a three-body problem —one of the most complex problems in classical mechanics—and tells a story around it. So let me, without spoiling the original story, do the same in my own way.
Table of Contents
three body problem
To explain the three-body problem and its connection to software development, let me start with the single-body problem. The central-force problem is more commonly known as the central-force problem. The mindful problem tries to determine the state of motion of a particle that is acted on by a central force, the source of which is a fixed force. More bluntly, stars can be considered stationary. The motion of planets can be represented by trigonometric functions .
Considering a slightly more complicated situation, let us imagine that two objects with mass affect each other’s motion state through gravity, which is the two-body problem . This can be used to describe the motion of the Earth and the Moon around each other. Or to take a better example, Pluto and Charon, as depicted in the animation below.
Pluto – Side view of the Charon system showing Pluto orbiting a point just outside it. (Wikipedia)
For many forces including gravity, the generalized two-body problem can be transformed into two single-body problems , so that the two-body problem can be completely solved. Therefore, there is also a corresponding solution to the two-body problem.
But if we add another object with mass, turning the whole system into a three-body problem, then things become unpredictable and often into chaos . For most initial conditions, the three-body problem does not have a general closed solution like the one-body or two-body problems.
Establishment of n-body problem in software development
What does the three-body problem have to do with software development? Actually it doesn’t matter. But if we think about these two things, we can see that they have similarities. Strongly coupled functions and extremely weakly coupled functions that affect each other can coexist peacefully in the same system without forcing one of them to change. Let’s compare software development to the n-body problem.
At first things were simple and easy to understand. We have a main character, a center around which everything else revolves. There are not many software functions that conflict with each other.
For example, let’s say we’re going to develop an inventory management application . All we need to do is insert new items, add and delete quantities, and know the stock status. So we have completed these functions.
After a while we need to add new stuff. It is best to open an online store to sell products online. So we started adding new features to our inventory management software.
First, a web page needs to be added . We get the stock status including the available quantity. Now the page needs to describe the status of the available stock, but it doesn’t mean that the items that were available are no longer in stock, they just changed status. So we need to set a new state in the inventory. We need to know the number of items in the “in stock” state, and the number of items in the “available for sale” state.
But now the action of getting available quantities for the web store needs to be changed to reflect this change. It doesn’t really matter how many items are in the warehouse if we can’t sell them. We only want to display “in stock” quantities in our online store. We need to modify the web store again.
The gravity of one part of the system attracts other parts to change their state of motion. There is competition between these two parts until both reach a steady state. Once we’ve optimized the functionality, things go back to how predictable they were initially. Everything is going according to plan, which makes us very happy. It is still relatively easy to predict what will happen next and know how a change in one part will affect other parts.
Two objects with “slightly” different masses moving around a common center of mass (Wikipedia)
But things can be optimized. We can provide express service for customers. So we checked the existing system and made changes every step of the way. Courier service changes inventory, inventory changes website design, website changes courier service, courier service changes inventory…
Courier services expanded commercial trade. One warehouse is no longer enough, we want to grow our business in more places, and the system needs to support this way of working. But how will this affect existing systems? Inventory needs to be adjusted to accommodate multiple locations. And since the website would reduce the number of items in stock, it also needed to be reworked to support multiple locations. But how? This in turn requires changes in inventory and delivery services as well…so confusing.
Approximate trajectories of three identical objects with zero initial velocity located at the vertices of a scalene triangle (Wikipedia)
Back to the single problem
How can we avoid this problem? How can we prevent one function from seriously affecting other functions?
The solar system has many planets with enough mass that they can affect each other’s motion state. However, if we were trying to predict the Earth’s orbit around the Sun, we could completely ignore all the planets and just focus on the Sun and Earth. This will give us a good enough initial approximation of the actual motion. The same is true for the predictions of the orbits of Jupiter and any other planet.
If we decouple the two functions of a software system , we can treat them like planets in our solar system. One planet’s gravity is not strong enough to affect the other planet’s orbit. While they do still influence each other, the changes brought about by these influences will not be very noticeable, and in some cases even non-existent.
Imagine if we were trying to calculate the date of Easter ten years in the future. Easter is a Christian holiday, on the first Sunday after the first full moon night after the spring equinox every year. Do we really care about Jupiter’s 79 moons when we calculate these dates? Of course not, and we don’t have to.
We decompose the software development solution into many small parts, and let each part revolve around the “sun”. The “sun” here can be an information broker, a service bus, or just an established contract (interface). We decide how decoupled our “solar system” needs to be. It doesn’t matter whether the widgets orbiting the sun are modules, domains, or microservices, what matters is that the widgets are as independent as possible from each other. This will make them easier to understand. Calculating the Easter date in this way doesn’t even require knowing that Jupiter has 79 moons.
It is true that the moon significantly affects the Earth’s orbit. If we are concerned with the relationship of the sun to the earth, then we are not talking about the orbits of the earth and the moon around the sun, we are only talking about the orbit of the earth. No matter how complex a function is (like Jupiter has 79 moons), in a whole system (like the solar system) we just need to think of them as a whole.
In this way we don’t need to deal with the (approximately) 1.2 million objects in the solar system, nor do we need to deal with the approximately 700 planets, asteroids or moons. We only consider the eight planets. Because generally speaking, when we talk about the solar system, we only care about these eight planets. Although this calculation is not perfect, it is accurate enough for us not to cause problems in our work.
Simplify the problem
When we think about a warehouse’s inventory, what exactly are we thinking about? Perhaps a large warehouse and the many items stored in it. What is the job of warehousing? To store goods until they are sold. Our software system should only consider these functions.
An online store should only be responsible for displaying items and creating purchases. But purchases in the online store require a change in stock status. So how to solve this problem? There are many workarounds now, but IMHO.
Purchasing is already a complex enough function. It fetches orders, checks inventory to see if items are available for purchase, executes payments, and creates shipments. This may seem like just another function, but due to its size, it can easily be broken into separate parts.
We create a strict contract for the inventory, according to the contract we can get a list of all goods, a list of all available goods, can check whether these goods can be sold and reduce their quantity. The online store only needs to know what goods are available. If we decide to support soft deletes at some point, or multiple states, like we did in the example above, the store doesn’t need to know about these changes. This can be done without the shop’s knowledge by simply changing the data received by the shop.
We need to do the same for the “Purchase” feature. The contract requires an action to complete the purchase. The store initiates this action, and its job is done. The “Buy” function takes over. It checks to see if there is an item available, then if all is well, it completes the purchase and subtracts the item count accordingly.
Looking at the whole system, we have clearly separated all the functions (some and not others) that can exist independently . We started with inventory, so of course it has its own system. Next, we added two functions of “online shop” and “purchase” that can be implemented independently.
We do have a courier service, but so far the process doesn’t need to know it exists. So we should also treat it as a standalone system. We shouldn’t force it into existing systems and make them match.
All right. Right now we don’t have a system with many functions with complex dependencies. We have many subsystems, each with a specific level of complexity, that together form a consistent and sustainable solution.
Building, maintaining, and extending software is complex. It may seem easy at first. “Just add this functionality.” But the more things we add, the more complex the equation becomes. If we try to force too many things in, we will eventually find ourselves stuck in an unsolvable problem. And there is only a thin line between the two.
For many-body problems, we can simplify the system as much as possible and divide it into many small parts. There are many people who can solve these small parts. For example, elementary school students can solve single-body problems. The three-body problem seems unsolvable. However, the difference between these two types of problems is very small at first glance. Therefore, we can use the idea of software design to try to break it into parts and make some simplified approximations to the problem.
The translated content only represents the opinion of the author and does not represent the position of the Institute of Physics, Chinese Academy of Sciences
This article comes from the WeChat public account: Institute of Physics, Chinese Academy of Sciences (ID: cas-iop) , author: Krste Šižgorić, translation: Zang Chi, reviewer: Nuor, editor: zhenni
For more such interesting article like this, app/softwares, games, Gadget Reviews, comparisons, troubleshooting guides, listicles, and tips & tricks related to Windows, Android, iOS, and macOS, follow us on Facebook, Instagram, Twitter, YouTube, and Pinterest.
Advertising statement: The external jump links (including but not limited to hyperlinks, QR codes, passwords, etc.) contained in the article are used to convey more information and save selection time. The results are for reference only. All Naijatechnews articles include this statement.