Why is software development so labor-intensive even though there are many people and little work to do?

This article is about a "strange phenomenon" that I have personally experienced during the software development process. Why is it strange? It seems to be in line with common sense that there is strength in numbers, but often in the process of software projects, there are many people, few tasks, and a large workload, which is very different from our previous cognition.

First of all, let me explain the meaning of the title. Many people refers to the same project team, the same group or the same department; few things refers to the effect produced, but the actual output is small; heavy workload refers to long working hours, busy work and large actual investment.

In fact, too many people and too little work means low efficiency. There are thousands of reasons that affect efficiency, including personnel problems, communication problems, process problems, management problems, and technical problems. The following are some of the problems that the blogger has personally experienced:

The article is basically pure text, so please read it carefully when you have free time.

● Frontline staff did not let professionals do professional things, resulting in low efficiency

Not letting professionals do professional work is a taboo in work development. In industry, everything has been proven long ago. In factory production, workers work in an assembly line, and one person only focuses on one thing. They will become more and more skilled, faster and more efficient as they do it.

Today, when the division of labor in software development is becoming more and more clear, can the efficiency be high if the back-end staff take the jobs of the front-end staff to write web pages and styles? Can the efficiency be high if the back-end staff take the jobs of the DBA to do database optimization?

Unprofessional people doing unprofessional things may be related to the company's development history, organizational structure, and personnel planning; it may also be related to task arrangements.

In the early stages of a company's development, it cannot afford to hire many professionals, so it may need a "full stack" engineer who can do everything. In the transitional period of a company's development, it has some money and realizes that it needs to let dedicated people do professional things, but the staff has not been fully recruited. In that case, you have to do various things part-time. If the company has money and matures, it does not belong to the above two stages. In the IT organization, if the front-end, back-end, testing, architecture, DBA, network, server operation and maintenance, technical support, security, and products are not well distinguished, it will affect work efficiency. Every IT front-line worker needs a professional screw in every position.

● Developers do not pay attention to code quality, resulting in rework and low efficiency

Sometimes, fast is slow. For developers with insufficient experience or bad habits, in the early stage of development, they are forced or unaware that in order to pursue progress, they do not consider the logic thoroughly and do not do self-testing. They consider the task completed as long as the code can run. On the surface, the task is completed quickly. However, in the later stage of the project, during the testing phase, problems break out on a large scale and even need to be reworked. Since it may be a while since I wrote the code in the late stage of testing, I have forgotten some things. If I go back and "familiarize" myself again, how can the efficiency not be low? The more serious consequence is that the project progress is uncontrollable. Therefore, no matter how tight the progress is, I have to withstand the pressure and do the most basic tests before entering the next task point.

● Individual organizations have expanded their staff, resulting in high communication costs and low efficiency

Communication cost is the primary problem exposed after the expansion of staff.

For example, many companies have a morning meeting every day. If a team has 5 people, and they report on their work, it takes 10 minutes for each person to report for 2 minutes. Now if a team has 10 people and each person reports for 2 minutes, it takes 20 minutes to complete the report. Time just passes by.

For example, if 30 man-days' work is divided among 2 people, it may take 15 days, a total of 30 man-days. But if it is divided among 5 people, can it be completed in 6 days?

Information may be "distorted" during the process of communication and transmission. You may not be able to say 100% of what you think, and even if you say it, others may not understand it 100%. Moreover, everyone's comprehension ability and knowledge system are different, so it is easy to have deviations in understanding, and deviations make it easy to do wrong things.

Therefore, if the number of staff increases, reasonable project and staff division should be carried out based on the project. It is best not to have more than 4 people in charge of the same "small project". When communicating, it is recommended to use oral + written + repetition to reduce information distortion during the communication process.

● Mutual distrust between superiors and subordinates leads to obstacles in getting things done or duplication of work, resulting in low efficiency

Mutual trust between superiors and subordinates is the foundation of all work. If the superior does not trust the subordinates and dare not delegate authority to them, and has to review everything himself, and the superior is often a one-to-many relationship, then the work bottleneck will appear on the superior; if the superior does not trust the subordinates and sets up a bunch of supervision mechanisms, in order to prevent the subordinates from making mistakes, he will have to ask other colleagues to review it again, which will consume extra costs, waste people's time and money, and the subordinates will not be trusted and will be hindered in doing things. Over time, they will be timid and find it difficult to be independent, or feel that they have no place to use their abilities, so they simply leave.

