Cargo cult in software development
Recently, I see many examples of how technical project managers (aka CTO) follow the canons of the Cargo cult in the development and management of projects, instead of introducing entities as needed, and building the process based on current needs, available resources and skills performers. We will talk about how to identify such a Cargo cultist and what risks they bear for the project.
To my natural question to one such CTO - how tangible is the benefit of this event, CTO honestly answered - "I don’t know either." Despite some advantages for the team, part of which worked remotely, discussions certainly came down to "Yesterday I wrote code, today I write code and tomorrow I plan to write code too, but, well, I still correct such and such bugs." As a result, we have minus half an hour from each member of the team. Some plus for remote workers is daily communication with the team, for some it is important. In my opinion, the usefulness of such daily discussions for development is rather small, since the main task of such general gatherings is to convey to everyone information on the current state of development, plans for the near future (from a week to a month), to discuss some issues that interest all. Very often, such discussions slip into discussions of some niche issues that are interesting for a couple of people, and the rest begin to get bored and expect when it will end. This should certainly be suppressed and discussed later, in a narrower format. The current state of development and plans are very important, but it is enough to discuss them once a week or even less, depending on the speed with which the team works.
Currently, many tools are available that allow you to describe the project infrastructure (services, networks, dependencies) in a convenient form, for example, Terraform. This thing is certainly useful, but with a certain project size, for example, when it becomes quite complicated. For most startups and small projects, this is an excess tool, since the infrastructure is extremely rare, and the ability to quickly deploy another Production is needed, roughly speaking, once a year, many startups may simply not survive. Therefore, the simpler the project is described - the better, many will have enough and Docker Compose.
Excessive enthusiasm for tests leads to the fact that precious development resources are spent on this, significantly increases the cost of refactoring (after all, all the affected tests must be rewritten) and often creates the illusion of code reliability and correct operation. I met a startup where, after a year of development, more than 2000 tests were written for the backend only! To effectively move forward in development, tests need to cover only really important sections of the code where some calculations are performed and manual error diagnosis is difficult. Often, for startups, test coverage can be delayed until the code structure becomes stable and the business logic becomes clear and is unlikely to change significantly. For frontend unit tests, they are often ineffective, since there are usually not enough complex calculations and algorithms, and it is better to cover the basic SPA functionality such as button presses during the BlackBox testing phase through Selenium or the like.
CTO Cargo cultist always uses those tools and technologies that once worked for him before, he read earlier about some cool things or he was told about them. The applicability of all this in the current conditions is difficult for him to assess, so he clearly follows the canons of the cult of Cargo - “after all, an airplane flew before, so I’m doing it right”. To convince CTO that it’s better to use other tools and technologies for the current project becomes an arduous and non-trivial task, because CTO is not used to analyzing the consequences.
There is one way for the Cargo cultist, and he follows it. The fact that the management of the team needs to be built on the basis of the current state of the project, its requirements, qualifications and limitations of the contractor is new to him and he does not attach any importance to this, since he is at high risk that he will not be able to cope. It is not easy for him to admit that there should be a different attitude towards Senior and Middle developers, that there are developers with specialties in communications, approach to business, and responsibility. For him, all the pieces on the chessboard are about the same; he makes the moves about the same. He most likely did not hear about the fact that it is necessary to identify and use the strongest points of each developer. Because of this, the team’s work efficiency is significantly reduced, the developers notice this very well and this makes them less satisfied with the work, usually it is characterized by a decent turnover. Often, such CTOs like to say that they all have Fullstack developers, although personally I have rarely seen equally strong frontend and backend ones, too many technologies need to be known at a good level.
Daily morning discussions (aka Daily Standup)
To my natural question to one such CTO - how tangible is the benefit of this event, CTO honestly answered - "I don’t know either." Despite some advantages for the team, part of which worked remotely, discussions certainly came down to "Yesterday I wrote code, today I write code and tomorrow I plan to write code too, but, well, I still correct such and such bugs." As a result, we have minus half an hour from each member of the team. Some plus for remote workers is daily communication with the team, for some it is important. In my opinion, the usefulness of such daily discussions for development is rather small, since the main task of such general gatherings is to convey to everyone information on the current state of development, plans for the near future (from a week to a month), to discuss some issues that interest all. Very often, such discussions slip into discussions of some niche issues that are interesting for a couple of people, and the rest begin to get bored and expect when it will end. This should certainly be suppressed and discussed later, in a narrower format. The current state of development and plans are very important, but it is enough to discuss them once a week or even less, depending on the speed with which the team works.
Cloud Deployment
Currently, many tools are available that allow you to describe the project infrastructure (services, networks, dependencies) in a convenient form, for example, Terraform. This thing is certainly useful, but with a certain project size, for example, when it becomes quite complicated. For most startups and small projects, this is an excess tool, since the infrastructure is extremely rare, and the ability to quickly deploy another Production is needed, roughly speaking, once a year, many startups may simply not survive. Therefore, the simpler the project is described - the better, many will have enough and Docker Compose.
Code coverage with unit tests
Excessive enthusiasm for tests leads to the fact that precious development resources are spent on this, significantly increases the cost of refactoring (after all, all the affected tests must be rewritten) and often creates the illusion of code reliability and correct operation. I met a startup where, after a year of development, more than 2000 tests were written for the backend only! To effectively move forward in development, tests need to cover only really important sections of the code where some calculations are performed and manual error diagnosis is difficult. Often, for startups, test coverage can be delayed until the code structure becomes stable and the business logic becomes clear and is unlikely to change significantly. For frontend unit tests, they are often ineffective, since there are usually not enough complex calculations and algorithms, and it is better to cover the basic SPA functionality such as button presses during the BlackBox testing phase through Selenium or the like.
Development process management
CTO Cargo cultist always uses those tools and technologies that once worked for him before, he read earlier about some cool things or he was told about them. The applicability of all this in the current conditions is difficult for him to assess, so he clearly follows the canons of the cult of Cargo - “after all, an airplane flew before, so I’m doing it right”. To convince CTO that it’s better to use other tools and technologies for the current project becomes an arduous and non-trivial task, because CTO is not used to analyzing the consequences.
Team management
There is one way for the Cargo cultist, and he follows it. The fact that the management of the team needs to be built on the basis of the current state of the project, its requirements, qualifications and limitations of the contractor is new to him and he does not attach any importance to this, since he is at high risk that he will not be able to cope. It is not easy for him to admit that there should be a different attitude towards Senior and Middle developers, that there are developers with specialties in communications, approach to business, and responsibility. For him, all the pieces on the chessboard are about the same; he makes the moves about the same. He most likely did not hear about the fact that it is necessary to identify and use the strongest points of each developer. Because of this, the team’s work efficiency is significantly reduced, the developers notice this very well and this makes them less satisfied with the work, usually it is characterized by a decent turnover. Often, such CTOs like to say that they all have Fullstack developers, although personally I have rarely seen equally strong frontend and backend ones, too many technologies need to be known at a good level.
How not to become / not to be a Cargo cultist
- Always take a critical approach to introducing new entities (services, technologies). If there are people in your team who know MySQL well but have not worked with Postgres, then it makes no sense to choose Postgres if this does not give you significant advantages.
- The development process must be adapted to the team and business. If Vasya works on Scrum and covers everything with unit tests, this does not mean that this approach will work for you as well, you should always critically evaluate and compare with other options (Waterfall). As a rule, what works for a small team ceases to work for a large team and vice versa.
- Identify the strengths of team members and use them to the maximum. This will increase the efficiency of the entire team, and employees will be happier, because they bring more benefits for less effort.
All Articles