Thoughts on Reading "The Myth of Human Moon"
basic situation:
- Title: The Myth of Human Moon
- Author: Brooks (FrederickP.Brooks.Jr.)
- Number of Pages: 369
- Number of words in the book: 316000
- Publisher: Tsinghua University Press
- Publication date: November 2002
- Reading date: September 2020
1. Main content:
A brief summary of the content of each chapter:
1. Tar pit
Comparing the development of a large-scale system to a tar pit in the prehistoric era, the continuous problems in the development are like a ball of yarn that is constantly sheared and messed up, which makes people struggle painfully, and when part of it is freed from it, the fun is great. In distress. The value of this book is to provide some development guidance so that we can pass through such tar pits more quickly.
2. The myth of man-month
In traditional work arrangements, we often use man-months as the unit of work. For example, if ten people do this for three months, it may take only one and a half months for twenty people. It implies that the number of man-months and time can be replaced with each other. However, such exchange is almost impossible in system programming, because we tend to add manpower to projects that are behind schedule, which will make our development progress more Falling behind creates more trouble.
3. Surgical team
In the process of large-scale project development, a large-scale team composed of many people will have many shortcomings, high management costs, too much difference in team members' abilities, and development efficiency can not keep up. Therefore, Mills recommends that each part of a large-scale project consists of a small team Solved, but the team was organized in a surgical manner to fully realize the professional and reasonable division of labor among team members.
4. Noble despotism, democratic politics and system design
Why should aristocracy be emphasized in the system development process? Because in the computer system development process, because the design is divided into several tasks completed by several people, the conceptual differences and inconsistencies will be great, and the advocate of aristocratic dictatorship is based on the conceptual integrity of the development, and it is better to omit some Irregular features and improvements do not advocate independent and incompatible systems.
5. Superfluous
When developing the first system, the architect tended to be refined and concise. Because he knows that he doesn’t know enough about the task in progress, he will work carefully, and the second system is the most dangerous system designed by designers. A common tendency is to over-design the second system. Adding a lot of modification functions and ideas to the system, his result is a "big pie" as OVid said, and only half of the operations are routinely used in the end.
6. Implementation
Assuming that a project manager already has a coded architect and many programmers, how can he ensure that everyone listens to, understands, and implements the architect's decisions. This requires a documented specification-manual, which is a unified basis for all developers to ensure consistent development.
7. Why the Tower of Babylon failed
The failure of the Tower of Babylon is used to illustrate the importance of communication and organization. In large-scale programming projects, because the left hand does not know what the right hand is doing, schedule disasters, unreasonable functions, and system defects appear one after another. As the work progresses, many The team slowly modified the function, scale, and speed of their programs. They explicitly or implicitly changed some conventions on the usage of valid input and output results. Therefore, certain exchanges should be carried out during the development process.
8. Be confident
The time spent on a project should not just be limited to coding. The time for planning, documentation, testing, system integration and training must be taken into account. Productivity will vary significantly depending on the complexity and difficulty of the task itself. A reasonable estimate of the progress of the project can make the implementation of the project as clear as possible.
9. Cut your feet to fit your shoes
For project managers, scale control is both part of technical work and part of management work. He must study users and their applications to set the scale of the system to be developed. Next, divide these systems into several parts, and set scale goals for each part. Since the results of the scale-speed trade-off scheme vary in a large range, the setting of scale targets is a very tricky thing, requiring a deep understanding of each available scheme. Smart project managers will also reserve some space for themselves to allocate when the work is carried out.
10. Outline
In many software projects, developers start with a meeting to discuss the structure and then start writing code. No matter how small the project is, the smart way for project managers is to formally generate a number of documents immediately as their data foundation, even if these mini documents are very simple. Then, he will request various documents like other managers.
11. Plan ahead
Chemical engineers have long realized that a reaction process that can be carried out in a laboratory cannot be realized in one step in a factory. An intermediate step called an "experimental factory" is very important. It will provide valuable experience for increasing production and operating in a lack of protection. For example, the laboratory process of seawater desalination will be tested at a test site with a production capacity of 10,000 gallons/day, and then used in a purification system of 2 million gallons/day. Software system builders also face similar problems, but they don’t seem to learn their lesson. One software project after another is to design an algorithm at the beginning, then apply the algorithm to the software to be released, and then release the first developed product to the customer according to the time schedule.
12. Dry general Moxie
What is the leader of our development project? That is the numerous programming development tools. Developing and maintaining common programming tools will make project development more efficient. The project manager needs to allocate resources reasonably for the development of common tools. The tools that the project manager must consider, plan, and organize are first computer facilities, then utilities, debugging aids, test case generation tools, and word processing systems for document processing. Appropriate development tools and high-level languages, like good tools, can make project development more effective.
13. The whole part
How to develop a working system? How to test the system? How to integrate a series of tested builds into a tested and reliable system? For these problems, some methods have been mentioned more or less before, but while implementing conceptual integrity, we still need to have more detailed function definitions and standardized function descriptions for the product. According to the top-down design concept, program design should be a series of refined designs.
14. Misfortune
The progress of the project is often affected by a variety of circumstances. But we can accurately monitor the progress of the project by formulating a schedule and setting up milestones. This must be a specific and measurable event that can be clearly defined.
2. Key content and personal experience:
When I first heard about "The Myth of Man-Month", I thought it was an extra-technical, but very well-written extracurricular reading, so the teacher would recommend us to read this book and let us write an afterthought. I’ve read this book twice so far. The first time I succumbed to it, I felt that the entire chapter was talking about the importance of cooperation and communication, and then there was the second time. When I started to read it by chapter, I realized that every time Each chapter corresponds to one aspect, and these aspects seem to be more or less unavoidable problems encountered in the development process. This book analyzes the importance of these problems in detail, and quotes many examples
The first moment before I saw this book, what attracted me first was its title, the Myth of Human Moon? Why is such a book that originated from technology and emphasized the standardization of team development? And as I continued to read and think later, I slowly began to understand the concept of "human month", which is almost impossible to achieve in system programming.
"Man-month" can be considered as a unit of workload used in project estimation and scheduling. In some cases, the cost will vary greatly with the number of people and time developing the product; however, the continuous increase in cost does not necessarily speed up the progress, but may cause problems to cause the entire Progress was slowed down. Therefore, it is problematic to use the concept of "person-month" to measure whether a job or a project is large or powerful. To a certain extent, the number of personnel and development time in system programming are not interchangeable. We cannot say that adding people to the project will definitely speed up the project completion time. Ten people developing a project may not be slower than a hundred people. ; But at the same time, ten people can develop a project faster than five people. The "person-month myth" we want to achieve is to achieve the maximum benefit of a job between the number of people and time.
But at the same time, a good product development team should not consist only of programmers. The so-called maximization of work efficiency does not mean developing products with the least cost. The development team should also have product managers, architects, and clear Division of work and requirements specification. The era when a person like Qiu Bojun, a computer, developed a product as great as wps1.0 in more than a year has passed. Most of today’s projects are based on team-based development, and the different thoughts and personalities of each person in the team will cause a great crisis in the development of the project. Therefore, only the formulation of team development specifications can solve this idea. Differences in style. "The Myth of Man-Moon" is such a book. It does not teach us how to break free from the tar area that appears in the development of large projects. It just points us to most situations that may occur in the development process, and then let me Pay attention to these situations. Give us some suggestions on how to develop reasonably. We should also correctly understand and take these suggestions seriously.