Why there are no simple solutions that it is better to buy servers or optimize code
In response to this article , about the choice of buying servers or optimization.
I would like to touch upon the factor of human psychology in decision making, its underestimation and the importance of influencing the final result.
At the bottom of the article there is a brief summary, who does not want to read.
Indeed, there is such a widespread belief that iron is easier to buy and more reliable than optimizing code.
Another question is, have there been any reliable research on this topic? I think not, and this only confirms the theses of the article “Programming, as a new kind of human activity” .
')
However, we will try to build a mental experiment with some assumptions. The market is a place for natural selection. Companies are selected by survival. The one who served the client better, earned more money and managed to stay on the market, beat the competitors - he survived. Feedback ensures the evolution of companies.
And judging by the fact that companies both invest millions of dollars both in human potential and in servers, both approaches are taking place, perhaps even their combination. What was said in the original article in the comments (combinations of approaches are not uncommon in other cases in life, for example, hawks and pigeons ).
From which we can conclude that both approaches exist, and there is a third - proportioning. And the success of their application is determined by the company's survival in the current market conditions, which, of course, cannot be reduced to a simple formula “what is cheaper”.
Just remember, for example, the phrase “Strategic miscalculations cannot be compensated by tactical successes” von Clausewitz, as well as examples of strategic decisions of companies that did not lead to immediate cost reductions (Apple: iPad, iPhone, Google: PR, etc), but ensured a convincing success on the market.
Many things to business and project management, however, boil down to simple models. That, of course, does not negate the limitations of such models.
The point is simple - you have two or more entities, one of which cannot be substantially developed without the other. Peculiar deadlock.
For example, you are a startup. You need to hire programmers, but there are no customers yet. But there are no customers, because there is no product that the programmer creates with his work. And until the idea of ​​addressing the topic through investors spread, there was no such abundance of startups.
But a more complex example is the choice of project architecture in an unfamiliar market. To design the architecture, you need to get real business requirements. A business requirements will appear as an appetite, coming with food, only during the operation. The solution is "herak, herak and in production", in more harmonious names from different specialists - Agile, Continuos Integration, BDD and so on.
The value of understanding the situation through such modeling is that you can transfer the solution experience from one sphere to another.
Just the problem of choice - optimization of the code or the purchase of servers - sometimes comes down to this one.
The decision pattern is to take one of the sides as the base one, and express the other through it with some formula.
Usually, you can’t just take a project and put a second server, you still need preparation for scaling.
And at the same time the server is purchased by a certain calculation.
The solution is a phased approach with a little research, when you do a phased scaling, simultaneously determining the dependence of the improvement of the required parameter (the speed of response of certain pages, for example) on the number and purpose of servers.
There is a moment that I casually touched on above. The fact is that we are essentially modeling the situation in our head. And there is always some kind of mistake, the difference between reality and the model in the head. This must be remembered, and not reduce the problem to either the adoption of a unique solution, a la silver bullet, or to the single application of measures.
Simplifying a situation usually costs too much. For example, when the opinion of the lead developer is ignored, that the architecture is shit and technology needs to be changed, and the decision maker (the decision maker) is sure that in the old way he will simply buy another database and a web server (because he used to roll), this leads to idle times in the work of the project and inability to respond to the challenges of the market, which often ends fatally.
As well as the importance of the work of administrators (and hiring expensive, good, suitable administrators), without which poorly configured servers can also do a poor service. For example, a poorly tuned Postgres database can kill all the advantages that it would give when scaled.
In general, in the original article, admins are almost not mentioned, for example. Sometimes tuning the system administrator can speed up overall performance, replacing screws on his advice - dramatically increase the speed of the project, and timely advice to increase the thickness of the channel - to remove the risk with a rapid increase in traffic.
But this generally does not apply to code optimization, nor to the purchase of new servers, and at the same time it can close the lion's share of problems.
By the way, did you know that a good admin is usually a great programmer, a specialist in process automation, and much more than a good fairy?
As already noted, the psychology of the participants is important.
Or rather, cognitive distortion .
It may be noted, for example, the problem when people get down to already proven solutions, as well as the fact that, on average, a person does not like to risk.
But the enormous harm that I personally attribute to the problems of the first order is in reassessing my capabilities and abilities.
There is even a special effect that is in the title, which says that the smarter and more experienced a person is, the more he doubts his abilities. And the more he is an amateur - the more self-confident and inclined to make wrong conclusions and actions in a given area of ​​activity.
For me, a typical example is the phrase about refactoring. As is known, much in nature has a normal distribution, including, according to some sources, the talents of people. As Brooks writes, capable and ordinary programmers differ in performance tenfold.
It can be assumed that there is also a large spread in the quality of work. However, due to the lack of objective quality metrics, such studies are few.
Nevertheless, such a situation is quite typical. The choice is made in favor of total code optimization. Programmers are not clearly given the task of a manager who is confident in his abilities - just saying “do refactoring to fly” is enough.
Programmers break the manager "to rewrite everything in OOP on the latest version of the framework / standard" (some simple for a beautiful, but monstrous and heavy symfony, or to rewrite the old code on the pluses with a demonstration of the knowledge of all stl) to make it "just like in books / at the guru "(we tackle patterns).
As a result, a code is written that slows down 10 times more, eats memory, processor time, but which is easier to maintain at times.
Having failed the deadlines, the authorities bring in more competent PMs and architects, who either make urgent fixes and buy more iron, or rewrite from scratch (as time permits).
For business, the situation looks understandable - programmers and PMs have cheated, have not improved anything. I had to involve the gurus, and they costly changed something quickly and bought servers. So, it is possible to squeeze something out of my guys quickly and make them buy servers.
At the same time, a self-confident businessman does not listen to the words of the guru about “the need for clear statement of requirements, hiring expensive specialists, engaging an architect to select a stack of technologies in development, highlighting special stages of optimization for scaling”, considering the words incomprehensible to him as another trick of people to distract resources and potentially missed opportunities.
Therefore, the habit of doubting your “facts” before making important decisions is a good way to gradually grow over your own delusions.
The original problem does not boil down to the simple factor "what is cheaper." And, as Demarco and Ashmanov wrote, a lot lies in the plane of human relations, and in the plane of the personality psychologists of the participants in the process.
Which, in my opinion, insufficient attention is paid.
The following does not apply to cases, for example, when you have one site that began to slow down with 1000 visitors per day, because it is CMS ***, ****** or *******, and there is one person in the company (i.e. you).
1. Before making a decision, research is needed with the participation of high-class technical specialists.
2. As a result of research, it is necessary to understand the current situation and obtain from decision-makers a further vector of project and business development.
3. After this, an understanding should appear:
- what resources at the moment can be allocated (monetary, human, temporary) to overcome the problem
- what are the terms of solving the problem and implementing the solution
- what risks and how to work with them if the current problem cannot be overcome
4. Separately, you need a clear identification of requirements for performers - programmers, administrators. Sometimes admins can save your project without purchasing servers or optimizing the code, just pay them well. Like programmers.
5. After that, you need to perform an iterative solution to the problem, each time selecting the optimal ratio of resources for optimizing the application code, tuning servers for administrators and purchasing hardware.
6. After achieving the required indicators, create a business process (or improve) aimed at strategic work on quality for the given metrics (expected traffic growth, increase in space occupied by screws, and so on). The process must sometimes allow a complete change of the technology stack, if necessary.
I would like to touch upon the factor of human psychology in decision making, its underestimation and the importance of influencing the final result.
At the bottom of the article there is a brief summary, who does not want to read.
As usually happens and why
Indeed, there is such a widespread belief that iron is easier to buy and more reliable than optimizing code.
Another question is, have there been any reliable research on this topic? I think not, and this only confirms the theses of the article “Programming, as a new kind of human activity” .
')
However, we will try to build a mental experiment with some assumptions. The market is a place for natural selection. Companies are selected by survival. The one who served the client better, earned more money and managed to stay on the market, beat the competitors - he survived. Feedback ensures the evolution of companies.
And judging by the fact that companies both invest millions of dollars both in human potential and in servers, both approaches are taking place, perhaps even their combination. What was said in the original article in the comments (combinations of approaches are not uncommon in other cases in life, for example, hawks and pigeons ).
From which we can conclude that both approaches exist, and there is a third - proportioning. And the success of their application is determined by the company's survival in the current market conditions, which, of course, cannot be reduced to a simple formula “what is cheaper”.
Just remember, for example, the phrase “Strategic miscalculations cannot be compensated by tactical successes” von Clausewitz, as well as examples of strategic decisions of companies that did not lead to immediate cost reductions (Apple: iPad, iPhone, Google: PR, etc), but ensured a convincing success on the market.
Closed loop problem
Many things to business and project management, however, boil down to simple models. That, of course, does not negate the limitations of such models.
The point is simple - you have two or more entities, one of which cannot be substantially developed without the other. Peculiar deadlock.
For example, you are a startup. You need to hire programmers, but there are no customers yet. But there are no customers, because there is no product that the programmer creates with his work. And until the idea of ​​addressing the topic through investors spread, there was no such abundance of startups.
But a more complex example is the choice of project architecture in an unfamiliar market. To design the architecture, you need to get real business requirements. A business requirements will appear as an appetite, coming with food, only during the operation. The solution is "herak, herak and in production", in more harmonious names from different specialists - Agile, Continuos Integration, BDD and so on.
The value of understanding the situation through such modeling is that you can transfer the solution experience from one sphere to another.
Just the problem of choice - optimization of the code or the purchase of servers - sometimes comes down to this one.
The decision pattern is to take one of the sides as the base one, and express the other through it with some formula.
Usually, you can’t just take a project and put a second server, you still need preparation for scaling.
And at the same time the server is purchased by a certain calculation.
The solution is a phased approach with a little research, when you do a phased scaling, simultaneously determining the dependence of the improvement of the required parameter (the speed of response of certain pages, for example) on the number and purpose of servers.
Simplification effect
There is a moment that I casually touched on above. The fact is that we are essentially modeling the situation in our head. And there is always some kind of mistake, the difference between reality and the model in the head. This must be remembered, and not reduce the problem to either the adoption of a unique solution, a la silver bullet, or to the single application of measures.
Simplifying a situation usually costs too much. For example, when the opinion of the lead developer is ignored, that the architecture is shit and technology needs to be changed, and the decision maker (the decision maker) is sure that in the old way he will simply buy another database and a web server (because he used to roll), this leads to idle times in the work of the project and inability to respond to the challenges of the market, which often ends fatally.
As well as the importance of the work of administrators (and hiring expensive, good, suitable administrators), without which poorly configured servers can also do a poor service. For example, a poorly tuned Postgres database can kill all the advantages that it would give when scaled.
In general, in the original article, admins are almost not mentioned, for example. Sometimes tuning the system administrator can speed up overall performance, replacing screws on his advice - dramatically increase the speed of the project, and timely advice to increase the thickness of the channel - to remove the risk with a rapid increase in traffic.
But this generally does not apply to code optimization, nor to the purchase of new servers, and at the same time it can close the lion's share of problems.
By the way, did you know that a good admin is usually a great programmer, a specialist in process automation, and much more than a good fairy?
Dunning-Kruger effect
As already noted, the psychology of the participants is important.
Or rather, cognitive distortion .
It may be noted, for example, the problem when people get down to already proven solutions, as well as the fact that, on average, a person does not like to risk.
But the enormous harm that I personally attribute to the problems of the first order is in reassessing my capabilities and abilities.
There is even a special effect that is in the title, which says that the smarter and more experienced a person is, the more he doubts his abilities. And the more he is an amateur - the more self-confident and inclined to make wrong conclusions and actions in a given area of ​​activity.
For me, a typical example is the phrase about refactoring. As is known, much in nature has a normal distribution, including, according to some sources, the talents of people. As Brooks writes, capable and ordinary programmers differ in performance tenfold.
It can be assumed that there is also a large spread in the quality of work. However, due to the lack of objective quality metrics, such studies are few.
Nevertheless, such a situation is quite typical. The choice is made in favor of total code optimization. Programmers are not clearly given the task of a manager who is confident in his abilities - just saying “do refactoring to fly” is enough.
Programmers break the manager "to rewrite everything in OOP on the latest version of the framework / standard" (some simple for a beautiful, but monstrous and heavy symfony, or to rewrite the old code on the pluses with a demonstration of the knowledge of all stl) to make it "just like in books / at the guru "(we tackle patterns).
As a result, a code is written that slows down 10 times more, eats memory, processor time, but which is easier to maintain at times.
Having failed the deadlines, the authorities bring in more competent PMs and architects, who either make urgent fixes and buy more iron, or rewrite from scratch (as time permits).
For business, the situation looks understandable - programmers and PMs have cheated, have not improved anything. I had to involve the gurus, and they costly changed something quickly and bought servers. So, it is possible to squeeze something out of my guys quickly and make them buy servers.
At the same time, a self-confident businessman does not listen to the words of the guru about “the need for clear statement of requirements, hiring expensive specialists, engaging an architect to select a stack of technologies in development, highlighting special stages of optimization for scaling”, considering the words incomprehensible to him as another trick of people to distract resources and potentially missed opportunities.
Therefore, the habit of doubting your “facts” before making important decisions is a good way to gradually grow over your own delusions.
findings
The original problem does not boil down to the simple factor "what is cheaper." And, as Demarco and Ashmanov wrote, a lot lies in the plane of human relations, and in the plane of the personality psychologists of the participants in the process.
Which, in my opinion, insufficient attention is paid.
To sum up
The following does not apply to cases, for example, when you have one site that began to slow down with 1000 visitors per day, because it is CMS ***, ****** or *******, and there is one person in the company (i.e. you).
1. Before making a decision, research is needed with the participation of high-class technical specialists.
2. As a result of research, it is necessary to understand the current situation and obtain from decision-makers a further vector of project and business development.
3. After this, an understanding should appear:
- what resources at the moment can be allocated (monetary, human, temporary) to overcome the problem
- what are the terms of solving the problem and implementing the solution
- what risks and how to work with them if the current problem cannot be overcome
4. Separately, you need a clear identification of requirements for performers - programmers, administrators. Sometimes admins can save your project without purchasing servers or optimizing the code, just pay them well. Like programmers.
5. After that, you need to perform an iterative solution to the problem, each time selecting the optimal ratio of resources for optimizing the application code, tuning servers for administrators and purchasing hardware.
6. After achieving the required indicators, create a business process (or improve) aimed at strategic work on quality for the given metrics (expected traffic growth, increase in space occupied by screws, and so on). The process must sometimes allow a complete change of the technology stack, if necessary.
Source: https://habr.com/ru/post/232369/
All Articles