Read the Mythical man-month

Read the Mythical man-month

-- Chen kaifei

After reading this book, I began to be deeply attracted by the content of this book. A book that was written 35 years ago is still very bright. The first time I came into contact with the man-month concept, because I had not previously been exposed to too many quantified software engineering concepts. It was also the first time that I saw a software engineering project's reliable but unexpected ratio of tasks to time allocation, the time allocation of test is as high as 1/2 and refined into component test and early system test and system test, all components in hand. The first time I realized that for a software project, the more people, the better. Second, too many people will only reduce the efficiency, because the consumption of communication increases sharply with the number of people.

For the assignment of a software engineering task, a surical team model is proposed in the book. This model assigns the group members to surgeon, copilot, Administrator, editor, Secretary, program clerk, toolsmith, tester, language lawyer, and provides their communication pattern ). I think a refined and scientific division of labor is extremely important for a software engineering team, otherwise the assignment of tasks will become extremely messy. In this software engineering course, we used the classic division of labor model: PM, designer, programer, and tester. they performed their respective jobs with excellent effects and efficiency.

ForProgramArchitects and programmers put forward in the book that they need to be conceptually unified and consider each other. One thing I'm very impressed with is that, after the program architecture is good, if the program writer requires to modify some of them, the architect should try to modify it as much as possible. Because some things are easy to design, but implementation requires a lot of work, and these things can only be discovered by programmers. Therefore, I think architects and programmers should work separately in general, but they must maintain communication and conceptual consistency with the entire program.

When designing a program architect, you must always communicate with programmers and users to adjust and change your design. In addition, the design of the first version is generally very simple, but when the design of the first version ends, the architect must be careful to add too much content to the design of the second version. Because the second version of the design once an error, will have a great impact on all the subsequent work. However, adding a lot of content can easily lead to errors. Therefore, the design of the second edition must be added to the benefits. You can complete the functions worth completing.

Program designers also need to pay attention to writing documents. It requires a very rigorous definition and description, and cannot be too boring. When defining, formal definitions and English prose can only use one of them. At the same time, they need to hold regular meetings with group members to update the design requirements.

The importance of communication is self-evident in the field of software engineering. A team needs to communicate with each other through meetings, documents, and other means, and exchange and update information on a regular basis. If the communication is good, everyone only needs to do their best.

 

All in all, software engineering development is a very complicated and valuable thing. The experience of Brooks has not been bad for decades. Naturally, there is a reason for this. I think most of the information described in this book is an overview of the nature of software engineering.