The illusion of effective development: management
I would like to discuss an unpleasant topic for many, namely, your illusions. Illusions and beliefs about the integrated process, which is called software development. Let us immediately define what illusion is in this context — it is such a person’s conviction that is not supported by clear scientific evidence.
Software development is permeated with such beliefs at all levels, ranging from the choice of programming language, moving to design technology, and ending with project management technology. Interpreting the results of the results of a successful project, if you decide to test some method using his example, can also mislead you if you are not configured as skeptical as possible. In this series of articles I will try to give you several starting points for analyzing the effectiveness of a particular development methodology. To some extent, everything that will be written below is just a detailed description of the main idea of ​​the site programming-otherfucker.com .
Let's start with project management, as an area where the search for truth is the most difficult. And if at least one person, after reading this article, refuses to introduce in his project a fashionable development methodology, based only on its popularity, I can assume that the time to write this text was not wasted.
Perhaps the following statement will seem absurd and impractical to you, but it is: it is impossible to accurately measure the effectiveness of a software development methodology. The reason is simple - to get accurate results, we need to start the process of developing the project of the same team, in the same language, with the same managers, at the same time. But with different approaches to development. Provided that you have medium managers who are familiar with each of the development methods, about the same. And also provided that all communication will take place in a purely official tone and only in text form in order to exclude the possibility of the influence of charisma / whining / motivation of managers on the development process. Rave? Can you refute on the merits?
')
Of course, there are things, the benefits or harms of which are obvious, and most importantly, provable. But it is necessary to take a step aside and we will plunge into the pool, where the ball is ruled by a case where credibility lies within the framework of statistical error, and the main argument is defying personal experience elevated to the rank of truth. Simply put we get into real life.
And that's it. No true, what are the main sciences studying human behavior? That's right, it's psychology and sociology. Both have existed for a long time, at the disposal of both huge amounts of information - the media, history, countless experiments. Nevertheless, none of these sciences are able to predict the behavior of a person, a social group, a nation with a high degree of probability, unless of course this is a trivial situation.
This was said to the fact that the whole theory of management is ultimately the same science of people, only more young, with several different schools. And, you will not believe it, but all these approaches, which are often contradictory ... work! In any case, the adherents of each school think so. In any case, successful projects are under the banner of each school, and failures can be attributed to a thousand reasons not related to management techniques.
This fact should lead us to the conclusion that the choice of management methodology is not decisive for the project. Then it is logical to transfer the view from the method to the person using it. The human factor is the only thing that can explain this random triggering of the methodology, although let's be honest, there may be a lot of reasons - an objective lack of budget, unrealistic deadlines, a weak level of programmers, etc.
During my modest career I had to deal with different management models. There was a purely gangster variant, when programmers were called and threatened to make them work. The most common model for small teams is one boss, up to a dozen programmers, there is no methodology as such, or there are borrowings from everywhere. Startups are either abraded, or agile and derivatives, or a herd of developers, where the leader is more like TK than human. Large teams - confusion and vacillation from one department / team to another, recently the same agile has been fixed.
At the same time, all these projects, from large to small, are alive and well, and also fail. The same technique used in different projects can lead to different results. It is logical to assume (disregarding all other factors) that the result depends on who uses the technique. Will it be possible to motivate the team for productive work? How successful will the negotiations be with the customer (he is also a person)? Will it be possible to persuade programmers to work for ghostly perspectives? Will it be possible to organize such an atmosphere that the programmer himself did not want to go to the competitors? How accurate will the timing and price be calculated? Will the manager be able to formulate the client's requirements so that the team does not resolve conflicts in the TK before the date of the delivery?
For the most part, these questions lie outside the existing methodologies, or the use of methods in solving these questions is not decisive. The decisive factor here is the personal qualities of a person, no matter how sad it may sound, and it is they who, despite a poorly set project management method, can lead to success, or, despite the most advanced project management, fail the project.
Therefore, before evaluating the next development methodology, sort through all the familiar managers in memory and give yourself an honest answer, but will they cope with the task and subordinates?
Do I have to say to what extent the result of the project depends on them? It is necessary. In addition to the obvious level of professionalism in their field, you need to understand that the following factors matter:
Many problems can be solved with money, what can we say about the number of problems that cannot be solved without money. We will not consider an obvious example, when a startup is falling apart a couple of months after its creation due to the fact that hunger for programmers turned out to be stronger than belief in a brighter future. It is quite obvious that it depends on the project budget (to some extent) on how much professional programmers you hire. It also depends on whether you can allow the introduction of a premium system to pay for the initiative of developers, which will also spur the development.
Other subtleties also depend on money: can you hire a consultant at a critical time, allow yourself to save time by purchasing an already-made component. In the case of an independent business project or startup, it is the budget that determines how much you can spend on advertising and promotion among hundreds of competitors. History teaches us that projects with bad code and management can still be successful with a competent marketing company.
And most importantly, the more resources a project has, the more mistakes it can afford to make so that it does not affect the ultimate success.
Usually the effectiveness of the methodology is estimated by the results of the project. And here we can immediately fall into 2 traps - the effect of randomness and the subjective interpretation of the result. The latter boils down to the fact that people ignore the number of projects that failed when using the chosen methodology (and what's the difference, because we found out that there are enough other reasons). Well, that is most people ignore this. Those. all you have to do is to create any set of practices, apply them in a couple of high-profile projects that have been carried out to the end, combine this set of practices into a management technique, calling it a great name.
Congratulations, you have just created your project management methodology. No one except a pair of whiners (whose opinion will not be heard anyway) will check how realistic your technique is, everyone will see only the success of your projects. Believe me, even if your methodology is very bad, all the same, due to the presence of a heap of other factors affecting the success of a project, it will most likely result in some number of projects. And if its use will lead to failure, then a rare manager will say that he chose a bad technique, he would rather complain about bad programmers, a small budget, death spots, irresponsible customers, and you never know what else.
In view of the human nature described above, the effectiveness of natural selection among the latter-day and even fairly old methods of project management seems to me rather low, which casts doubt on the assertion that the methods used in software development are really effective. After all, in order to survive and get spread, the methodology must meet all the requirements of one thing - do not interfere so much as to overwhelm the development process.
Any systematic development of software has been going on for at least three decades; during this time, not a single project management methodology has been submitted, which would be unconditionally accepted by the industry. There is a regular change of methods without a fundamental change in the efficiency of development and the quality of the software produced.
Noticeable results from the application of the methodology can be reduced to a situation where the team is a mediocre manager, and any improvement, even the most obvious, can lead to improvement. In the case of an average manager and higher, the effectiveness of the method is generally beyond the provability.
The piquancy is added by the moment that usually the decision on the introduction / change of the development methodology is made at the moment when it becomes clear that the development is not satisfactory. This idea comes to managers and programmers, with a hint that you need to work more productively, and the technique is only a symbol. Simply put, the main result we get from the pressure on developers.
The influence of the development methodology is drowning amid the influence of other factors, so in principle it is not possible to evaluate the benefit from it.
Due to the fact that in real conditions it is not possible to test the effectiveness of any management technique, we have many approaches that are actually used at random. All this led to the emergence of a whole galaxy of managers who confused fundamental unprovability and difficult provability (assuming that any complex system of management rules simply cannot be erroneous) and decided to choose any methodology and take it for granted. From the outside, it looks like a circus, where some try to cover up the lack of experience in managing a formal approach, using a modern methodology, others with talent to manage, but not having critical thinking, take their successes for the success of the methodology, managers of companies that make changes in the process project to simulate activities. All this somehow exists and works, and most likely will exist for a long time, because where there are no clear criteria for evaluation, you can prove anything.
If you are faced with the need to use a modern method of project management, or you just wanted to try something new, then do not take seriously the assurances of its effectiveness. As a rule, recognition of effectiveness rests on one or two authorities, and then it goes on by inertia, and you will never know what really made the leadership career of these authorities successful. However, you should be aware of available methods for at least two reasons - if you want to find a job and if you want to have a set of typical solutions in your head for common problems. And the ability to select templates for the purpose will come only with experience.
Software development is permeated with such beliefs at all levels, ranging from the choice of programming language, moving to design technology, and ending with project management technology. Interpreting the results of the results of a successful project, if you decide to test some method using his example, can also mislead you if you are not configured as skeptical as possible. In this series of articles I will try to give you several starting points for analyzing the effectiveness of a particular development methodology. To some extent, everything that will be written below is just a detailed description of the main idea of ​​the site programming-otherfucker.com .
Let's start with project management, as an area where the search for truth is the most difficult. And if at least one person, after reading this article, refuses to introduce in his project a fashionable development methodology, based only on its popularity, I can assume that the time to write this text was not wasted.
Introduction
Perhaps the following statement will seem absurd and impractical to you, but it is: it is impossible to accurately measure the effectiveness of a software development methodology. The reason is simple - to get accurate results, we need to start the process of developing the project of the same team, in the same language, with the same managers, at the same time. But with different approaches to development. Provided that you have medium managers who are familiar with each of the development methods, about the same. And also provided that all communication will take place in a purely official tone and only in text form in order to exclude the possibility of the influence of charisma / whining / motivation of managers on the development process. Rave? Can you refute on the merits?
')
Of course, there are things, the benefits or harms of which are obvious, and most importantly, provable. But it is necessary to take a step aside and we will plunge into the pool, where the ball is ruled by a case where credibility lies within the framework of statistical error, and the main argument is defying personal experience elevated to the rank of truth. Simply put we get into real life.
Managers are still people
And that's it. No true, what are the main sciences studying human behavior? That's right, it's psychology and sociology. Both have existed for a long time, at the disposal of both huge amounts of information - the media, history, countless experiments. Nevertheless, none of these sciences are able to predict the behavior of a person, a social group, a nation with a high degree of probability, unless of course this is a trivial situation.
This was said to the fact that the whole theory of management is ultimately the same science of people, only more young, with several different schools. And, you will not believe it, but all these approaches, which are often contradictory ... work! In any case, the adherents of each school think so. In any case, successful projects are under the banner of each school, and failures can be attributed to a thousand reasons not related to management techniques.
This fact should lead us to the conclusion that the choice of management methodology is not decisive for the project. Then it is logical to transfer the view from the method to the person using it. The human factor is the only thing that can explain this random triggering of the methodology, although let's be honest, there may be a lot of reasons - an objective lack of budget, unrealistic deadlines, a weak level of programmers, etc.
During my modest career I had to deal with different management models. There was a purely gangster variant, when programmers were called and threatened to make them work. The most common model for small teams is one boss, up to a dozen programmers, there is no methodology as such, or there are borrowings from everywhere. Startups are either abraded, or agile and derivatives, or a herd of developers, where the leader is more like TK than human. Large teams - confusion and vacillation from one department / team to another, recently the same agile has been fixed.
At the same time, all these projects, from large to small, are alive and well, and also fail. The same technique used in different projects can lead to different results. It is logical to assume (disregarding all other factors) that the result depends on who uses the technique. Will it be possible to motivate the team for productive work? How successful will the negotiations be with the customer (he is also a person)? Will it be possible to persuade programmers to work for ghostly perspectives? Will it be possible to organize such an atmosphere that the programmer himself did not want to go to the competitors? How accurate will the timing and price be calculated? Will the manager be able to formulate the client's requirements so that the team does not resolve conflicts in the TK before the date of the delivery?
For the most part, these questions lie outside the existing methodologies, or the use of methods in solving these questions is not decisive. The decisive factor here is the personal qualities of a person, no matter how sad it may sound, and it is they who, despite a poorly set project management method, can lead to success, or, despite the most advanced project management, fail the project.
Therefore, before evaluating the next development methodology, sort through all the familiar managers in memory and give yourself an honest answer, but will they cope with the task and subordinates?
Programmers are people too
Do I have to say to what extent the result of the project depends on them? It is necessary. In addition to the obvious level of professionalism in their field, you need to understand that the following factors matter:
- variation of the level of qualification in the team - one team will not pull out five juniors. Although no, it will pull out - my computer science teacher was able to pull out as many as 15 people, but it was not enough for commercial development.
- how is communication in the team. Among the most qualified programmers there is a high percentage of those who lose their motivation, seeing hour-long meetings and conferences about a solution that takes up several lines. Among the majority of programmers, there is a high percentage of those who lose their understanding of the purpose of work in the absence of hourly meetings and conferences about a solution that takes up several lines.
- how attractive the project is for performers. A start-up on tracking satellites with issuing a visibility map of a particular satellite in a particular region of the Earth will cause more enthusiasm for almost any programmer than a simpler project of the type “clone of that site with such features.” I have often heard from programmers that for good money they are ready to rivet these clones all my life, but in reality, I can do this one, and I don’t even consider those high-level programmers. At some point, meaningless from the point of view of benefit (but not at all meaningless from commercial) projects begin to kill the desire to work, and there is a gradual immersion in procrastination.
- how much programmers are loyal to the existing development method. Not everyone will enjoy the daily scrum meetings. It is also possible that the programmer is committed to one development methodology, while another is chosen for the project, but there’s nothing to worry about - no sane person starts to put the stick into the wheel manager to prove that his technique is the best.
Need more gold
Many problems can be solved with money, what can we say about the number of problems that cannot be solved without money. We will not consider an obvious example, when a startup is falling apart a couple of months after its creation due to the fact that hunger for programmers turned out to be stronger than belief in a brighter future. It is quite obvious that it depends on the project budget (to some extent) on how much professional programmers you hire. It also depends on whether you can allow the introduction of a premium system to pay for the initiative of developers, which will also spur the development.
Other subtleties also depend on money: can you hire a consultant at a critical time, allow yourself to save time by purchasing an already-made component. In the case of an independent business project or startup, it is the budget that determines how much you can spend on advertising and promotion among hundreds of competitors. History teaches us that projects with bad code and management can still be successful with a competent marketing company.
And most importantly, the more resources a project has, the more mistakes it can afford to make so that it does not affect the ultimate success.
Randomness as a significant quantity
Usually the effectiveness of the methodology is estimated by the results of the project. And here we can immediately fall into 2 traps - the effect of randomness and the subjective interpretation of the result. The latter boils down to the fact that people ignore the number of projects that failed when using the chosen methodology (and what's the difference, because we found out that there are enough other reasons). Well, that is most people ignore this. Those. all you have to do is to create any set of practices, apply them in a couple of high-profile projects that have been carried out to the end, combine this set of practices into a management technique, calling it a great name.
Congratulations, you have just created your project management methodology. No one except a pair of whiners (whose opinion will not be heard anyway) will check how realistic your technique is, everyone will see only the success of your projects. Believe me, even if your methodology is very bad, all the same, due to the presence of a heap of other factors affecting the success of a project, it will most likely result in some number of projects. And if its use will lead to failure, then a rare manager will say that he chose a bad technique, he would rather complain about bad programmers, a small budget, death spots, irresponsible customers, and you never know what else.
In view of the human nature described above, the effectiveness of natural selection among the latter-day and even fairly old methods of project management seems to me rather low, which casts doubt on the assertion that the methods used in software development are really effective. After all, in order to survive and get spread, the methodology must meet all the requirements of one thing - do not interfere so much as to overwhelm the development process.
Five minutes of subjectivity
Any systematic development of software has been going on for at least three decades; during this time, not a single project management methodology has been submitted, which would be unconditionally accepted by the industry. There is a regular change of methods without a fundamental change in the efficiency of development and the quality of the software produced.
Noticeable results from the application of the methodology can be reduced to a situation where the team is a mediocre manager, and any improvement, even the most obvious, can lead to improvement. In the case of an average manager and higher, the effectiveness of the method is generally beyond the provability.
The piquancy is added by the moment that usually the decision on the introduction / change of the development methodology is made at the moment when it becomes clear that the development is not satisfactory. This idea comes to managers and programmers, with a hint that you need to work more productively, and the technique is only a symbol. Simply put, the main result we get from the pressure on developers.
The influence of the development methodology is drowning amid the influence of other factors, so in principle it is not possible to evaluate the benefit from it.
Due to the fact that in real conditions it is not possible to test the effectiveness of any management technique, we have many approaches that are actually used at random. All this led to the emergence of a whole galaxy of managers who confused fundamental unprovability and difficult provability (assuming that any complex system of management rules simply cannot be erroneous) and decided to choose any methodology and take it for granted. From the outside, it looks like a circus, where some try to cover up the lack of experience in managing a formal approach, using a modern methodology, others with talent to manage, but not having critical thinking, take their successes for the success of the methodology, managers of companies that make changes in the process project to simulate activities. All this somehow exists and works, and most likely will exist for a long time, because where there are no clear criteria for evaluation, you can prove anything.
Conclusion
If you are faced with the need to use a modern method of project management, or you just wanted to try something new, then do not take seriously the assurances of its effectiveness. As a rule, recognition of effectiveness rests on one or two authorities, and then it goes on by inertia, and you will never know what really made the leadership career of these authorities successful. However, you should be aware of available methods for at least two reasons - if you want to find a job and if you want to have a set of typical solutions in your head for common problems. And the ability to select templates for the purpose will come only with experience.
Source: https://habr.com/ru/post/151294/
All Articles