Division of labor makes everyProgramMembers only focus on their work areas, and have no time or energy to care about other parts of the system. This leads to localism in system development. What is more serious, errors in the system are covered by detailed division of labor. At last, they are often found during system testing. It is too late to modify the system, so we have to fix them, in the end, the whole system becomes like a quagmire, which makes the project team unable to extricate themselves. The reason is often that the Division of Labor leads to mutual ignorance. In the end, the work of each other is offset, the more troubles and disadvantages it brings to other parts, which is a very ironic reality in software development. this is often understood as requiring more communication. In fact, it is not because only by fully understanding the work of the other party can we achieve effective communication, the separation of labor makes full communication impossible. <man-month myth> the root cause of the communication problem lies in the division of labor. The author hopes to strengthen communication to solve the problem, which I think is unrealistic.
As we all say, "division of labor increases productivity", managers tend to blindly demand higher development efficiency under the guidance of this judgment due to market and customer pressure. it is precisely because of the division of labor that programmers in different positions cannot realize the mistake of doing so, and resistance to such a decision often carries the crime of absenteeism, and finally everyone listens to it. finally, system analysis, design, coding, and testing were started before the system was clearly understood. the result is "speed is not up to speed". The final result is that at the beginning of the system, it seems that everything is normal during the process. When the system is over, the problem begins to appear, this causes the project to be delayed. <Mythical man-month> there is such a sentence: "It takes time to cook well. "In fact, the same is true for software development. Before you fully understand the system, you can start to work blindly. The result is that the more you work, the more errors you encounter. on the surface, it seems that the efficiency has been improved, but the speed is actually pursued at the expense of the quality of the software. In the end, it was too late when the conflict broke out, which caused the software crisis. the reason is that the premise that "the division of labor increases efficiency" is plausible. The correct statement should be: "under certain circumstances, the division of labor can improve development efficiency, however, under certain circumstances, development efficiency may also be reduced. "On the surface, the improvement in development efficiency is not a real improvement in development efficiency. On the surface, this improvement often hides the ignorance of the system and lays the foundation for system failure.