Superiors should fully trust their subordinates and feel free to authorize them to do things, but all of this is based on a prerequisite of having a good software management process, including a development environment and a testing team, as well as providing some guidance and control and supervision of important nodes in the process of completing tasks.

It is common for superiors to not trust their subordinates, and it is also fatal for subordinates to not trust their superiors. Programmers are very individualistic workers, difficult to manage, and often have many ideas. It is like a wheel stuck in a quagmire. The superior says to push the car forward, and some people say to pull it back. With each exerting their own strength, it is estimated that the car will never get out of the quagmire, so how can we talk about efficiency?

Therefore, if you have any opinions, you can raise them in the early stages, but once the solution is decided, everyone should be united (even if you have opinions, keep them to yourself) and work together towards the goal.

● There are barriers and obstacles in communication between different departments

During the software development process, within the IT field, different departments inevitably overlap, such as development and operation and maintenance, development and testing. The responsibilities assumed by different positions, the knowledge systems mastered, and the perspectives on issues are often different, which leads to obstacles in handling things.

For example, once, in order to verify a certain problem, the developer needed the assistance of the operation and maintenance personnel to restart a certain site. For the developer, this site is used by relatively few people, and restarting is a matter of a moment, and the risk is basically zero. However, due to the different knowledge systems mastered by the operation and maintenance personnel, they are afraid that restarting will cause a great impact, and even afraid that they will be responsible for the problem. They can obviously solve the problem instantly, but they have to wait until noon or midnight when no one is around before they dare to restart, which reduces efficiency. At this time, the operation and maintenance personnel need to learn relevant knowledge or introduce new processes. For example, restarting the site requires verbal consent from a professional, and it can be executed immediately.

Therefore, people from different departments should learn from each other so that they can communicate better; when doing things, they should try to make them lightweight, procedural and standardized.

● Inadequate work arrangements by superiors

Inadequate work arrangements by superiors can also lead to low work efficiency. Sometimes there is a strange phenomenon that many things may not be done, but the people below have nothing to do; or some people are very busy, while others are very idle.

The division of labor in software development is not like moving bricks, where one person can move one truck. In software development, work quantification itself is a difficult area. If the project manager does not make a project plan and does not split the work points and tasks, it will be difficult to arrange the work in place. Especially for those who have just transformed from programmers to project managers, they have a procedural mindset and cannot grasp and plan the project as a whole. They just do whatever they think of and assign whatever work they think of. In the end, it is a mess, and the people below are exhausted and idle.

● Unclear communication of requirements or misunderstandings lead to rework

It is difficult to find out the potential needs of customers. After the needs are determined, the medium for information transmission is often the requirements document. Language and text are easily distorted during the transmission process and lose their original meaning. In this case, the requirements are transmitted across too many levels before finally reaching the developer. If this structure is used, it is a big deal if 2% of the information is lost at each level. If it is done wrong, the efficiency and cost of rework will be huge.

Often this is the way of communication:

What we need is this approach:

After receiving the requirements, the R&D personnel should communicate with users, product managers, and R&D managers before making the final decision.

● The technical architecture is too backward and too complicated

Advanced technical architecture and unified and efficient development standards are the cornerstones of system construction. They will greatly improve software productivity and allow developers to focus on implementing business and commercial logic and do more valuable and higher-productivity things.

When you are still struggling with page compatibility and how to implement the required fields on the interface, others can automatically generate the interface through simple configuration of tools; when you are still struggling with large concurrency and how to implement distributed transactions, others' message mechanism and two-phase commit are already in full use; when you are still struggling with distributed systems and database splitting, if you need to do cross-database query, others' ORM automatic database routing and data distribution mechanism are already overused; when you can't figure out the calling relationship between various systems, can't guess the impact of single-point changes, and face huge pressure on operation and maintenance, others' service governance framework comes into being. ... All of this depends on advanced software architecture, which is either ready-made or independently developed. All of this can make developers more powerful and get twice the result with half the effort.