Is the division of labor in software engineering e

  • Detail

Is the division of labor in "software engineering" effective

"software engineering" refers to those theories we have learned in school. After years of development practice and technical exchange, we are constantly rethinking the traditional software engineering theories

problem raising

when we divide software development into three stages (requirements analysis, design and programming), we naturally ask the question, "should software developers continue to improve their specialization?" After all, the division of labor is the foundation of the industrial revolution. It is precisely because the manufacturing industry is broken down into several precisely defined small tasks that the productivity of a group of workers can be restarted by leaps and bounds. Therefore, we take it for granted that this "specialization" approach will be equally effective for software development

it seems obvious, doesn't it? Let some people become professional analysts to specifically obtain and record the needs of users; Let some people become designers, responsible for producing design specification documents from requirements documents; The programmer is responsible for coding according to the design specification. Obviously, it should be a more efficient way to work, shouldn't it? The answer is No

problem analysis

1 Ignoring the cost of communication

the more small steps the same task is divided into, the more time it takes to transfer information between people. Therefore, the flow type production line can work well when a lot of communication work is not required (for example, a lot of manual work in the manufacturing industry); But in the brain work (especially software development) that requires a lot of communication, this method fails completely

most of the work of software development is done in the minds of team members. If you want to force everyone to specialize in a particular job, any simple project will need to deliver more additional intermediate products. Every delivery can bring potential errors and defects, so every delivery is quite expensive. Yes, if everyone is required to write a large number of documents to reduce the risk of misunderstanding or assumptions made by others, we can certainly minimize the possibility of "mistakes due to communication". However, the workload of "writing more documents" is also calculated in the cost of the project. As Fred Brooks pointed out, if the success or failure of a task is determined by the communication efficiency among project team members, adding more people will only delay the progress of the project

when the same developer has a deep understanding of requirements, design and source code, software development can achieve the best results. All hackers interviewed by Steven levy designed and coded independently. In an interview with "19 programmers who have influenced the (personal) computer industry", Susan Lammers mentioned the same phenomenon. None of these great programmers has ever used the software engineering style of division of labor. They usually go deep into the whole design and coding work alone. Interestingly, almost all of them have their own unique work style

2. Leading to confusion

the traditional division of labor is imposed on software development, resulting in the continuous transfer of information among analysts, designers, programmers, testers, user interface experts, document engineers and technical support engineers. Too much communication has greatly reduced efficiency, and the project has been constantly delayed. When any change occurs, the information must be passed along the whole development chain, resulting in chaos. Soon after the project ended, the software became a "legacy system" because no one knew exactly how it worked

software engineering artificially subdivides the technology, which makes it impossible for anyone to understand the entire application. The solution to this problem in software engineering is not to carry out cross training among developers to let them understand the overall situation, but to constantly emphasize the myth of documents - good documents can make anyone understand the entire application. Unfortunately, although the document can well record the choices and agreements in the software, it can not effectively retain and transmit the detailed information about specific problems, and these specific and subtle knowledge is the most important

Another drawback of software engineering is that it makes documents infamous. Many projects actually have no documentation at all, because young developers instinctively reject this "product of software engineering"

3. Lack of scientific quantitative means

"scientific management" replaces empirical rules with science. In the method of "scientific management", numbers dominate everything. If you want to improve something, you must first measure it. If something cannot be measured, it is impossible to improve it by installing the lower end of the lead screw on the base. Managers know everything. There must be a best way to work

therefore, we will not be surprised to see that software engineers have invented many software development measurement methods. even to the extent that, The "time and motion study" brought about by "scientific management" has been used to study the use of software. On some specific issues, people have stipulated some quantitative rules, such as how long it takes to move the cursor to a button (Fitts rule) and how long it takes to make a choice between behaviors with equal probability (hick rule) Wait

in the frenzy of quantitative management, people often ignore the difference between mechanical activities and intellectual activities. Fitts' law is mainly about mechanical activities. Although the action of moving the mouse and clicking a button requires the coordination of the eyes and hands, it is still only a (more complex) mechanical activity. Hick's law attempts to measure activity in the human brain. This is a classic mistake made by software engineering: it thinks that what can be measured is the most important, but this is not the case for large power battery enterprises

fundamentally, software development is also an intellectual activity to achieve the expected cellular response. The speed of typing has never been and will never be the bottleneck of software development. The only way to talk about an intellectual activity is through imprecise discussion, because what you can measure is not helpful to improve efficiency. Software engineering is harmful because it ignores the value of discussion among developers - which is the only way for us to understand software development and improve development efficiency

software factories always show a tendency: they try to imitate the former model of manufacturing. But even manufacturing is growing. Now? Even those who are most enthusiastic about production lines have stopped talking about "fully integrated manufacturing". Nowadays, automobile enterprises no longer have steel factories, coal mines and rubber plantations. They no longer make tires themselves, but buy tires from enterprises that are good at manufacturing tires. The same is true for software components: with components at hand, small teams can develop excellent software.

" The concept of "software factory" is not really popular because software manufacturing is too easy. How to cooperate and communicate with users to create a good design and make it evolve is the real problem in the software industry


if your project has virtually unlimited resources, software engineering is an effective way of software development. However, if your resources are limited and you can't afford hundreds of software engineers, please give up software engineering in time. You must realize that software development is more an intellectual and social work than a mechanical one. With this in mind, you will learn something useful from software engineering. (end)

Copyright © 2011 JIN SHI