Full-stack developer and their economic principles

Recently, forced to make a living, re-study the principles of economics, just to review the comparative advantages, so I combined my own job and wrote such a thing similar to a small exercise after class.

Comparative Advantage

Before talking about software development, let's briefly clarify the basic concepts (the correctness is not guaranteed, and I am not studying economics).

To talk about comparative advantage, according to the sequence of the textbook, we must first understand what absolute advantage is. For the convenience of explanation, I just copy the textbook example (so that my cost is the lowest): Suppose there are two people A and B, these two people produce beef and potatoes, and both of them eat beef and potatoes. We assume that their production capacity meets the following table:

Obviously, B is a more skillful person than A. Because whether it is talking about beef production or potato production, B's output per hour is higher than that of A. This is the absolute advantage.

However, the absolute advantage of B does not mean that B has to produce alone. We assume that they work for 8 hours, and according to the preferences of A and B, their respective output when they produce alone conforms to the following table:

However, we noticed that although A is a not very productive, he is actually better at producing potatoes. Although this kind of goodness may be based on that A is really bad at producing beef.
Now, considering the low productivity of A, we let A and B produce together, and A specializes in the production of potatoes, and B reduces the production of potatoes. After the transaction, we can get the following table:

The result is that A and B get more things every day.

The comparative advantage means that A can produce potatoes with less opportunity cost than B. After all, A is too bad at producing beef, and there is almost no opportunity cost for him to produce potatoes.

Software development

Let's change the background of the above example and change the production of beef and potatoes into the production front-end and back-end code. We assume that the ratio of front-end code to back-end code required for a usable website is 1:1. In other words, a rough assumption is that a front-end function must correspond to a back-end function.
Although in reality, it is obviously not 1:1, but in my example, adjusting the ratio to 2:1 or even 1:100 should be the same result. However, the case of 0:1 or 1:0 is excluded.
At the same time, it needs to be clarified that the software development is also inseparable from the support of devops, but in order to simplify the calculation, we reluctantly ignore the work of devops here. But in reality, devops are also very important. In the same way, QA, BA, and even company management have played a vital role in software development, but for the sake of simplifying the model, they are temporarily ignored in the example.

Similarly, for two Devs: A and B, the amount of front-end and back-end code they can produce in one hour is shown in the following table:

Obviously, A is better at the back-end, but B is obviously a front-end expert. Now we let these two people work for 9 hours to produce the website (in order to simplify the calculation, so changed to 9 hours). Let's consider they develop the website separately:

Here we can first find the diversity of people:
From the perspective of high productivity, it is reasonable that B is still very productive. After all, the front-end production capacity is twice that of A!
On the other hand, from the perspective of independent work, it seems that A is still awesome, after all, it has 50% more website delivered than B!

Before reaching the optimal solution, we first consider that A is fully working on the back end, and B is fully working on the front end, we get the following output table:

In this way, the total delivery number of the website is 36, which has exceeded the output produced by A and B respectively (12+8=20). Here, we can clearly see why many top company before and now have adopted waterfall development, and let the front and back ends completely separate the development model.

But this is obviously not the end, because we saw that B produced 36 more front-end codes, which wasted capacity. So we let B spend only 5 hours on the front-end every day, and another 4 hours to write the back-end, we can get the following output table:

We found that the number of sites delivered in this way became 40 copies, which once again increased productivity.

Full-stack developer

We first consider the definition of full-stack developer:

A full-stack engineer refers to a person who has a variety of skills, is competent at the front and back ends, and can use multiple skills to complete products independently.

This definition cannot be said to be wrong. But I personally think that this definition can easily lead to a misunderstanding: because this person has the ability to complete the product independently, this person must complete the product independently. I think this is wrong.

Taking the above example as an example, it seems that A is actually more full-stack than B, and indeed, when the product is completed independently, A's production capacity is higher than B. But we can see that in the project that A and B work together, A is specialized in the back end, while B is the person who is really "full stack".

Therefore, I personally believe that as long as it have the ability to complete development independently, it is full-stack developer. Although the skill of full-stack developer may be uneven. But as long as a certain output of a person is 1 not 0 (strictly speaking, as long as it is not close to 0), then this person is a full stack developer.
As for the full stack developer, what exactly they do depends on project situation.

Prediction

I personally think that as the industry develops, full-stack developer may gradually become mainstream. Because this can actually improve production efficiency.
But the meaning here is that the market value of a pure front-end or a pure back-end will decrease.
The meaning here does not mean to develop evenly, cover everything, and have no specialties.

Some limitation

Although, the high probability can be analogous to devops, QA and so on. However, considering the recruitment process and the cost of verification, it is not certain that the full stack will become mainstream in the future. After all, I don’t understand commercialization. This is just an inference based on the textbook.